Common Android Architectures (MVC vs MVP vs MVVM)

Before we move on to architectures, let's get this term clear.
God Class/Object: Class which has a high number of components, and the components are coupled. This is a very bad idea and must avoid them at all cost. It is an architectural pattern.

MVC: Model View Controller

Model:
1. Represents the data models.
2. Manages the Data States
3. Has business Logics

View:
1. The way we represent our data e.g. Views/layouts in Android.
2. Renders the UI.

Controller:
1. Handles user interactions with our application.
2. The communication channel between the model and the view.
e.g. the fragments/Activities in Android.

The MVC flow diagram will look like:

The user interacts with the UI, and the controller gets notified via the view. Based on the User interaction the controller modifies certain Models. Models perform some business logic and return the updated model data state to the controller. The controller can then update the UI according to the new data state as received from Model.

The view gets the User input and asks Controller to handle the user input.
Controller gets input from View, based on whether the user chose to hide/view the message. Controller calls Model to update the Data state(message here).
The Model updates the model based on the input from the Controller. Thus it contains this Business logic.
Controllers get the updated Data and update the UI accordingly.

MVP: Model View Presenter

Model:
Same as in MVC pattern.

View:
1. The way we represent our data e.g. Views/layouts as well as Activities/Fragments in Android.
2. Will implement an interface for the Presenter’s Actions.

Presenter:
1. Has no relation to the views(Unlike MVC).
2. Operations are invoked by our views.
3. Views are updated via View’s Interface.

The MVP flow diagram will look like:

Although the Flow diagram looks same as MVC the difference is how the VIew and Presenters/Controllers interacts with each other.

In MVP the Views and presenters interact via an interface(unlike MVC). Presenters perform some action on the Interface, which is implemented in Views and hence the view gets updated.

So the model remains the same(as in MVC).
The presenter here just performs the Interface actions and has no knowledge of the Views it is trying to update.
So the views implementing that interface updates the UI.

It is far better than MVC as here the presenter has NO ANDROID API and it can be easily tested.
The views can be tested using espresso etc to see if the views are updated or not.

Thus the views are pretty dumb. They get data from the presenter and updates the UI Components accordingly.

MVVM- Model View ViewModel

It further minimizes the view binding code i.e. how the view is bind to the model data.

Talking in the Android ecosystem, it uses the Data binding library from Google, and the View’s binding logic is implemented in the XML layouts.

Model:
Same as in MVC/MVP pattern.

View:
1. Same as in MVC/MVP pattern.

ViewModel:
1. It contains the Model.
2. Uses observable values for update values.
3. On the value update, the relevant views will get updates(uses Data Binding Library).

The MVP flow diagram will look like:

So the view receives the User interactions and will notify the view model.
Now the ViewModel will update the model as well as the Observable(which will invoke the value change). Next, the ViewModel interface will update the UI(XML layouts) directly.

So the view i.e. XML file will look like:

So as shown the TextView here can get updated directly its text, as the message value changes.

Comparisons between MVC/MVP/MVVM:

Controllers(activities in Android) have a high dependency on Android, unlike in MVP and MVVM, and hence it is easy to unit test in MVP/MVVM.

However, the XML gets more complex in MVVM for data-binding purposes.