MVP Architecture in Android Development

Story Behind This Post

Kenju Wagatsuma
Dec 20, 2015 · 7 min read

Recently, the more and more Android developer seem to discuss about the architecture. So do my colleagues and engineers around me. Though I did not know much about MVP and DDD, our new project was decided to built on MVP architecture.

This post is what I have researched and learnt from various posts and discussions, including:

  • Why more and more people are talking about the architecture?
  • What is MVP, in the first place?
  • MVC, MVVM or MVP? Which one is the best?
  • Pros and Cons of MVP
  • Show me the code!!!

And, here is what this post does not include:

  • Lively sample codes in details
  • How to write testing code

In the end, I will tell you further readings for those topics.

By the way, I gave it a talk at a local workshop about the MVP architecture last week. This post is meant to correspondence with the talk as well.

Introduction ~ Activity was God ~

First of all, let us talk about the root problem why the Android Development has raised the necessity for the clean architecture.

Here is an excerpt from “Code Complete 2nd Edition”:

Avoid creating god classes Avoid creating omniscient classes that are all-knowing and all-powerful. If a class spends its time retrieving data from other classes using Get() and Set() routines ( that is, digging into their business and telling them what to do ), ask whether that functionality might better be organized into those other classes rather than into the god class ( Riel 1996 ).

The God Class is hard to maintain, understand what is going on, execute unit testing, expand in enhancement phases, etc. This is the golden rule to avoid creating god classes.

However, in Android development, the Activity classes tend to be bigger and bigger, if you do not care too much about the architecture. This is because, in Android, the View and other threads can coexist in Activity classes. The biggest problem? The business logic and UI logic coexist in the Activity classes. This leads to the difficulty of unit testing or maintainability.

Activity is god

This is one of the reasons why the clean architecture was needed. Not only the enlargement of Activity classes, there are other problems like complicated lifecycle among Activity and Fragment classes, the data binding, and so on.

What is MVP?

MVP stands for Model, View, and Presenter.

  • View is a layer which handles all user actions and displaying each view parts. On Android, this could be Activity and Fragment classes.
  • Model is a layer which is in charge of data accessing. Data is, for example, remote server API, local database like SQL, SharedPreferences, and so on.
  • Presenter is a layer which bridges ( or adapter ) data between View and Model patterns.

The below image shows one of schemas based on MVP architecture. View is UI Threads. Presenter is the adapter between View and Model. UseCase, or domain layer, is in the Model layer, which gets or puts all data into entities. The dependency rules applies here ( this is described in the next chapter ).

The Dependency Injection

The key point is that, the higher interfaces do not know about the lower ones, or more precisely, the higher interfaces cannot, should not, and must not know the details about the lower ones. Yes, Information hiding.

The higher interfaces do not know about the details of the lower ones

The Dependency Rule?

Uncle Bob’s “The Clean Architecture” describes really well about what the dependency rule is.

The concentric circles represent different areas of software. In general, the further in you go, the higher level the software becomes. The outer circles are mechanisms. The inner circles are policies.

Here are the excerpts from the above post:


  • can be an object with methods
  • can be a set of data structures and functions
  • does not matter so long as the entities could be used by many different applications in the enterprise

Use Cases

  • contains application specific business rules
  • orchestrate the flow of data to and from the entities
  • direct those entities to use their enterprise wide business rules to achieve the goals of the use case

Presenters, Controllers

  • convert data from the format most convenient for the use cases and entities,
  • to the format most convenient for some external agency such as the DB or the Web
  • wholly contain the MVC architecture of a GUI

External Interfaces, UI, DB

  • is where all the details go
  • such as the DB, the Web Framework, etc.


Then which one is the best? Which one is superior to others? Should I choose the only one from the others?

The answer is, No.

The motivation of these patterns are the same. How to avoid complicated spaghetti codes, let it easy to execute unit testing, and create the higher-quality app. That’s it.

Of course, there would be much more patterns beside those three ones. Each one of them is not silver bullet nor the only answer. They are one of methodology. One of solution to the problems. Do not turns means to purposes.

Pros and Cons

Okay, let us go back to the MVP architecture. For a while, we have seen what the MVP is, why the discussion over MVP or other architecture is hot now, and what are the differences among MVC, MVP and MVVM. Here we summarize the pros and cons of the MPV architecture.


  • Testable ( leading to TDD )
  • Maintainable ( Code reuse )
  • Easy to get reviewed
  • Information Hiding


  • Redundant, especially when the app size is small
  • Extra learning curve( maybe )
  • Requires time before starting coding ( but I bet, the architecture step is the must step for all development )

Show me the code!!!

Here is showing only the minimal structure of MVP patterns. If you would like to see much more examples or lively examples, please refer the “Links and Resources” chapter at the end. There are much more plentiful and well-designed examples, basically hosted in Github so that you can clone and see how it works on your devices.

First of all, let define the interfaces of each views.

Let us override the TopView class. The key point here is:

  • TopActivity only handles event listeners or displaying each view parts
  • All business logic must be delegated to the Presenter class
  • In MVP, View and Presenter classes are declared 1 on 1 ( in MVVM, it is 1 on some )

Here is the Presenter class. The most important thing is that, the presenter only adapter between model and view. For example, what the `TopUseCase#saveCalendarDate()` does is hidden to TopPresenter, so does TopView. You do not have to care about what the data structure is and how the business logic works. Therefore you can execute unit testing of TopUseCase, because the business logic is separated from View layers.

Yes, you can of course execute unit testings even though the business logic is implemented in Activity class… but this requires much more time and complexity. It may take much more time to run the app. Rather, you should make full use of the power of unit testing library like Robolectric.


There is no silver bullet, and, MVP itself is just one of solutions. It can be mixed with other methodology, and at the same time, it can be selectively used for each projects.

Links and Resources

The Clean Architecture by Uncle Bob

This is a post by Uncle Bob, describing what the dependency rule is, and how the each components work among them. The graph from my talks at the beginning was inspired by his post. Though this is not written focusing on Android Development, as always, his words implies a lot and well-organized. Must-read one.

Architecting Android…The clean way? by Fernando Cejas

I think this is the most famous and popular blog post explaining how to incorporate the MVP architecture into Android Development. I also came across the word ‘MVP’ from his easily-readable and well-written blog post. His sample code on Github should be cloned by every Android developers who want to know how the MVP architecture works in the real app.

Android Architecture by Thanos Karpouzis

A simple guid for MVC, MVP and MVVM on Android projects. I learnt a lot from his plain but widely-covered post, especially the differences among MVC, MVP and MVVM.

Software Design patterns on Android English by Pedro Vicente Gómez Sánchez

This is a talk from Senior Android Developer at Karumi, which is explaining from some design patterns ( e.g. Renderer Pattern, Repository Pattern and Command Pattern ) to MVP architecture. If you want to broaden your research over MVC or MVP, this is the one you are looking for.

M — Model in MVC, MVP, MVVC in Android by Artem Zinnatullin

If you are misunderstanding JSON or SQL with the Model layer, or do not get the precise image about what the Model layer is, this post leads you to the further understanding about what and why the Model layer is separated from others. The “Model layer is solution” section is especially great for showing the real example how you implement your code from interfaces to testing.

KJ is a Software Programmer Based in Tokyo. Programming, Teaching, and Singing with his Acoustic Guitar is his passion. Currently Android Developer@Recruit_PR, Former @LifeisTechInc — Link: About Me, Twitter, GitHub