MVP — Android App Architecture — Part 1

Regardless how many years of experience you have on Android development, you might have worked on projects with different architectures; MVC, MVP, MVVM, MVI ; even one with none of them.
If your project is quite “old”, it probably has been developed with MVP. So, having their own pros and cons, today we’ll explore MVP.

Before diving into MVP, let’s quickly see what was used before it — MVC.

MVC stands for Model-View-Controller. It’s been widely used with the purpose of dividing the application logic into 3 interconnected elements. Briefly, Controller operates in between Model and View, where Model is basically the data layer, View is responsible for rendering UI. Controller gets the events from user, updates the Model and informs View about it in order to update what user sees.

MVC‘s disadvantages

MVC’s primary drawback lies in the tight coupling between the Controller and View components. Any changes made to one component necessitate corresponding modifications in the other. While this may not pose significant issues for smaller projects, it becomes a time-consuming and arduous task in extensive applications with numerous activities or fragments. Developers have to invest considerable effort and time to synchronize changes between the View and Controller. This tight dependency between Controller and View makes the application hard to write Unit tests as well.

MVP (Model-View-Presenter) to the rescue! Well, at least for those times 😊

MVP emerges as a solution to the limitations of MVC, where the Presenter acts as an intermediary between the View and the Model. Notably, the Presenter is not aware of which View is receiving the information from it, ensuring loose coupling and enhancing the maintainability and extensibility of the application.

MVP data flow.

Key Components of MVP

1. View: In the MVP architecture, the View takes on the responsibility of rendering the user interface (UI) exclusively. It focuses solely on UI-related tasks, such as displaying information and capturing user input. By isolating UI concerns, the View becomes more lightweight and focused.
2. Contract — Interface: MVP employs an interface that acts as a contract between the View and the Presenter, facilitating loose coupling. This interface defines the methods that the View exposes to the Presenter, enabling seamless communication between the components.
3. Presenter: The Presenter serves as the glue that connects the View and the Model. It acts as the mediator, facilitating interactions between the UI and the business logic layers. The Presenter triggers business logic classes, prepares data for the UI, and orchestrates the flow of information between the View and the Model. By moving non-UI-related code out of the View and into the Presenter, the application achieves cleaner and more maintainable code.
4. Model: Similar to MVC, the Model in MVP handles data and business logic. It serves as a data provider, responsible for tasks such as database updates or remote server communications. By separating the data and business logic layer from the UI, the Model ensures a separation of concerns and improves code organization.

Let’s get it coded! We’ll create a small sample project to demonstrate how MVP can be implemented. This will be a simple movie app that shows list of top 10 movies of all time.

Model: A simple data holder class that will keep the list of top 10 movies (for the sake of simplicity, we’ll keep the list in an ArrayList. We can just consider it as a response of an API request or a local DB query.)

Model.kt

View: the UI side just contains a RecyclerView that will show the list of movies.

Presenter: This is the fun part. The View and the Presenter are connected by abstraction. This connection is made using a Contract.

Contract between View and Presenter.

Presenter in MVP.

Once the user requests for the list of movies, Presenter will fetch it from the Model and provide the View with the appropriate data: Here’s how it looks like:

Activity class in MVP.

You can find the full sample code here.

As everything, MVP has it’s own drawbacks as well:

— There’s a one-to-one relation between View and Presenter. In other words, you’ll have Presenter for every single Fragment/Activity. This will lead to have lots of Interfaces.
— Presenter is not lifecycle aware. You have to handle the data in case the Activity is destroyed, depending on your will — whether you want the data to be saved or lost.
— Updating UI; The view can not listen the Model updates to react accordingly.

That’s it for MVP. Thanks for reading and feel free to leave your feedbacks in the comments 😊