Android Architecture Patterns

When developers work on a real mobile application whose nature is dynamic and will expand its features according to the user’s need, then it is not possible to write core logic in activities or fragments. To structure the project’s code and to give it a modular design(separated code parts), architecture patterns are applied to separate the concerns. The most popular android architectures used by developers are the following:

• MVC (Model — View — Controller)
• MVP (Model — View — Presenter)
• MVVM (Model — View — ViewModel)

The main idea of all these patterns is to organize the project in a proper way so that all the codes get covered in the Unit Testing. Moreover, it is very helpful in the maintenance of the software, to add and remove features and developers can keep a track of various crucial logic parts. 

The Model—View—Controller(MVC) Pattern

MVC pattern is the oldest android app architecture which simply suggests separating the code into 3 different layers:

• Model: Layer for storing data. It is responsible for handling the domain logic(real-world business rules) and communication with the database and network layers.
• View: UI(User Interface) layer. It provides the visualization of the data stored in the Model.
• Controller: Layer which contains core logic. It gets informed of the user’s behavior and updates the Model as per the need.

In MVC schema, View and Controller both depend upon the Model. Application data is updated by the controller and View gets the data. In this pattern, the Model could be tested independently of the UI as it is separated. There are multiple approaches possible to apply the MVC pattern. Either the activities and fragments can act like the controller where they are responsible for data processing and updating the views. Another way is to use the activities and fragments as Views and the controller, as well as Models, should be a separate class that does not extend any Android class.  If the Views respect the single responsibility principle then their role is just to update the Controller for every user event and just display data from the Model, without implementing any business logic. In this case, UI tests should be enough to cover the functionalities of the View.

Advantages:

• MVC pattern increases the code testability and makes it easier to implement new features as it highly supports the separation of concerns.
• Unit testing of the Model and Controller is possible as they do not extend or use any Android class.
• Functionalities of the View can be checked through UI tests if the View respect the single responsibility principle(update controller and display data from the model without implementing domain logic)

Disadvantages:

• Code layers depend on each other even if MVC is applied correctly.
• No parameter to handle UI logic i.e., how to display the data.

The Model—View—Presenter(MVP) Pattern

MVP pattern is the second iteration of Android app architecture. This pattern is widely accepted and is still recommended for upcoming developers. The purpose of each component is easy to learn:

• Model: Layer for storing data. It is responsible for handling the domain logic(real-world business rules) and communication with the database and network layers.
• View: UI(User Interface) layer. It provides the visualization of the data and keep a track of the user’s action in order to notify the Presenter.
• Presenter: Fetch the data from the model and applies the UI logic to decide what to display. It manages the state of the View and takes actions according to the user’s input notification from the View.

In the MVP schema, View and Presenter are closely related and have a reference to each other. To make the code readable and easier to understand, a Contract interface class is used to define the Presenter and View relationship. The View is abstracted and has an interface in order to enable the Presenter for Unit Testing.

Advantages:

• No conceptual relationship in android components
• Easy code maintenance and testing as the application’s model, view, and presenter layer are separated.

Disadvantages:

• If the developer does not follow the single responsibility principle to break the code then the Presenter layer tends to expand to a huge all-knowing class.

The Model—View—ViewModel (MVVM) Pattern

The third iteration of android architecture is the MVVV pattern. While releasing the Android Architecture Components, the Android team recommended this architecture pattern. Below are the separate code layers:

• Model: This layer is responsible for the abstraction of the data sources. Model and ViewModel work together to get and save the data.
• View: The purpose of this layer is to inform the ViewModel about the user’s action.
• ViewModel: It exposes those data streams which are relevant to the View.

The MVVM and MVP patterns are quite similar because both are efficient in abstracting the state and behavior of the View layer. In MVVM, Views can bind itself to the data streams which are exposed by ViewModel.

In MVVM schema the View informs the ViewModel about various actions. The View has a reference to the ViewModel while ViewModel has no information about the View. The many-to-one relationship that exists between View and ViewModel and MVVM supports two-way data binding between both.

Comparing MVC, MVP, and MVVM Architecture Pattern

Pattern	Dependency on Android API	XML Complexity	Unit Testability	Follow Modular and single  responsibility principle
MVC	High	Low	Difficult	No
MVP	Low	Low	Good	Yes
MVVM	Low or No dependency	Medium to High	Best	Yes

Advantages of Architecture

• Developers can design applications that can accept changes in the future.
• Gives a modular design to the application which assures good quality testing and maintenance of code.

Disadvantages of Architecture

• Writing the whole project code in an architecture pattern is a time taking process.
• Strict discipline is required from the developer team side as one misplaced change can ruin the integrity of the architecture.