MVP architectural design pattern with reactive Rx in android

This article is a step-by-step introduction to MVP on Android, from a simplest possible example to best practices. The very first question comes in every developer is that what is MVP?

What is MVP: MVP stands for Model View Presenter. Let’s see what is meant of each aspect?

View: View is a layer that displays data and reacts to user actions. On Android, this could be an Activity, a Fragment, an android.view.View or a Dialog. View also represents the user interface component like Button, TextView etc. View displays the data from the model and also change the model from the user interface.

Model: Model is a data access layer such as database API or remote services API. A model represents the collection of classes that represent the business model and data model. It means that how the data can manipulate.

Presenter: Presenter is a layer that provides View with data from Model. The presenter also handles background tasks. It processes the view action of the user and makes the change into the model. Here there is the direct communication from model to view and vice Versa.

Why MVP: This is a very basic question that comes to everyone mind. Yes off course without knowing the reason why should I use this design as an architectural level in Android application developments. Ok, that’s fair enough, So the reason is very simple to start using MVP with. Ok, Let’s focus on two basic things.

  1. Keep the Design and Communication of each component is simple
  2. Managed Background Task and removed callback

Let’s discuss in detail this two reason that encourages us to start using MVP while building the Android app.

When We look above old design architecture, It seems like that every thing connected with every thing. A programmer is confused and involved in the fight with View complexities instead of solving business tasks.

OK Some how the diagram is not too complexed that’s Ok, But think again when view appears and disappears frequent and random and add few background tasks then manage to restore and store view. Then it will be very difficult to manage. A developer has only stuck to understand the view hierarchy complexity rather than focus on business logic which he wants to develop or implement.

After all the scenario the result comes that it is so complicated to resolve. Most of the part can not able to test and debug proper. Now let’s focus on MVP.

With MVP complex task has divided into multiple tasks. Let’s look at above diagram it is very clear that the only presenter is the mediator whose has responsible to communicate with view and data. No any direct communication with data to view. Here every module has a unique presenter to communicate for data to view or vice versa.

A developer can easily add the implementation and test the result easily. Overall the result will be Smaller objects, fewer bugs, easier to debug and Testable. View layer with MVP becomes so simple, so it does not even need to have callbacks when requesting for data. View logic becomes very linear.

Ok Let’s talk about the background task, In the old pattern, every activity or fragment or custom view has connected with a background task. Background task always running with multiple threads, for example, Async Task, it is running half part with a separate thread and remaining part with the main thread. In this case, chances will be the memory leak because some time process is killed because of memory low.

Or in other words, If a user flips the screen often this will cause memory leaks – every callback keeps a reference to MainActivity and will keep it in memory while a request is running. It is absolutely possible to get an application crash because of out-of-memory error or a significant application slowdown.

But in MVP all the background task and business logic will handle inside the presenter. It makes life easy because presenter only delivered the data to view when the view is alive or subscribed. The chances of memory leak will be very less. There are many reasons of memory leak, it generally happened with bad code practice. A developer should understand the good code practice. Here you can detail Why need to take care memory leak?

Let’s see the simple example of MVP.

First of all, we need to create the base contract to define the MVP. Here we need to create the two interface one for a presenter and other for a view.

Now this base contract will be connected with each module. For example, I am defining the for KickStarterDetail Contract to show the detail of each item of recyclerview. here I want to show the data of this item from DB and show at a view.

Let’s create the Presenter to handle this request. All the business logic should be here. I mean in this example fetch data from DB and give it to view.

In Fragment, it will take this data and show at the view. It is very simple and separates each and every thing. In the future, if it changes the business logic then I have to check the presenter class and modify it. It will not be so complex because I am not touching the view part.

Here do not be confused I used a database of GreenDao ORM. If you need to get the detail of GreenDao then get the detail from here Exploring GreenDao database with reactive Rx.To understand the reactive Rx I would be recommended to check these posts of understanding of Java 8 stream and Rx Observables, and basic understanding and practice features and functions of RxJava, and understanding practice RxJava with RxBinding in Android.

I also used the dependency injection Dagger2 in above example. I would recommend to checking this post in Kotlin Dagger2 dependency injection.


MVP is the best architectural based design pattern. It provides the best code practice, easy to use and maintenance and easy for the JUnit testing and debug for a developer. Developers should always flow this sequence user -> view -> presenter -> model -> data sequence to avoid the complexity of code.  You can build an awesome Android application by using MVP design pattern with Reactive nature.  Here is the Github of full source code for practice more.

Please do subscribe email to get every newsletter of this blog and if you feel that this post will help you to better understand then do not forget to subscribe, share and comment below.

Happy coding 🙂

Sunil Gupta

I am a very enthusiastic Android developer to build solid Android apps. I have a keen interest in developing for Android and have published apps to the Google Play Store. I always open to learning new technologies. For any help drop us a line anytime at

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.