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 have 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 is steadily being dropped for the Model View Presenter.
In the first part of this article we’ll discuss the main differences between MVC (Model View Controller) and MVP (Model View Presenter), why MVC is being dropped, how MVP adjusts 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, allows us to use other types of architecture patterns, including no pattern whatsoever, the so called anti-patterns. Even though MVC is a reliable and well known solution, it’s losing ground for its 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 tend 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.
[expand title=”Model-View-Controller (MVC) definition” tag=”h5″]
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.
In MVP the presenter assumes the functionality of the “middle-man”. In MVP, all presentation logic is pushed to the presenter.
Differences between MVC and MVP
Model View Presenter
- View more separated 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 Presenters 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.
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:
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.
The View, usually implemented by an Activity, will contain a reference to the presenter. The only thing that the view will do is to call a method from the Presenter every time there is an interface action.
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 in 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.
See you soon!
Also published on Medium.