Android Model-View-Presenter(MVP) Definition

MVP is a architectural pattern, and is to used mostly for front end. It has three main parts:
1. The model should be a simple Java object (pojo), is used to store data to present to user.
2. The View is used to display data to user. It should be a passive view.
3. The Presenter acts upon the model and the view. It has references to bold model and view.
4. Above, we have definition of MVP but I have one thing to clarify here. MVP is used only for presentation layer, and it needs to delegate another work to another layer for business logic and data loading. It means that we should not do any heavy things in Model, View or Presenter or MVP should be simple. I prefer Clean Architecture for my Android application. You can look at it here: Clean Architecture

For Android, We have some other definitions: (Thanks Christian for his great article):
1. Android View: Just an Android component, something that extends from android.view.View
2. View: The view interface to communicate from your presenter to your view implementation, it can be implemented in your preferred Android component, sometimes is better to use an Activity others a Fragment or maybe a Custom View.
3. Screen: A screen is more a user concept, the user gets the feeling that the phone is navigating between windows, but we can represent this in Android with Activities or replacing fragments/views in the same Activity. So it depends on the perception that the user gets and usually represents all the content that you can see in the view.
4. MVP Component(or MVP): A pair of View and Presenter.

Why MVP?

  • Avoid spaghetti code: We used to do everything in Activity and make it like a god object. It is really hard to work with.
  • Separation of Concern: Our classes are smaller and have fewer responsibility.
  • Testing: With MVP each class has each own responsibility and isolate from each other. So we can test them easily.
  • Scale and flexibility: MVP give us power to update/add/remove/reuse a feature without effect another feature by MVP composition.

MVP Best Practices

With these definitions, We have some best practices below:

MVP Responsibility

  • Activity, Fragment or Android View should be treat as a dumb View.
  • View is passive view so it should only do things that Presenter tells it to do.
  • View is responsible for animation.
  • View is responsible for handle UI events and delegate them to Presenter. Presenter is responsible for processing these UI events.
  • Presenter should have no knowledge about Android. It should be pure Java so We can test it easy.
  • View and Presenter should not know internal implementation of each other. They should talk via interfaces.

MVP Composition

  • One View should map to one Presenter to be come a MVP component. And View usually holds the reference to its Presenter.
  • One MVP should contains only one business logic.
  • We should not map one screen as one MVP. Some time it is fine for example you treat your Splash screen as a MVP or some other simple screens.
  • Most of time we should separate one screen to multiple MVPs. For example, usually one screen has a Toolbar view and a content view. We can see that those views have different functionality. So we need one MVP for Toolbar view and one MVP for content view.
  • In some cases, there is a business which needs several screen to finish it works. You can image a complicated registration process, so user needs to use multiple screens to finish this process. In this case, we need only one MVP for those screens. It is easy to maintain data between screens and we can reuse it on larger screen where can group those screens into one. So that we just keep our logic from how views are implemented.

Conclusion

Follow MVP and its best practices, our life will definitely happier. So let’s start using MVP and you will start to loving it.

I gave a talk about Dependency Injection on last weekend and It was my first public speaking ever. I want to say thanks to anyone who attended this talk, you guys was my big support, thank you so much. But for lacking of experience my talk was not smooth and did not give you— my listeners enough information about dependency injection as well as Dagger 2 library. So I decided to write this blog to correct my fault.

First of all, I forgot to talk about why Dagger is named as Dagger. Actually it is coming from DAG which stands for directed acyclic graph. So we know Dagger is a directed graph without any cycle. So we cannot create a cycle dependency when using Dagger, it will throw exception in compile time. For example we can not create something like: A dependents to B, B dependents to C, and C dependents to A. It is a cycle dependency, we should avoid it when using Dagger.

Because of time constraint, I could not walk throw how to add Dagger to your project. So I just created a small gist about dagger 2 configuration with comments. You can see it here: Dagger 2 Configuration.

The last thing I want to mention is I have learned a lot of things after the talk. I have better understanding about dependency injection as well as Dagger when I preparing for the talk. So that sharing and talking is one of the best way to learn and hope it is the same for everyone. Thank you again for attending and listening.

Materials of the talk:

Slide

Dagger 2 Example