Model View Presenter (MVP) in Android,Part 1

4 min readMar 4, 2016

Architecture Pattern is a fundamental part of computer science. It’s the only way to maintain a project clean, expansible and testable. The patterns are recognized solutions that has been developed over the years and are considered industry standards. They’re constantly evolving, and in the Android SDK, the reliable Model View Controller pattern are steadily being dropped for the Model View Presenter.

In the first part of this article we’ll discuss the principal differences between MVC (Model View Controller) and MVP (Model View Presenter), why MVC is being dropped, how MVP adjusts it to Android SDK and its greatest advantages.

The Android SDK

When we briefly analise the Android SDK, specially the relations between layout x activity x data, we have the impression that the pattern that best suits Android is the Model View Controller (MVC). However, when the project gains complexity, the separation of concerns offered by MVC isn’t enough, specially to realize unit tests.

Yet, the way that the Android SDK was planned, allow us to use other types of architecture patterns, including no pattern whatsoever, the so called anti-patterns. Even that MVC is a reliable and well known solution, it’s losing ground for his younger brother, the Model View Presenter (MVP), that offers some advantages, like a more well defined separation of concerns.

Should I use MVC or MVP in my project?

There isn’t exactly a correct answer for this question. Some people will believe that MVC is the solution, others will stand with MVP and some will point towards another solution, like MVVM for example. Each one of these approaches have advantages and disadvantages. Which means that the only way to answer the question is to understand the pros and cons of each solution, so you can make your choice wisely.

Model–view–controller (MVC) is a software architectural pattern mostly (but not exclusively) for implementing user interfaces on computers. It divides a given software application into three interconnected parts, so as to separate internal representations of information from the ways that information is presented to or accepted from the user.
wikipedia
Model–view–presenter (MVP) is a derivation of the model–view–controller (MVC) architectural pattern, and is used mostly for building user interfaces.
In MVP the presenter assumes the functionality of the “middle-man”. In MVP, all presentation logic is pushed to the presenter.
wikipedia

MVC vs MVP

Differences between MVC and MVP

Model View Presenter

View more separate from Model. The Presenter is the mediator between Model and View.
Easier to create unit tests
Generally there is a one to one mapping between View and Presenter, with the possibility to use multiple presenter for complex views

Model View Controller

Controllers are behavior based and can share multiple views.
View can communicate directly with Model

Model View Presenter (MVP) on Android

Android’s separation of concerns isn’t well defined. The Activities for example, have a too close relationship with data mechanisms. Although, for an application to become expandable, maintainable and testable, it’s extremely important to create a deep separation of concerns and this is probably the biggest advantage that we’ll get with the MVP adoption.

Layer relations in a Android’s Model View Presenter pattern

Best way to implement the MVP pattern

This is actually a blurry topic. There are many interesting approaches towards the MVP and also a lot of different solutions to adapt it to Android. The way which the pattern is implemented, varies according to the role assumed by the Presenter. But independently of the choice, the MVP core should be preserved:

Presenter
The presenter is responsible to act as the middle man between view and model. It retrieves data from the model and returns it formatted to the view. But unlike the typical MVC, it also decides what happens when you interact with the view.
View
The view, usually implemented by an Activity, will contain a reference to the presenter. The only thing that the view will do is calling a method from the presenter every time there is an interface action.
Model
In an application with a good layered architecture, this model would only be the gateway to the domain layer or business logic. See it as the provider of the data we want to display in the view.
These excellent definitions above were extracted from Antonio Leiva’s article.

On the next article of this series, we’ll implement the Model View Presenter pattern on Android. We’ll follow a more conservative path, using only canonical code, without any libraries from outside the Android SDK. This approach will help to understand the different relations between the MVP’s layers.

If you want to check the final MVP framework, that was based on Dr. Douglas C. Schmidt vision, by all means do. You can also check it out the awesome Mosby library.

See you soon!

References: