MVP

Android Model-View-Presenter(MVP) Definition

MVP is a architectural pattern, and is to used mostly for front end. It has three main parts:

• The model should be a simple Java object (pojo), is used to store data to present to user.
• The View is used to display data to user. It should be a passive view.
• The Presenter acts upon the model and the view. It has references to bold model and view.
• 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):

• Android View: Just an Android component, something that extends from android.view.View
• 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.
• 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.
• 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.