The application of the--MVP model of project reconstruction experience

first, the MVP introduction

As the functionality of the UI creation technology grows, the UI layer also performs more and more responsibilities. In order to better subdivide view and model function, let view focus on processing data visualization and interaction with the user, while let the model only relational data processing, based on the MVC concept of the MVP (Model-view-presenter) model emerged.

The MVP model usually contains 4 elements:

(1) View: Responsible for drawing UI elements, interacting with users (represented as activity in Android);

(2) View interface: Need view implementation of the interface, view through the view interface and presenter interaction, reduce coupling, facilitate unit testing;

(3) Model: Responsible for storing, retrieving, manipulating data (sometimes also implement a model interface used to reduce coupling);

(4) Presenter: As an intermediate link between view and model, handling the responsible logic of interacting with the user.

Second, why use the MVP model

In Android development, activity is not the controller of a standard MVC pattern, and its primary responsibility is to load the applied layout and initialize the user interface, and accept and process requests from users to respond. As the complexity of the interface and its logic continues to rise, the responsibilities of the activity class increase and become bloated. When we move a complex logical process into another class (Presneter), the activity is actually the view in the MVP mode, which is responsible for the initialization of UI elements, the association of UI elements with presenter (listener, and so on), At the same time, they also handle some simple logic (complex logic referred to presenter processing).

Also, think about how you can unit-test your code logic when developing Android apps. Whether you want to deploy the application to the Android emulator or the real machine every time, and then test by simulating user actions. However, because of the characteristics of the Android platform, each deployment consumes a lot of time, which directly leads to the reduction of development efficiency. In MVP mode, the presenter of dealing with complex logic is through interface interacting with view (activity), which shows what. This shows that we can implement this interface to simulate the behavior of the activity of the presenter Unit test, save a lot of time for deployment and testing.

The similarities and differences between MVP and MVC

Both the MVC pattern and the MVP model have been applied for many years as a development model for separating the UI layer from the business layer. When we choose a development model, we first need to understand the pros and cons of this model:

There is an unavoidable drawback to either MVC or the MVP model:

Additional code complexity and learning costs.

This leads to the two development patterns that may not be very small applications.

But compared to their advantages, this shortcoming can be ignored basically:

(1) Reduce the coupling degree

(2) Module Responsibility Division is obvious

(3) Conducive to test-driven development

(4) Code reuse

(5) Hide Data

(6) Code flexibility

There is also a big difference between the two modes of MVP and MVC. Some programmers choose not to use any of these patterns, partly because they may not be able to distinguish between the two patterns. The following are the most critical differences between the two modes:

MVP mode:

View does not interact directly with model, but indirectly with the model by interacting with the presenter. The interaction of presenter and view is done through interfaces and is more conducive to adding unit tests.

Usually view and presenter are one-to-one, but complex view may bind multiple presenter to handle logic

MVC pattern:

View can interact directly with model

Controller is based on behavior and can be shared by multiple view

is responsible for deciding which view to display

Iv. Using the MVP example in this project

Take the main module below the UI package for example:

Public interface Newsmaincontract {

Interfacemodel extends Basemodel {
observable< list<newschanneltable> > Lodeminenewschannels ();
}

Interfaceview Extendsbaseview {
Voidreturnminenewschannels (list<newschanneltable>

Newschannelsmine);
}
Abstract Classpresenter Extendsbasepresenter<view, model> {
public abstract voidlodeminechannelsrequest ();
}
}

Write a contract interface, where the Model,view,presenter interface, the unified management of three interfaces, you can find that presenter and model, View are interactive through the interface, both reduce coupling and facilitate unit testing.

First look at model, inherit the Basemodel,basemodel inside is the model needs to implement public methods.

View,presenter, too, inherited the Baseview,basepresenter. The advantage of this writing is that the base class is used for unified management of common methods.

specifically see Basepresenter,

Public abstract classbasepresenter<t,e>{
PublicContextMcontext;
PublicEMmodel;
PublicTMview;
PublicRxmanagerMrxmanage=NewRxmanager ();

Public voidSETVM (Tv,em) {
This.Mview= V;
This.Mmodel= m;
This. OnStart ();
}
Public voidOnStart () {
};
Public voidOnDestroy () {
Mrxmanage. Clear ();
}
}

Rxmanager is the lifecycle of encapsulating a unified management Rxjava, which is discussed in the next section when using Rxjava for project optimization.

SETVM (Tv,em) Through this method, it is obvious to know presenter the model and view associated.

Next look at how the MVP model is used in fragment.

Public class  Newsmainfragment extends basefragment<newsmainpresenter,newsmainmodel> implements Newsmaincontract.view

Inherited the Basefragment<t extends basepresenter,e extends basemodel>

The

implements the contract inside view interface so that the method in the view can be implemented in fragment, and the methods in model and presenter are implemented in the outer class, as long as the basefragment<> , and then associate model and view with Mpresenter . SETVM ( This , Mmodel ). This represents the most important point in the MVP model: view does not interact directly with the model, but interacts with the model indirectly by interacting with the presenter.