Detailed explanation of MVP mode in Android

MVP evolved from the classic mode MVC, and their basic ideas have similarities: Controller / presenter is responsible for logic processing, model provides data, and view is responsible for display. As a new mode, there is a significant difference between MVP and MVC: in MVP, the view does not directly use the model, and the communication between them is carried out through the presenter (controller in MVC). All interactions occur within the presenter, while in MVC, the view will read data from the direct model rather than through the controller.

In MVC, view can directly access the model! Thus, the view will contain model information and inevitably some business logic. In the MVC model, more attention is paid to the invariance of the model, while there are multiple different displays of the model and views at the same time. Therefore, in the MVC model, the model does not depend on the view, but the view depends on the model. Moreover, because some business logic is implemented in the view, it is difficult to change the view. At least those business logic cannot be reused.

How does MVP solve the problem of MVC?

In MVP, presenter completely separates model and view, and the main program logic is implemented in presenter. Moreover, the presenter is not directly associated with a specific view, but interacts through a defined interface, so that the presenter can be kept unchanged when changing the view, that is, reused! Not only that, we can also write a view for testing to simulate various operations of users, so as to test the presenter -- without using automated testing tools. We can even test the presenter's logic by writing mock objects (that is, those that implement the interface between model and view but have no specific content) before the model and view are completed. In MVP, the application logic is mainly implemented in the presenter, and the view is a very thin layer. Therefore, someone proposed the design pattern of presenter first, which is to first design and develop presenter according to user story. In this process, view is very simple. It is enough to display the information clearly. Later, you can change the view as needed without any impact on the presenter. If the UI to be implemented is complex and the related display logic is related to the model, you can place an adapter between the view and the presenter. This adapter accesses the model and view to avoid the association between them. At the same time, because the adapter implements the view interface, it can ensure that the interface with the presenter remains unchanged. This ensures the simplicity of the interface between view and presenter without losing the flexibility of the UI. In MVP mode, view should only have a simple set / get method, user input and set the content displayed in the interface. In addition, there should be no more content, and direct access to the model is never allowed - which is very different from MVC.

Advantages of MVP:

1. The model is completely separated from the view. We can modify the view without affecting the model;

2. The model can be used more efficiently because all interactions take place in one place - inside the presenter;

3. We can use one presenter for multiple views without changing the presenter logic. This feature is very useful because the view changes more frequently than the model;

4. If we put the logic in the presenter, we can test the logic (unit test) away from the user interface.

usage method

1. Create bean

2. Establish a model interface (process business logic, here refers to data reading and writing)

3. Create a view interface (update the view status in the UI). Here are the methods to operate the current view

4. Establish a presenter (Master, operate the model and view through the iView and imodel interfaces), and the activity can process all logic to the presenter, so that the Java logic can be separated from the activity of the mobile phone

The main solution of MVP is to extract the logical layer into a p layer. If there are logical changes in requirements, we can only modify the p layer, or we can write a p directly. Many developers write everything in the activity / fragment. In this way, when there are frequent changes in requirements or the logic is becoming more and more complex, There will be too many mixed logic in the activity / fragment, resulting in errors, so MVP mode is a good choice for app to decouple the control logic and UI!

The above is a detailed explanation of the use examples of MVP mode in Android introduced by Xiaobian. I hope it will be helpful to you. If you have any questions, please leave me a message, and Xiaobian will reply to you in time. Thank you very much for your support for the programming tips website!