Android Architectural Patterns: When to use Which

When working with architectural patterns in android, every one of them has its own pros and cons. In some cases, one is better and sometimes the other. But one thing for certain that whatever use case you have there is always a choice.
 

Keywords : 

There is one keyword that gets misinterpreted sometimes: Model (the M letter in every pattern)

One misconception is that model is an object received from a server or database like a Person object or any data class in the app. But that's not true. The Model stands for Model Layer, which contains Entities layer (where all our data class and POJOs object) and then another layer where we put all the business logic/rules i.e. repos, api interfaces or databases classes.

The model layer is accessed by a controller or presenter through an interface which is called inter-actor class or View-model in some cases.

So in essence Model class is responsible for communicating with Model Layer and also holding the state of the current screen. In MVVP you can make this class extend the View-model as it will help survive the app configuration changes.

Lets go over few cases for patterns : 

No Architecture pattern at all : 

There are some screens in some cases where the screen doesn't hold any business logic or app state at all. If we have a screen that only has some textview that shows some information then it doesn't require any business logic or maintaining app state. So here in this case we can use No Architectural Pattern.

Model-View-Controller (MVC) : 

There is no universal unique pattern known as MVC, it's rather a concept than a programming framework. You can implement your MVC in your own way, all you need is to keep in mind the following things : 

1. Model : What to render
2. View : How to render
3. Controller : Events and User Inputs.

In Android MVC is already implemented as :

View = Layout or classes which are derived from android.view.View class
Controller = Activity
Model = Classes that will implement the Business logic.

In MVC, View is too much dependent on Controller and Model both. Model does too much work. So it's not preferable to use MVC in your code. But you can go for MVP.

Model-View-presenter (MVP) : 

MVP provides us with more test-able feature than MVC. The screen communicates with the model and waits for the response to update its UI. 
When we have a simple case where Bi-Directional-Flow is required between UI and Model then MVP is the best choice for us.

The MVP has three main components : 

1. Model : Data that is to be displayed from the network or local database. This data is put into small classes which are later used by components.
2. View : View is what displayed to the user. It handles the interaction between the user and the app. These are lightweight components so they contain less code compared to other components.
3. Presenter : Presenter handles the UI updates based on changes made to the data model and also processes the user inputs. It contains much of the business logic.

The data (Model) and UI (view) only communicate using the presenter. Presenter holds the business logic of the app.
In general MVP allows us to seperate the presentation layer (view) from logic. MVP is a User interface architectural pattern, which eases automated testing and also provide us with clean code architecture.

MVP is a bad idea when the View is updated without the user interactions. Like updating UI when event happens in Model Layer. For this approach we should use MVVM.

Model View View-Model (MVVM): 

MVVM is an architectural patterns which focuses more on seperation on concern. It allows us to seperate the user interface logic from the business logic. It tried to keep the UI code simple and free of the business logic in order to make it easier to manage.

MVVM has following layers : 

1. Model : Model holds the data. It doesnt have any communication with the view. The recommended way is to expose its data through observables or any other observer/consumer to View-Model, so it can be fully decoupled from the other layers.
2. View : The role of the view is to only observe View-Model through an observables and update the UI.
3. View-Model : View-Model interacts with the model and also prepare the observables that are observed by the view. It can also provide callbacks for the view to pass events to models.

The difference between MVP and MVVM is mainly the introduction of View-Model. Its kind of implementation of observer design pattern. The view-model is also lifecycle aware which provide us with a advantage. So, it will not notify data if the view is unavailable. The data automatically flow in the forward mode using LiveData. 

MVVM provide use with more testable code and it allows us to write unit tests against core logic. The presenter and the logic is loosely coupled. In MVVM we have better chances to make the other layers more reusable.

There are other patterns also like MVI or REDUX and many more. The MVVM is mostly recommended way of code as it provide us with more reusability and testable code.