MVP design objectives:

  • Unlocks bloat at tier V

Extreme experience:

BaseMVPActivity itself is a generic class that sinks into the lib, but the upper business layer needs to use BaseActivity to implement basic statistics and burying points, which means I can either move BaseMVPActivity to the business layer, Then inherit BaseActivity, or sink BaseActivity into lib for BaseMVPActivity to inherit, but my business statistics won’t work.

public abstract class BaseMVPActivity<P extends MVPBasePresenter> extends BaseActivity implements MVPBaseView
Copy the code

2. Give P layer life cycle perception

    private P presenter;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        if (presenter == null) {
            presenter = createPresenter();
        }
        presenter.attach((V) this);
    }
    
    @Override
    protected void onDestroy(a) {
        presenter.detach();
        super.onDestroy();
    }
Copy the code

This approach has advantages and disadvantages: V layer does not need to care about data release when ending the page. Disadvantages: P layer operates time-consuming tasks of M layer during detach, which will directly lead to ANR of V layer

In my opinion, the P layer should not have lifecycle awareness

Layer P will specify an interface to restrict the current callable method, and layer P will also use the constraint interface to call back data to Layer V when completing the task action. The interface is specified as follows:

public interface HandleContract {
    interface View extends BaseView {
        void startWayPointSuccess(a);
        void pauseWayPointSuccess(a);
        void resumeWayPointSuccess(a);
        void clearWayPointSuccess(a);
        void stopWayPointSuccess(a);
    }
    interface Present extends BasePresenter {
        void startWayPointMission(a);
        void pauseWayPointMission(a);
        void resumeWayPointMission(a);
        void clearWayPointMission(a);
        void stopWayPointMission(a); }}Copy the code

Always thought before, through the interface constraints to realize V and P the invocation of the templates, can clearly understand both sides of the action, but, in the continuous change of the business, because some interface constraint is no longer useful, I will need to modify the interface template, modify the template, I have to modify V layer implementation method, In order to track a function, V layer jumps P, P layer jumps V, jumps several layers, and finally understands what action this function realizes.

idea

I always think ViewModel+LiveData+Lifecycles is a very good solution. ViewModel is already supported by ViewModelStore at the Framework level. Lifecycles also registers LifecycleRegistry in ComponentActivity, LiveData holds LifecycleOwner when observing (this, Observer), You have a sense of life cycle.

1. Number one: data interaction

View layer only needs to initialize ViewModel, subscribe LiveData in ViewModel and observe data as an observer. Once there is data change, it will be automatically updated to View, without the relationship between V and P. When obtaining data, P will be triggered first. The P layer then calls V to update the data. Compared to the ViewModel method, there is one more layer to manually set the data return, and another layer of template interface to regulate the constraints for the data return. Finally, the whole code is a pie.

2. Second point: Life cycle perception

The life-cycle awareness capability of LiveData is somewhat different from that of Present, and the specific difference is in the implementation level: 1. The Lifecycle perception of LiveData is to addObserver itself into Lifecycle when observing. Present Lifecycle awareness is given to BaseMVPPresent by BaseMVPActivity. If our Present is sentient, I’m going to have to inherit BaseMVPPresent, which I showed you in the inheritance above, and this is the worst experience point, so if we look at the way ViewModel+LiveData is doing, everything is combining, what’s the advantage of combining? Of course, in order to facilitate the dismantling and assembly of business upgrades, and inheritance, does not have such characteristics

3, the third point: page reconstruction

When the screen rotates, the page is rebuilt. We need to save the data when the page is destroyed, and restore the data when the page is rebuilt. However, the data storage is limited in capacity, and the object storage must be serialized object. The ViewModel does not store data in a Bundle, but in the ViewModelStore, which is supported by the Framework. For detailed analysis, please refer to the article “Why can the ViewModel store reconstructed data?”

Other thoughts, please fill in!!