directory

MVP stuff (1)… Speak with the scene

MVP stuff (2)… A Preliminary study on MVC Architecture

MVP stuff (3)… Using MVC in Android (Part 1)

MVP stuff (4)… Using MVC in Android (Part 2)

MVP stuff (5)… The relationship between the mediator model and MVP

MVP stuff (6)… MVC turned into MVP

MVP stuff (7)… Repository Design analysis

Will soon be the Spring Festival, now also in the unit brush nuggets of students, you can see how important in the minds of the leadership, here, first of all, I wish you a happy New Year, all the best, the New Year new atmosphere, next year a new high!

Quickly review

Front spent a lot of trouble to introduce layered architecture related knowledge, and how the MVC architecture, a broker mode is introduced and the relationship between the MVP, during the application of scene description, such as the rent house’s story, the story of project development, work overtime, the stage is in order to explain the MVP, In order to be more free to expand and design new varieties in the future actual combat, skilled application in the project, it is necessary to know how, know why.

The capacity of this article is relatively simple, how to design an MVP, because of the previous paving, we directly use the MVC example to rewrite.

First of all, let’s review the difference between MVC and MVP. Let’s look at the following two design drawings. After repeated summary and induction, we come to a conclusion:

In MVC, C has a very simple responsibility to handle process control, while in MVP, apart from process control, it is also responsible for an isolated role between M and V, as an intermediary.

What is a mediator? The MVP thing (5) Intermediaries and MVPS welcome back.

The duties of the intermediary, isolation

MVP is an intermediary in nature. It can be seen from the above conclusion that as long as the Controller gives the intermediary function, it will become Presenter.

Isolation means that M and V cannot refer to each other during the design process, so all interactions need to be done through the Controller. Once this is satisfied, the Controller will be upgraded to Presenter. Let’s take the code from the MVC invocation and work backwards from the application layer:

public class MainActivity extends AppCompatActivity implments TasksView{ @Override public void onCreate(@Nullable Bundle  savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); TasksController = new TasksController(tasksView:this); Model -> View and View -> Model TasksRepository Model = new TasksRepository(tasksView:this); //Controller -> Model model.setController(controller); }}Copy the code

This code was used in the MVC example in the previous chapters. You can see that when TaskRepository is initialized, the constructor injects the View into TaskRepository, which is an instance of the Model layer. As mentioned in MVP, M and V cannot meet in any form, so this is not allowed in MVP, so it needs to be redesigned to not allow views to appear in Moodel in any form, including three dependency injection methods. Second, since MainActivity is an implementation of View, it clearly implements TaskView. Although TaskView is not designed to include Model, it has no control over subclasses that include Model. In this case, TaskRepository is instantiated in MainActivity, one representing M and one representing V, but in this case, it doesn’t really affect the overall design. After all, the behavior of subclasses is not controlled. Typically, the initialization of a Model is in an instance of Presenter. In my opinion, there is a benefit to this: Presenters handle Model initialization, so that when a View wants to use a different Model, it can use a different Presenter. After simple analysis, the code is modified in this way

public class MainActivity extends AppCompatActivity implments TasksView{ @Override public void onCreate(@Nullable Bundle  savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); TasksController = new TasksController(tasksView:this); }} /** public class TasksController implements Observer{public TasksController(TasksView view) { View this. View = view; // Initialize Model TasksRepository Model = new TasksRepository(); //Controller -> Model model.addObserver(observer: this); }..}Copy the code

In real projects, layers are defined in the form of interfaces. This is not surprising. There is no interface design, so don’t forget to do interface design. If you have a certain amount of experience and accumulation, you can design several general interfaces first and then improve them gradually. For example, the function of loading data in Model is indispensable. Then you can define loadData first, and the method of processing View that receives notification from View. For example, Prensenter unified processing initiated to obtain data requests and so on. These business-specific interfaces are the key to the fullness of MVP framework, but the premise is that we must follow the principles of MVP architecture to design, so next, we try to design these interfaces.

Design interfaces to make the MVP framework stronger

The framework is the skeleton, while the interfaces and their implementations are the muscular system. The interfaces determine where the muscles go, and the implementations determine what the muscles can do.

scenario

In my recent work, there was a requirement to have both HTTP requests and TCP requests in the App: I called it getObject because I didn’t know exactly what I was getting, and I didn’t know exactly what the parameters and return values were (ignoring too much of the specific business for now).

Let’s build an MVP framework from scratch

1. Define Model

public interface DataSource {
    void getObject();
}
Copy the code

2. Define Presenter

public interface Presenter {
    void loadSometing();
}
Copy the code

Define the View

public interface View {
    void setPresenter(Presenter p);
}
Copy the code

Define a listener between Presenter and Model

public interface PresenterListener {
    void onSametingCallBack()
}
Copy the code

First implement the Model

1. HTTP request Model

Public class RemoteHttpRepository implements DataSource {@override void getObject() {}Copy the code

2. TCP request Model

Public class RemoteTcpRepository implements DataSource {@override void getObject() {// Implements a TCP request.. if(listener ! = null) { listener.onSametingCallBack(); } } void addListener(PresenterListener listener) { } }Copy the code

To realize the View

public abstruct class BaseView implements View {
    Presenter presenter;
    void setPresenter(BasePresenter presenter) {
        this.presenter = presenter
    }
    
    abstruct onViewDoSamething();
}
Copy the code

Realize the Presenter

public class BasePresenter implements Presenter ,PresenterListener{ RemoteTcpRepository repository; View view; public BasePresenter (View view) { this.view = view; // Repository = new RemoteTcpRepository(); repository.addListener(presenterListener: this); } @Override void loadSomething() { repository.getObject(); } @Override void onSametingCallBack() { view.onViewDoSamething(); }}Copy the code

Of course, don’t forget to add listening. BasePresenter implements listening, which we covered in detail in the previous section.

How To Use

public class MainActivity extends AppCompatActivity implments BaseView{
        @Override
        public void onCreate(@Nullable Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.activity_main);
            Presenter presenter = new BasePresenter(view: this);
            presenter.loadSamething();
        }
        
        @Override
        void onViewDoSamething() {
            //do view 
        }
    }
Copy the code

The definition of an interface should be defined according to the specific business. The above example is a very specific business to determine the definition of the interface. Therefore, do not copy the model, the key is to understand the idea.

conclusion

At this point, the muscles of the entire MVP are formed, and we continue to add to them: , for example, to add a generic object, achieve the function of the specific network request, whether to support data cache, as well as the Presenter life cycle control, this requires you to fill the according to actual demand, the day after tomorrow is New Year’s eve, a holiday soon, so happy, you have to spend more time with family, work what all go to hell, ha, ha, ha, We’ll continue after the festival.