According to the layering of MVC, Activity and Fragment (hereinafter referred to as Activity) should belong to the View layer, used to display the UI interface, and receive user input, in addition to bear some life cycle work. Activity plays a very important role in Android development, especially the life cycle function of TA, so when developing, we often write some business logic directly in Activity. This is very intuitive and convenient. The price is that Activity will become more and more bloated. , It is common for more than 1000 lines of code, and if it is some common business logic (such as user login), writing in a specific Activity means that this logic cannot be reused. If you have experience in code refactoring, you will definitely have concerns when you see 1000+ lines of classes. Therefore, Activity not only assumes the role of View, but also assumes a part of the Controller role. In this way, V and C are coupled together. Although this is convenient to write, it is difficult to maintain if the business is adjusted. A bloated Activity class to find the business logic code will also be very painful, so it seems necessary to extract the View and Controller from the Activity, and this is the work of the MVP mode.
1. The core idea of mvp
MVP abstracts the UI logic in the Activity into the View interface, and abstracts the business logic into the Presenter interface. The Model class is still the original Model. This is the MVP mode. In this case, the activity of the Activity is simple, only used to respond to the life cycle, and other tasks are thrown into the Presenter to complete. As can be seen from the above figure, Presenter is a bridge between Model and View. In order to make the structure simpler, View cannot directly operate on Model. This is also the biggest difference between MVP and MVC.
2. A brief description of mvp
The work done in this layer of MVP's Model model is the realization of specific business logic processing, which is accompanied by the processing of various data in the program, and the more complicated ones obviously need to implement an Interface to loose coupling.
The View
layer of MVP is very thin and light, which is responsible for displaying data and providing a friendly interface to interact with users. Activity and Fragment under MVP are reflected in this layer. Activity generally does some work of loading UI views, setting up monitoring and then handing over to Presenter to handle, so it also needs to hold a reference to the corresponding Presenter. For example, the Acionbar (Toolbar) is hidden or displayed when the list is scrolled on the Activity. Such UI logic should also be in this layer. In addition, when making some judgments on the data entered on the View, for example, the input data of EditText, if it is a simple non-empty judgment, can be used as the logic of the View layer, and when a more complex comparison of the EditText data is required, such as from When the database obtains local data for judgment, it obviously needs to go through the Model layer to return, so these details need to be weighed by yourself.
The Presenter
Presenter layer of MVP handles the distribution of various logics of the program. After receiving feedback commands, timing commands, system commands and other instructions on the View layer UI, the distribution processing logic is handed over to the Model layer for specific business operations.
3. The role of mvp
Preliminary Study on MVC, MVP, MVVM (1)-There are specific explanations on the basic concepts , here is an important point.
Extract the business logic into the Presenter to avoid background threads referencing the Activity, causing the resources of the Activity to not be recycled by the system, causing memory leaks and OOM
The biggest reason for the OOM of Android APP is the memory leak that causes the APP's memory to be insufficient. One of the two major causes of memory leak is Activity Leak (the other reason is Bitmap Leak).
A powerful function of Java is the memory recycling mechanism of its virtual machine. This function allows Java users to design their code without having to consider the recycling of objects like C++ users. However, Java users always like to write a lot of objects casually, and then imagine that the virtual machine can help them handle the memory recovery work. However, when the virtual machine reclaims memory, it only reclaims those objects that are not referenced, and the referenced objects cannot be reclaimed because they may still be called.
Activity has a life cycle. The user may switch Activity at any time. When the memory of the APP is not enough, the system will reclaim the resources of the Activity in the background to avoid OOM.
Using the traditional MV mode, a lot of asynchronous tasks and operations on the UI are placed in the Activity. For example, you may download a picture from the network, and load the picture into the Activity's ImageView in the callback of a successful download, so asynchronous tasks Keep a reference to the Activity. In this way, even if the Activity has been switched to the background (onDestroy has been executed), these asynchronous tasks still retain a reference to the Activity instance, so the system cannot reclaim this Activity instance, and the result is Activity Leak. In Android components, Activity objects tend to occupy the most memory in the heap (Java Heap), so the system will give priority to reclaiming Activity objects. If there is an Activity Leak, it is easy for APP to OOM because of insufficient memory.
Using the MVP mode, as long as the asynchronous task's reference to the Activity is separated in the onDestroy of the current Activity, Activity Leak can be avoided.
4. Examples of mvp code
4.1 Hierarchical structure
4.2 Code example
To achieve the view layer, the callback interface and controller (mLoginHelper) corresponding to the P layer must be implemented
Implementation of the P layer, custom business logic related interfaces, and helper specific business logic implementation
Implementation of the model layer, defining beans
Calling the view layer, and matters needing attention
5. Summary
The more troublesome thing about mvp is that you need to define various view interfaces and corresponding presenters. But this also has the advantage that the code looks clearer, at least the activity is basically the implementation of the relevant ui, and the processing of business logic is placed in the presenter. The degree of coupling is reduced. It is really convenient to improve later!
This is just a project I practiced, and I am still improving it. Calls related to the network layer may require additional method implementation for the presenter call. There is also model I did not use, it is directly processed by sharepreference, and I will continue to improve and optimize it below.