In last chapter, we talked a little bit about the basic concepts of MVP and how to implement it. And also there is a simple framework provided at the end of article for your convinient.

Coincidentally, one of the Android projects in my company is looking for a great solution to solve their problems:

• Currently, their business logic is so deeply coupling with UI. They are using fragment to display UI, but now most of the fragment has more than 2000+ lines code due to the business logic messed up here
• They don’t have consistent way to persist the data to survive from the storm android system recycled resources
• No standard rules for programmers to follow up when dealing with UI related staffs

After I heard their pain, the MVP pattern was the first one I want to share with them and encourge them to use. So here is the topic I am trying to record when I’m commencing to bring the MVP pattern into it.

The implementation we provided in last chapter is good, but very basic and not enough to handle the situations they have now. To solve it, I have below things to setup:

1. Create base classes for each role of MVP
2. Provide a common standard way to persist the data(maybe we could use saveInstanceState that’s provided by Android)
3. Bind MVP with the real UI implementation.

MVP Enhancement

M - Model

Android provids a good way to persistent model when the storm is coming which we called onSaveInstanceState(Bundle). So we can use this way to help persistent the model data, but the limitation is Model object must be Parcelable or Serializable. However, you can also define your own persistent way as long as you defined your action when the onSaveInstanceState(Bundle) is triggered.

To be more structive, let’s define a interface for persistent actions.

Following a default implementation which supports both Parcelable and Serializable as mentioned.

You also also use your own customized way.

MVPDelegate

In last chapter, we defined a MVPDelegate to help bind the lifecycle for Model-View-Presenter(which you can also use modern way Dagger to make it). So we can reuse it to bind the onSaveInstanceState(Bundle) lifecycle.

V - View

Bascially, we are using Activity or Fragment to display our UI in Android. So let’s define some base classes to help us easilly access the M and P.

In BaseActivity, there is instance of MVPDelegate to bind the lifecycles for each other, and also provides the ability to customize your own ModelSerializer.

BaseFragment is simliar

Usage

Okay, now you get everything ready for your MVP framework for Android. It’s time to use it in your real project!

Assume there is project that needs to calculate the PI value(Get user’s input as term). Lets see how we make it.

Firstly, we need to create the contracts for our goal. One is the base view we want to represent: showToastMessage(String), and another one is the behavior of related presenter: calculatePI(long).

Secondly, Create a real UI implementation that we are using Activity to display in this case. Note: In this case, there is no data we have to persistent, so we use Void to replace the Model.

Thirdly, it’s the presenter which has been decoupled perfectly from the UI detail.

Conclution

MVP is just a concept which is not an architecture pattern, but really help if you want to seprate the presentation layer from the logic which means decouple your business logic from the real UI itself!

You can get the full example on my Github.