Design Pattern in Android

iOS development is based on the MVC and is well structured. The Android system does not require any model. Components of a good implementation should be decoupled as much as possible; it should be possible to switch from one input/output entity(View) to another or to change the location or the type of persistent storage mechanism(Model) without affecting other components. Android team has introduced Android Architecture Components to help better design in this area. I will explain common patterns. 

MVC

MVC (Model-View-Controller) is a standard software project that separates the user interface (View) and the business rules and data (Model) using a mediator (Controller) to connect the model to the view. All external events should be processed by Controller(Activity) in Android. However, it is hard to separate View in the Activity.

Model

The model is the Data, State and Business logic of an application. It is not tied to the view or controller, and because of this, it is reusable in many contexts. For example, It's responsible for handling network or accessing databases. 

View

The view is the Representation of the Model and it has a responsibility to render the UI(User Interface). Also, the view can communicate to the controller when the user interacts 

Controller

When the specific event happens by a user like clicking a button, controller interacts with the event and decides how to process it. Also, the controller may decide to update the state of the view based on data changing in the model. In the case of an Android application, the controller is almost always represented by an Activity or Fragment. 

Summary

MVC could be able to separate the data and the UI but it has a few problems. The controller is tied so tightly to the Android APIs that it is difficult to unit test. The controllers are tightly coupled to the views so that we have to change the controller if the view is changed. It could be more and more codes into the controllers, making them complex. 

MVP

The natural View and Activity coupling can occur without tying it to the rest of the controller responsibilities. Model is no change. Activity can access View directly and Presenter can control it. 

View

Activity or Fragment is now considered part of the view. A good practice is to have the Activity implement a view interface so that the presenter has an interface to make codes. This eliminates coupling it to any specific view and allows simple unit testing with a mock implementation of the view. 

Presenter

This is essentially the controller from MVC except that it is not at all tied to the View, just an interface. It's a one-to-one relationship between View and Presenter. If there are N activity, Presenter should be N counts. That is why this structure could have redundancy codes. 

Summary

In MVP, the Presenter contains a UI business logic for the View. The Presenter is also decoupled directly from the View and talks to it through an interface. This is to allow mocking of the View in a unit test. MVP has to be a lot of two-way dispatching. For example, when someone clicks the 'Save' button, the event handler delegates to the Presenter's 'OnSave' method. Once the save is completed, the Presenter will then call back the View through its interface so that the View can display that the save has completed. 

MVVM

With MVVM, the ViewModel replaces the Presenter in driving the View. The difference is that the ViewModel drives the view with DataBinding, while the Presenter drives the view with an interface.

View

Bind to the ViewModel observable properties and update itself when ViewModel properties change. 

ViewModel

The ViewModel is responsible for wrapping the model and preparing observable data needed by the view. It also provides hooks for the view to pass events to the model. The ViewModel is not tied to the view.

Summary

MVVM uses two design patterns which are Command and Databinding. We can remove the dependency of View and ViewModel. When the input is coming from View, it instructs to ViewModel using Command pattern. Thus, if the values of ViewModel are changed, View will be changed because of Data Binding. 

• When Input is coming from the View, it will do action in ViewModel using Command pattern.
• The ViewModel requests needed information to the Model.
• The Model responses to ViewModel. 
• ViewModel will process the received data and save it.
• View will be updated automatically because of Data Binding.

There is no perfect answer using those patterns. We should choose the patterns in case of your project situation. Also, Some vague concepts in the Android framework are not allowed to separate those patterns like between Activity and View. You should check on Stackoverflow page. It is the famous quote from Robert C. Martin here, and I will close this topic. I am going to move Android Architecture Components next time. 

The only way to make the deadline - the only way to go fast - is to keep the code as clean as possible at all times. 
- Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship