MVP, Dagger — The Memory Guards of Android

**Disclaimer ** — It’s not going to be a code lab type blog , with this you might not be able to code MVP and dagger but if even if you have some experience in MVP and Dagger, it won’t take you more than a while to figure out the power and beauty of the combination!

MVP

MVP (Model View Presenter) pattern is a derivative from the well known MVC (Model View Controller). The MVP pattern allows separate the presentation layer from the logic , so that everything about how the interface works is separated from how we represent it on screen. Ideally the MVP pattern would achieve that same logic might have completely different and interchangeable views.

MVP is not an architectural pattern , it’s only responsible for the presentation layer . It’s how you can divide the business logic and the user interface layer into different layers.

The reason why we use MVP is because of the power, extensiblity and reliability it provides for building a large application. It helps us divide the logic , be it UI or be it business logic and help unit test them without much effort.

MVP makes views independent from our data source. We divide the application into at least three different layers, which let us test them independently. With MVP we are able to take most of logic out from the activities so that we can test it without using instrumentation tests. It has the following parts

Model

In an application with a good layered architecture, this model would only be the gateway to the domain layer or business logic. In simple terms if you want to fetch data from network or get it from SQLite you can easily achieve it from the model layer and it will also help you in unit test it so you will be confident that the data layer is working fine.

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. Don’t get confused by the middle man phenomenon in simple words you can call it that presenter is responsible for the communication between the model and the view. The view cannot interact with the model directly and vice-versa. Hence presenter helps them interact and do the required using callback mechanism etc.

View

The view is usually implemented by the activity or fragment which contains a reference to the presenter so the interactions can be done between view and model.
You can have different methods which will be triggered from the presenter layer and similarly view will be responsible for triggering presenter actions. The sole thing that the view will do is calling a method from the presenter every time there is an interface action (a button click for example).

Now its pretty obvious that we would be instantiating the model, view and the presenter. But we need to control the instantiation and memory leak so our application remains memory efficient, to do this we need use the power of Dagger.

Dagger — The True Memory Guard

Dependency Injection is a practice where objects are designed in a manner where they receive instances of the objects from other pieces of code, instead of constructing them internally. This means that any object implementing the interface which is required by the object can be substituted in without changing the code, which simplifies testing, and improves decoupling.

Dagger 2 is dependency injection framework for Android. It helps you forget all the dependencies instantiation so the probability of memory leakage is minimum. I know you would be feeling puzzled after reading it but hang on the below annotations will make it more clear.

• @Module and @Provides: define classes and methods which provide dependencies
• @Inject: request dependencies. Can be used on a constructor, a field, or a method
• @Component: enable selected modules and used for performing dependency injection.

Now some screen casts will clear the rock in your mind about combining these two powerful tools.

Architecture of application using dagger

Application Component and Application Module

App Module, showing how you can provide a single retrofit instance in your whole application with the help of @Provides and @Module annotation.

This is how a component is built and the modules are added as a part of the component. Anything required from other parts of app can be accessed through the getters made in the component.

Activity Component and Activity Module

Activity Component, the inject method instantiates all the resources that have been instantiated in the modules at the place where inject method is being used.

App Module, it helps us in providing the Model, View and Presenter.

Thus looking at the pictures from top to bottom you can understand how you can make the model, view and presenter available accordingly without circular dependency at the required places of execution. The @Provides annotation not only helps you in instantiation of several resources but you can pass them in other resources constructors by injections which will minimize the possibility of memory leak in application.

I will conclude this blog for now otherwise it won’t really be a blog, feel free to leave comments if you want any sample of the above architecture. I will be posting a GitHub sample very soon. The next part will cover combining the touch of Rx-Java into the blend of the these awesome two! Thanks for reading! Clap it , if you find it useful!

Asheesh Sharma