MVC

This is how MVC is often described in our development

  • View: XML, dynamically added View bindings, etc
  • Model: The model layer that gets the data
  • Controller: Activity, Fragment, etc
  1. The Activity binds the view to the controller using setContentLayout and findviewByid
  2. Listeners such as setOnclick bind various view interactions
  3. When the click event is triggered, let’s say a network request, so when the button is clicked, we want the Model to send a network request
  4. So the Activity also holds the Model object and notifies the View to update it when the Model request returns data
V xml <TextView... > C Activity{ onCreate{ //Model String data = Model.getData(); //View tv.setText(data); Static String getData(){retrun "MVC"}} static String getData(){retrun "MVC"}}Copy the code

The flow of the MVC

In fact, I think MVC should not separate M, V, C, in fact, can be seen as ++M++, ++VC++ two parts better understand some

  • Controller and View->Activity control the View: First of all, an Activity holds a view. We know that a controller is usually responsible for process control. In our daily development, an Activity can be roughly defined as a controller, so we can understand that the controller controll the view. View updates need to be controlled by Controller, that’s the first point
  • Controller and Model->Controller also control Model: The View itself does not actively fetch data from Model, but the Controller can ask Model for data and decide whether to update the View
  • View and Model-> Data and views need to be aligned: Operations on the View can trigger changes to the Model, such as submitting data, and updates to the Model require View changes, such as interface data changes
  • A complete MVC business would look like this, taking the registration function as an example
    • The View layer user enters the username and password, clicks Submit, and hands the transaction to the Controller
    • The Controller listens for the Submit button event in the View layer and submits data to the Model
    • The Model gets the event sent by the Controller, requests the interface, gets the data from the server, and calls back to the Controller
    • The Controller gets the data {data:”sucess”,message:” registration successful “}, and it’s time to notify the View
    • The View presents the Controller’s data, and the control of the flow continues to the Controller
    • After three seconds, the Controller goes directly to the home page via startActivity
    • So, actually a complete MVC flow here isV-C-M-C-V-C,M and V are never next to each other, indicating that they do not interact directly
  • Here, we can see that the model and view are separated, and there is no direct interaction, this is our daily development of the common way, and many online articles about the model. SetView (.. ). “, and then update the View inside the Model, which is not normal for Android development, and there is no need to do more complicated work to write classic MVC code

The problem of MVC

Actually MVC is too heavy, the main problem is that C is responsible for things too much, should not only responsible for inquiry Model, and to be responsible for updating the View, not tired, tired, tired, and the code is much seems to have a headache, this is even if the code you write neatly again feel vexed, for later maintenance is not very friendly, and the code is really easy to write more and more disorderly, There is too much code in the Activity, so the MVP really liberates the Activity

Finally, remember: Writing all the business logic and interface updates into an Activity is not called MVC.

MVP

MVP broke up the Controller on top of MVC

  • Abstract the Activity completely as a View
  • Add Presenter binding to View and Model
  • When it needs to get data, the View gets it from the Presenter, and the View doesn’t care what’s going on inside the Presenter. Okay
  • When data is updated, Presenter notifies the View to update it via an interface callback
  • So the code can be written like this

Presenter

P class Presenter{ Model model; View view; View v {Model = new Model(); view = v; } doPost(){ String data = model.getData(); view.showData(data); }}Copy the code

Model

M
Model{
    String getData(){
        retrun "MVP"
    }
}
Copy the code

View

V xml <TextView... > Activity implements View{ onCreate{ //P Presenter p = new Presenter(this); } @override showData(String data){ tv.setText(data); } } interface View{ void showData(Obect data); }Copy the code

The process of MVP

Take the registration process above as an example

  • The View click event is triggered and the View notifies the Presenter to submit the registration
  • Presenter notifies Model that I want to register
  • Model gets the registration information and returns the registration success message
  • It’s still in the Presenter, and the Presenter calls back to the View through the interface
  • The View receives a callback, updates the View, jumps
  • So the whole process isV-P-M-P-VSimilarly, M and V are not adjacent and do not interact directly

MVP vs. MVC

It seems that MVPS are very similar to MVC, even the code in MVC is much simpler, yes, yes, so there is no need for MVC and MVP to argue about who is good and who is bad, the one that fits is the best

  • MVP doesn’t actually have less code than MVC (of course Presenter reuse can reduce the code to a certain extent, but it doesn’t have to be used), but rather it has more interfaces and classes
  • In my opinion, MVP is actually an evolved version of MVC. It relies on interface programming, and the responsibilities of classes are more simple and clear, which are its advantages
  • In fact, the main change in MVP is to add a P to MVC. The M in MVC remains the same. V is part of THE V in MVP.
    • Model: The Model layer that gets the data
    • View: Activity, XML, dynamically added View bindings, etc
    • Presenter: Connects the View and Model

The characteristics of the MVP

  • Too many interfaces, class explosion (writing a page usually requires too many classes);
  • It is difficult to find data sources, because MOST MVPS use interfaces, so they use interfaces to find data (in fact, I am very tired of constantly running between interfaces), not like MVC to run to black as “cool”;
  • For very simple applications, MVC is faster, and MVP is no longer an option
  • High time cost of development (reminds me of the react meme that creates more jobs than VUE)
  • The code is indeed more readable because it is hierarchical and relies on interfaces
  • Maintainability is also significantly better than MVC

MVVM

MVVM is particularly common in front end development, and its features are

  • The Model is updated, the View is updated
  • Some input on the View changes, and the Model changes

React, Vue and other front-end frameworks help us realize the bi-directional binding of Model-View and view-Model, that is, the process is automatic. Developers can just write the code according to the spec but in Android development we have to implement this manually (although ViewModel+LiveData greatly simplifies the process of bidirectional binding)

MVVM, as I understand it, is an MVP/MVC with data

What is data binding?

  • External presentation data (database data, network data), in-memory data (variables in Java code), presentation data (data displayed in the interface) and in-memory data automatically update each other.
  • In addition, MVVM can sometimes give your memory data and database data to do associated listening, so that your three kinds of data to achieve further linkage.

The realization of the MVVM

MVVM can be interpreted in three parts: MODEL,VIEW, and view-model

  • MODEL provides data 
    object DataCenter{
  fun getData():String{
    return StringAttr().value!!;
  }
}
Copy the code
  • View is responsible for presenting the data 
    class MvvmActivity:AppCompatActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.layout_mvvm) var mvvmText: EditText = findViewById(R.id.mvvmText); ViewModel(mvvmText).init(); }}Copy the code
  • The ViewModel is responsible for the bidirectional binding of the View and model
    • View we can set the listener and then update the model with model.setValue()
    • The model data changes, and the rendering on the view changes through view.settext ()
    class ViewModel (textView: EditText){ var data:StringAttr = StringAttr() init { ViewBinder.bind(textView,data); } fun init(){ val data = DataCenter.getData(); }}Copy the code

    Here we use ViewBinder for bidirectional binding

    Class ViewBinder {companion object{private const val TAG = "ViewBinder" EditText,stringAttr: StringAttr){ editText.addTextChangedListener(object : TextWatcher { override fun afterTextChanged(s: Editable?) { if (! TextUtils.equals(stringAttr.value,s)){ stringAttr.value = s.toString(); Log.d(TAG,"view notifies model to change data :${s}")}}... }) stringAttr.onChangeListener = object : OnchangeListener { override fun onChange(newVal: String?) { if (! Textutils.equals (newVal,editText.text) {edittext.settext (newVal) log. d(TAG," Model notifies view to change text :${newVal}")}}}}}}Copy the code

So that both views and data are bound, and you change and I change

The MVVM process

Again, take the registration function as an example

  • When the user enters, the View-Model works, synchronizing the data with the UI update
  • After the input is complete, click the registration submit button and View will get the synchronized Model data
  • Model submits the data we want to submit, and the server returns the registration success message
  • This returned data is rebound to the View via the ViewModel, and the View is updated
  • After a countdown of three seconds, the View control layer jumps to the home page
  • So the whole process isVM-V-M-VM-V

The difference between MVVM and MVC and MVP in positioning

  • The MVC MVP is more architectural in nature: it provides design specifications
  • MVVM is a framework, like a library: it provides data binding features

The MVVM and Android Jetpack

The Jetpack component associated with MVVM is DataBinding, not ViewModel