MVP evolved from the classic model MVC, and their basic ideas are similar: Controller/Presenter is responsible for logic processing, Model provides data, and View is responsible for display. As a new model, MVP and MVC have a significant difference: in MVP, View does not directly use Model, communication between them is performed through Presenter (Controller in MVC), all interactions occur inside Presenter, while in MVC, View will read data from the direct Model instead of through Controller.
In MVC, View can directly access the Model! Therefore, the View will contain Model information, and inevitably some business logic will also be included. In the MVC model, we pay more attention to the unchanging of the Model, and there are multiple different displays of the Model and View at the same time. Therefore, in the MVC model, the Model does not depend on the View, but the View depends on the Model. Not only that, because some business logic is implemented in the View, it is also difficult to change the View, at least those business logics 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 the specific View, but interacts through a defined interface, so that the Presenter can be kept unchanged when changing the View, that is, reuse! Not only that, we can also write test views to simulate various users' operations, thereby realizing testing of Presenter without using automated testing tools. We can even test the logic of Presenter by writing a Mock Object (that is, implementing the interface between Model and View, but without specific content) when neither Model nor View is completed. In MVP, the logic of the application is mainly implemented in Presenter, and the View is a very thin layer. Therefore, some people proposed the design model of Presenter First, which is to design and develop Presenter based on the User Story. In this process, the View is very simple, and it is enough to display the information clearly. Later, change the View as needed, without any impact on the Presenter. If the UI to be implemented is more complex and the relevant display logic is related to the Model, you can place an Adapter between the View and the Presenter. This Adapter is used to access the Model and View to avoid the relationship between the two. At the same time, because Adapter implements the View interface, it can ensure that the interface between it and Presenter remains unchanged. This ensures that the interface between View and Presenter is simplified without losing the flexibility of the UI. In MVP mode, the View should only have a simple Set/Get method, and the user inputs and settings content displayed on the interface. Apart from this, there should not be more content, and the Model is never allowed to be directly accessed - this is the big difference from MVC.
Advantages of MVP:
1. The model is completely separated from the view, and we can modify the view without affecting the model;
2. You can use the model more efficiently because all interactions occur in one place - inside the Presenter;
3. We can use a Presenter for multiple views without changing the Presenter logic. This feature is very useful because the view changes are always more frequent than the model;
4. If we put the logic in Presenter, then we can test these logics (unit tests) off the user interface.
How to use
1. Create a bean
public class UserBean {
private String mFirstName;
private String mLastName;
public UserBean(String firstName, String lastName) {
this. mFirstName = firstName;
this. mLastName = lastName;
}
public String getFirstName() {
return mFirstName;
}
public String getLastName() {
return mLastName;
}
}
2. Establish a model interface (processing business logic, which refers to data reading and writing here)
public interface IUserModel {
void setID(int id);
void setFirstName(String firstName);
void setLastName(String lastName);
int getID();
UserBean load(int id);// Read user information through id and return a UserBean}
3. Establish a view interface (update the view status in ui), and here are the methods that need to operate the current view
public interface IUserView {
int getID();
String getFristName();
String getLastName();
void setFirstName(String firstName);
void setLastName(String lastName);
}
4. Create a presenter (the dominant, operating model and view through the iView and iModel interfaces), and the activity can process all logic to the presenter, so that the Java logic is separated from the activity of the mobile phone.
public class UserPresenter {
private IUserView mUserView;
private IUserModel mUserModel;
public UserPresenter(IUserView view) {
mUserView = view;
mUserModel = new UserModel();
}
public void saveUser( int id, String firstName, String lastName) {
(id);
(firstName);
(lastName);
}
public void loadUser( int id) {
UserBean user = (id);
(()); // Update the display by calling the IUserView method (());
}
}
The main solution of MVP is to extract the logic layer into a P layer. If you encounter logical changes in requirements, you can only modify the P layer or encounter logical approximations. We can write a P directly. Many developers write everything in Activity/Fragment. In this way, when frequent changes in requirements or the logic becomes more and more complicated, too much mixed logic will appear in Activity/Fragment, causing errors. Therefore, the MVP mode is a good choice for APP to decouple control logic and UI!
The above is a detailed explanation of the use of the mvp mode in Android introduced by the editor. I hope it will be helpful to everyone. If you have any questions, please leave me a message and the editor will reply to everyone in time. Thank you very much for your support for my website!