Skip to content

MVP in Android - A Summary

September 14th, 2015 - IT(1 min)

These days I’m reading on architectures. I had a look at MVC, MVP, MVVM and how they are applied (adapted to?) to Android applications. Here are some short points about MVP.

Model-View-Presenter has been adapted to Android and is advocated by more experienced people than I. It is interesting to note that in the Clean Architecture approach, MVP is only taking care of the presentation layer.


In the Clean Architecture, the model is .However, given the magnitude of most applications, at least the Model part is more involved. Most code I’ve seen maps the model over the ORM POJOs, network and persistence communication (how to build and keep the objects). Therefore, we can simplify things and view the model as the provider of data.

Testing: The model should be normally tested with JUnit plus mockito for unit tests. If however you place persistence and networking… well, you can use the U2020 approach and create mocks via dagger.


The presenter is the middleman between the model and the model. You can look at it as a necessary step to isolate the two; it provides the data formatted for the presenter but also contains logic to implement presenter actions. The idea is that a view just calls presenter methods to retrieve data and perform actions.

The presenter contains references to models and views. In a clean implementation, these references are to interfaces, not actual implementations.

Testing: By design, the presenter contains behaviour which can be tested mocking both data and views. One should be able to avoid android instrumentation altogether when testing presenters.


The view is the actual UI. It can be an Activity , a Fragment or a View and it contains a reference to the presenter. As noted above, it should be designed as a shell with all meaningful logic in the presenter.

Testing: UI testing requires android instrumentation. Though, but necessary.


Generally, MVP, MVVM are associated with improved testing capabilities and cleaner code (particularly when helped by e.g. injection libraries).

I’ve seen things separated in MP|V because code can be designed so only the view testing is done with android instrumentation.

I guess the burning question is:

Is it worth it?

AS-generated login activity has 1 class while Antonio Leiva’s login part has (at the time of writing) 7+ classes and interfaces.

Share on

A little experiment: