Simplifying Android Architectures for Developers — MVC, MVP, MVVM, Clean, MVI, VIPER — part 2: MVP
MVP
Theory
I think that architecture really works at the theory and the practice in Android Development.
It stops understanding only .xml files as a view. It makes sense because a .xml file is not capable to show anything, it is dependent on an Activity or Fragment. But the difference regarding MVC, here an Activity or Fragment is considered as a View, so it can only (or almost only) call for methods to refresh UI, or request something from the presenter.
The android lifecycle is based on Activity/Fragment, so beyond call view methods like showSomething or hideSomething, we have to handle some default events. Is really common to instantiate the presenter at onCreate, and release the presenter at onDestroy
In this Architecture, we have 3 layers too.
Model (Exactly like in MVC)
The model contains Databases, business rules, and access to external resources.
View: This layer is responsible to update UI and receiving UI triggers like a user click, or some life cycle event, and requesting information from the Presenter Layer.
Presenter: This layer is responsible to connect the data layer, requesting information, and returning information to the view layer. Maybe this could appear unnecessary if you think about our model as a synchronous data provider, that provides data from the memory, but usually model provides data asynchronously, so some layers have to care about questions like :
What is supposed to happen when the user cancels a request?
What is supposed happen if a request fails?
Who checks if the application should show a kind of empty screen?
So this application logic is on the presenter layer.
If you see something like this in the view layers, maybe your activity no behaves only like a view:
WrongViewActivity.kt
Instead of that, you should move that kind of logic for your presenter, then call a specific method from the view. A view with many ifelses maybe is not behaving only like a view.
RightViewActivity.kt
RightPresenter.kt
Is important to know the presenter layer can not be dependent on any android library. So the presenter can not know what property visibility means, that is a view layer responsibility.
Practice
Model
I will skip this layer because this is exactly like what was implemented in the previous article (part 1) where a talked about MVC.
View
Like I told you, the presenter layer can not know android libraries. So we have to create an interface to be implemented by our view.
So our view has to implement that interface, create an instance of our presenter, and send to that presenter our view.
Presenter
I created an interface to be implemented by my presenter. This is a good practice: When you have to establish a dependency between modules, depending on an interface is better than depending on implementation. It makes you free to replace your module for another module, and since that module implements the same interface, your system will keep working.
You can check this project on GitHub. Remember to select the architecture that you wish to study on the build variants:
Simplifying Android Architectures for Developers — part 1: MVC
Simplifying Android Architectures for Developers — part 2: MVP
Simplifying Android Architectures for Developers — part 3: MVVM
Simplifying Android Architectures for Developers — part 5: MVI
Simplifying Android Architectures for Developers — part 6: VIPER
