The Model View Presenter pattern is an architectural pattern based on the Model View Controller (MVC) pattern that increases the separation of concerns and facilitates unit testing.
It creates three layers, Model, View, and Presenter, each with a well defined responsibility. The MVP pattern separates the data model, from a view through a presenter.
The Model
Accommodating models (POJO class), data from various sources (database, server results, cache, Android file system, etc.).
The View
View is responsible for visual display of applications, along with data input by users. This part should NOT under any circumstances process the data. Its function is only to detect the input (e.g. touch or swipe) and visualization.
The Presenter
Presenter is responsible for passing of data between two layers, and thus the analysis and interaction. Such division allows substitution of code parts, proper testing and connects layers as interfaces.
Android MVP Guidelines
- Activity, Fragment and a CustomView act as the View part of the application.
- The Presenter is responsible for listening to user interactions (on the View) and model updates (database, APIs) as well as updating the Model and the View.
- Generally, a View and Presenter are in a one to one relationship. One Presenter class manages one View at a time.
- Interfaces need to be defined and implemented to communicate between View-Presenter and Presenter-Model.
- The Presenter is responsible for handling all the background tasks. Android SDK classes must be avoided in the presenter classes.
- The View and Model classes can’t have a reference of one another.
Having covered the theory of MVP architecture, let’s build an android MVP app now. I have developed a very simple application to demonstrate MVP. When user click ‘Tap me’ button, I am showing “Hello, Kotlinzers!!!” popup message,
We have to create 3 packages such as model, presenter, view.
When to follow MVP design pattern ?
MVP makes it easier to test your presenter logic and to replace dependencies. But using MVP also comes with a cost, it makes your application code longer. Also as the standard Android templates at the moment do not use this approach, not every Android developer will find this code structure easy to understand.
Model Layer
The Model layer is responsible for handling the business logic. It holds an popup message shown to the user, and a reference to the Presenter.
We have to create IBaseView.kt & IBasePresenter.kt interfaces to implement to communicate between View-Presenter and Presenter-Model.
interface IBasePresenter {
fun clickMe()
}
interface IBaseView {
fun clickSuccess(text: String)
}
Let us implement IBaseView interface in Activity,
Because Android doesn't permit the instantiation of an Activity, the View layer will be instantiated for us. We are responsible for instantiating the Presenter and Model layers. Unfortunately, instantiating those layers outside the Activity can be problematic.
It is recommended to use a form of dependency injection to accomplish this. Since our goal is to concentrate on the MVP implementation, we will take an easier approach. This isn't the best approach available, but it is the easiest to understand.
Because Android doesn't permit the instantiation of an Activity, the View layer will be instantiated for us. We are responsible for instantiating the Presenter and Model layers. Unfortunately, instantiating those layers outside the Activity can be problematic.
It is recommended to use a form of dependency injection to accomplish this. Since our goal is to concentrate on the MVP implementation, we will take an easier approach. This isn't the best approach available, but it is the easiest to understand.
I have shared this source code on GitHub
