Use of the "Android-frame" MVP mode

By bringing up the MVP architecture model, you might first think of its "predecessor" MVC pattern. MVC consists of model, View, and controller, requesting business judgment from the controller and then handing it over to model or view. This itself is nothing, but when applied to the Android program, you will find that the activity has served as the controller's role in the business screening, as well as the role of the view to display the interface, and sometimes as a model of the role of loading data. This causes the code in the activity to become much longer, and the functionality is messy and inconvenient to differentiate. What do we do? As a result, the MVP model was born.

MVP is composed of model, view and presenter, similar to MVC, the model layer of the MVP is also used to load the data, the view layer is used to display the interface, the MVP of the unique presenter is used to connect the model and view two layer, act as a decoupling function. Shows the comparison between the MVC pattern and the MVP model's workflow:

As you can see, there is no connection between the view layer and the model layer in the MVP mode, that is, there is no direct correlation between the two layers, and the interaction between them is done through presenter, thus decoupling the view and model two layers. The specific MVP internal workflow is as follows:

You can see, the user first in the view layer operation, the user action into the presenter, presenter the action passed to the model for processing, and then pass the processing results back to presenter, and then by presenter corresponding to the view.

The overall architecture of the MVP model is built through interfaces, we need a holistic architecture management class contract to manage the three interfaces of model, view, presenter, and the model, view, and presenter classes implement these three interfaces respectively. Presenter holds the model and view references, all methods in the presenter call the corresponding method in the model to be processed; the actual code is written in the model; The view is implemented by the activity, which holds a presenter reference, All methods will call the corresponding method of presenter.

A simple demo code is posted below.

The demo interface is very simple, there is only one button, when we click on the button to pop a toast, is such a simple demo, we try to use the MVP mode to build, write.

First we need an interface of the unified management class Maincontract, this class contains M, V, p three interfaces, the interface defines the abstract method. Here we are only going to have a method, i.e. button click event onbuttonclicked () method. The code is as follows:

 Public class maincontract {    interface  View {        void  onbuttonclicked (String text);    }     Interface Model {        void  onbuttonclicked (context context, String text);    }     Interface Presenter {        void  onbuttonclicked (context context, String text);}    }

With the interface, we let the M, V, p three layer concrete class to implement these three interfaces, the three classes are: M layer corresponding to the MAINMODEL,P layer corresponding to the MAINPRESENTER,V layer corresponding to mainactivity.

Let's write the code in the Mainpresenter class, first we need to make it implement the presenter interface in the Maincontract class, and then set two properties for it, one is model, one is view, a view is passed in the constructor, and the model is initialized, Finally, the method in the presenter interface is implemented and the corresponding method in model is called. The code in the Mainpresenter class is as follows:

 Public classMainpresenterImplementsMaincontract.presenter {PrivateMaincontract.model Model; PrivateMaincontract.view View;  PublicMainpresenter (Maincontract.view View) { This. View =view;  This. Model =NewMainmodel (); } @Override Public voidonbuttonclicked (Context context, String text) {model.onbuttonclicked (context, text); }}

Next is the code in the Mainmodel class. All the specific logic implementations of the MVP code are written in the model layer, so in the Mainmodel implementation of the Model interface's onbuttonclicked () method, we pop a toast as needed. The code is as follows:

 Public class Implements Maincontract.model {    @Override    publicvoid  onbuttonclicked (context context, String text) {        Toast.maketext (context, text, Toast.length_short). Show ();    }}

Finally, the view layer is written. As stated above, the realization class of the view layer is that the Activity,view layer needs to hold a presenter reference, all operations in the view layer call the corresponding method in the presenter layer, and the presenter layer is the code that calls the model layer. So the view layer even indirectly calls the code of the model layer. The code in Mainactivity is as follows:

 Public classMainactivityextendsAppcompatactivityImplementsMaincontract.view {PrivateMainpresenter presenter =NewMainpresenter (mainactivity. This); @InjectView (R.ID.BTN)protectedbutton button; @Overrideprotected voidonCreate (Bundle savedinstancestate) {Super. OnCreate (savedinstancestate);        Setcontentview (R.layout.activity_main); //Initialize ButterknifeButterknife.inject (mainactivity. This); } @OnClick (R.ID.BTN)protected voidClick () {onbuttonclicked ("Button Clicked!!!!"); } @Override Public voidonbuttonclicked (String text) {presenter.onbuttonclicked (mainactivity. This, text); }}

So far, a simple demo of the MVP is done. MVP is just a way of thinking, everyone has the understanding of everyone, so the structure will be different, but the overall goal is the same, that is, the activity of the view layer and controller layer separate, reduce the activity of code.

Of course, the MVP model also has drawbacks, that is, every activity created, you need to create contract, Model, presenter three classes, will greatly increase the number of classes in the project.

Use of the "Android-frame" MVP mode