Android Architecture Patterns (original) (raw)

Last Updated : 23 Jul, 2025

Modern mobile applications are dynamic, evolving over time to meet user needs. As these apps gets complex day by day, it becomes essential to separate core logic from UI components (such as activities and 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 and relay user interactions.
• **Controller: Layer which contains core logic. It gets informed of the user’s behavior and updates the Model as per the need.

How it works?

In a typical MVC setup, both the View and the Controller depend on the Model. For example, a user interaction in the View triggers the Controller to update the Model, after which the View is updated with the new data. Depending on the approach, developers can:

• Use activities and fragments as both View and Controller.
• Or, strictly separate the UI (View) from the Controller logic by having dedicated controller classes.

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.

How it works?

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 responsibilityprinciple to break the code then the Presenter layer can become **overly complex and bloated.
• The need for interfaces and additional classes can result in **more boilerplate code.

The Model-View-ViewModel (MVVM) Pattern

With the introduction of MVVM architecture pattern, it has become increasingly popular. It prioritises a clear separation between and UI and business logic while using data binding to enhance the communication between layers. 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 UI layer that displays data and notifies the ViewModel about user actions.
• **ViewModel: Exposes data streams (often using observable patterns) that the View can bind to. It is responsible for preparing and managing data for the UI and handling user interactions in a way that is completely decoupled from 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.

How it works?

• The view automatically updated when the ViewModel's data changes.
• The View forwards the user actions to the ViewModel without the ViewModel needing to know details about the View.
• Changes in the UI will update the ViewModel automatically, although this adds some complexity.

Differences between MVC, MVP, and MVVM Architecture Pattern

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.