concept

MVP is a new Android development architecture, modified from the previous MVC, with the goal of decoupling logic and display to achieve modularity.

The difference between the two can be found at the following address

Blog.csdn.net/boyupeng/ar…

specific

View Displays the interface. The callback response is implemented by calling the Presenter interface to update the data.

Presenter serves primarily as a bridge to a Model that accesses a website’s data, parses it back, and presents it to the interface via the View interface

Model The primary data structure that serves as the core of the logical business

Specific relationship diagram:

Review images

The advantages and disadvantages

  • advantages
    • The interface and logical business are linked by interfaces to hide the business implementation details, so that when the interfaces between the interactions are defined, the internal implementation details are modified to ensure module independence.
  • disadvantages
    • Because of the use of interfaces to decouple the association between modules, the interface class increases, and the MVP pattern can be used appropriately, but in some very simple logical services, MVP can not be used.

This development architecture is slowly evolving, and an idea has emerged, that is, to continue to decompose the Model and create a DataManager to manage the Model in a unified manner.

With DaraManager, Presenter does not correspond directly to Model, but to the interface that calls the DataManager, which implements the implementation details of each Model.

To better understand MVP thinking, let’s take a look at the official MVP demo

The address is github.com/googlesampl…

View the difference between

The View here has a different meaning than the default View on Android. The default is a TextView Button and this class is called a View, and a View is an interface View, like an Activity or a Fragment, or in our case, a Fragment.

Let’s start with the main Activity, TasksActivity

Review images

We see here that we define an mTasksPresenter. We then construct a TasksFragment and use the view image

When creating a TasksPresenter, use mTasksView to store the View in order to retrieve data from the View. Update the View data. use

View the image and assign the View’s mPresenter. Then when we need to request or retrieve data on the interface, we call the interface provided by mPresenter directly. The mPresenter gets the result back, and calls the interface from the saved View object.

To better understand what is defined here, let’s go straight to the interface defined in the demo. The TasksContract class has two interfaces: View and Presenter.

View pictures View pictures

View defines how to display and refresh the data we get.

Presenter defines what methods we need to implement in order to prepare the data we provide to the View. In this way, we treat the View as a completely passive processing of the data, not actively involved in how the data is coming from, just processing the data that is given to us. According to the function of each interface agreed in advance, get the data, change the interface, refresh the list and so on.

In the case of TasksPresenter and the corresponding tasksFragment, let’s take a look at how their classes are defined.

When this is done, TasksPresenter implements the TasksContract.Presenter method, and tasksFragment implements the TasksContract.View method.

We then complete a round trip by calling the mPresenter methods in the tasksFragment, triggering the Presenter to fetch the data, retrieving the data, and directly calling the associated View methods (in this case, the tasksFragment).

Here we take a look at a sequence diagram of clicking the Fab button to see how the View and Presenter pass through.

Review images

If you look closely, you will find that there are all V and P (View and Presenter) things, not M (Model), why?

Because a Model is associated with a Presenter, it is not directly associated with a View. When a Presenter requests data, the implementation process is pushed to the Model, which processes the data, returns it to the Presenter, which is collated by the Presenter, and then passes it to the View to complete the process.

Here’s a sequence diagram of the refresh operation:

Review images

I do not know so, whether you can clearly understand this development model? Comments are welcome.

Review images