Android MVP pattern

1. Introduction to the MVP model

I believe that everyone is familiar with MVC: M-Model-Model, V-View-View, C-Controller-Controller, MVP is an evolved version of MVC, then the meaning corresponding to similar MVP: M-Model-Model , V-View-View, P-Presenter-Presenter. From the perspective of the combination of MVC and MVP, Controller/Presenter plays the role of logical control processing in MVC/MVP, and plays the role of controlling various business processes. The most different point between MVP and MVC is that M and V are not directly related, and there is no direct relationship between Model and View. The Presenter layer is separated between the two, which is responsible for regulating the indirect interaction between View and Model. . A very important point in Android is that the operation of the UI basically needs to be performed asynchronously, that is, the UI can be operated in the MainThread, so the separation of the View and the Model is reasonable. In addition, the interaction between Presenter and View and Model can be further loosely coupled by using interfaces to define interaction operations, and it can also be more convenient for unit testing through interfaces. So there is this picture (comparison of MVP and MVC)


Comparing MVP and MVC

In fact, the most obvious difference is that in MVC, Model and View are allowed to interact, while in MVP, it is obvious that the interaction between Model and View is completed by Presenter. Another point is that the interaction between Presenter and View is through the interface (which will be reflected in the code).

 

Through the above analysis, let's sort out the whole steps:
1 The official MVP instance, through the protocol class XXXContract, internally inherits the interface of View and Presenter. It is a further encapsulation of BaseView and BasePresenter, so the View and Presenter we implement only need to inherit the corresponding internal interface in XXXContract.

2 The main function of activity is to create a View (here is the corresponding fragment), create a presenter, and pass the view to the presenter (complete the presenter's associated operation of the view instance)

3 In the constructor of the implementation class of the presenter, through the setPresenter of the view, let the view get the presenter instance. In this way, the method in the Presenter can be operated in the view. (Complete the associated operation of the view to the presenter instance)

4 In the implementation class of the presenter, you can operate on the Model data. In the example, data acquisition, storage, and data state changes are all tasks of the model layer. The presenter will call the data processing logic of this layer as needed and pass in the callback when needed. In this way, model, presenter, and view only handle their own tasks. This implementation is indeed the best interpretation of single responsibility.




Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=324818027&siteId=291194637
MVP