Android Hello World - MVC / MVP / MVVM

This article is intended to show the difference between those 3 patterns in a "Hello World" example.

In all three patterns, the Model is the same ... so lets start creating our Model class that will be used in all of the examples :

* Notice that the word Model stands for the Model-Layer, not an Entity (some times Entity is called Model as well ... like a Label entity or a User entity, etc...), a Model is the class that takes requests from the Presentation layer, and request it from the layers below to get the entities required, then pass it back to the presentation layer

This is our Model class, it is responsible for generating a random String label ... that's all, now for our Patterns :

1- Model-View-Controller

In this pattern, we can consider the View as the XML layout Views ... nothing interesting here, and the Controller is the Glue code between that XML layout, and the Model, in other words, our Controller is the Activity (or Fragment) :

So here, our Controller is the Activity, our View is the XML layout, and all our logic is written in the Activity ... notice that this pattern has proven to be the worst one.

2- Model-View-Presenter

In this Pattern, the View is not the XML layout, it is an interface that holds the methods which changes the UI, which is :

And this View is controlled by a Presenter, which looks like this :

as you see, the Presenter knows nothing about the implementer of the View interface, this respects the Dependency Inversion principal, where we code to Interfaces, not to implementation ... and since this pattern respects this principal, the Presenter also implements an interface, that is used by the View implementer to communicate with it, this interface looks like this :

And the View implementer (The Activity or Fragment) will use this interface to notify the Presenter with the updates needed for the Presenter to do it's job properly (mainly Life-Cycle events), the View implementer will look like this :

in MVP it is very clear that any Activity / Fragment that implements the View interface, should implement the methods that this View requires, like "updateHelloLabel()", and the one who controls when these methods are triggered is the Presenter.

on the other hand, the View has some events like Life-Cycle events, and it needs to notify the Presenter with it, so these events should be in the Presenter Interface, so when it happens, the View can notify the Presenter with it.

Bottom line is, Presenter controls when to trigger UI changes declared in the View interface, and in return, the View notifies the Presenter with Life-Cycle events and similar stuff that the Presenter needs to manipulate UI changes.

3- Model-View-View Model

The View in this pattern is Observing on updates from the View Model, through a binding engine or through Rx-java or any similar mechanism, i prefer the Rx-Java way since it makes it easy to test and know whats going on, also because it does not require putting any logic in XML ... the View Model will be as follows :

and the View is going to subscribe to the Observable in the View Model, and update itself when ever an update happens :

* label::setText is a short hand for making a Consumer and invoking label.setText() in it's accept() method, on the received String value ... this is called "method reference"

the best part about MVVM is Test-ability, where the View Model does not have any reference to the Views, hence it is easy to make J-Unit tests with the minimum effort of mocking, unlike MVP which requires mocking the View implementer, or MVC which is very hard to test.