Skip to content

Causes of Moxy

Yuri Shmakov edited this page Jun 22, 2017 · 5 revisions

Theory intro

MVP is a user interface architectural pattern(wiki). This pattern almost does not tell us about model and what it should doing. Only business logic, no more. But this pattern is about View and Presenter. Let's see at these.

View is responsible for GUI. It’s only send user input to Presenter and show commands from Presenter. View interacts with system of input/output. But I/O is not only display. It’s dynamic, camera, bluetooth-devices and so more. View can thus be not only Activity, that interact with display. But View can be Service, because it’s great place for interact with other I/O, like dynamic, microphone, e.t.c.

Presenter is logic of GUI. It isn’t business logic. This component reacts on user input; knows which model should be used; and how and when should be View changed.

Moxy intro

Base your project on MVP is much simple. First, inject presenter in your view. Then inject Model to this Presenter. And that’s all. You use MVP =) This code will be much modular, scalability, testability and so more.

But when you want to allow View recreates, then you should decide, where will be saved presenter and how restore View state. But it’s issue much routine. And then you should know, what we want of Moxy:

  1. Presenter should be exists regardless of View lifecycle state.
  2. Recreated View should use same Presenter instance that be used before recreate.
  3. View should show actual state of UI-logic(of Presenter) at each moment, no depends on attach moment to Presenter.
  4. No boilerplate code for these requirements!

These are the primary requirements to Moxy. And it makes them perfectly =)

Theory of Moxy

Let's first talk about how it should works to resolve our needs. Firstly, Moxy should inject Presenter in some way. We don’t want to know this way. We may allow Moxy receive only View lifecycle callbacks. So Presenter. It’s doesn’t want to know, is View attached or not, and is it one View or many. Presenter should only tell to something, what View should do, if it want to interact with this Presenter. That’s all =)

Okay, lets see, how Moxy do it.

First. what is it some way, how Moxy inject right Presenter? It’s much simple. Moxy have MvpDelegate, that receive lifecycle callbacks and inject right Presenter instance. No interesting. More interesting is second task. How to send command to View, whether or not some attached View? So, lets take a ViewState, that will be collect commands. And when View will be attached, ViewState tell them, what commands it must apply for going to actual UI-logic(Presenter) state. Disclaimer: all of these code will be generated and you should not make something for this.