Android Design Pattern Comparison

Introduction:

The development of the Android framework is a process of continuous simplification, and everyone is studying how to properly and efficiently standardize the code. Of course, this road will never stop, like the new bud, with the passage of time, every day in the growth of new branches, every day to grow. For the technology, each new frame of the proposed in the elimination of the old frame of the criticism and pain points, to become more convenient, more efficient, more concise new framework, and then the new framework in the specific use will bring new criticism and pain points, repeatedly, endless also ... From starting with MVC to using MVP, from MVP to MVVM, every frame has something to give us a light, but there are still a lot of pain points in use, and there seems to be a reaction force to prevent me from doing so. But what can you do? New bud destined to grow into towering trees, technology will only progress.

Overview

Mvc

MVC here is not much to say, we are familiar with the more familiar, more ancient framework, I believe we have also used;

MVC Specific Use

• Model: Data models, JavaBean

• View:layout Layout file

• control:activity, processing data requests, business logic

The criticism of MVC

• View and control coupling is serious, there is a lot of logic code in activity, activity is both view, control, structure is not clear, activity content too much

Mvp

MVP is a model that is independent of control on the basis of MVC, simplifying the control content, where presenter acts as an intermediary agent, and the view and model do not interact directly, but through presenter

The specific use of MVP

• Model: Solid Models, JavaBean

• View:activity and layout

• Presenter:view and model interact through Presenter

The criticism of the MVP

• Granularity is difficult to grasp, the use of MVP know that MVP model needs to define a more interface, view needs to define the interface, presenter need to define the interface, before we use a activty can solve the problem, now we want to break down an activity into a view, A preseter, a model, each module needs to use the interface to achieve decoupling, which will lead to sometimes an activity involved in a lot of business, according to each business point to build the MVP model, will lead to an activity class can be done, Now need to expand into multiple interfaces, multiple classes can be implemented; If the granularity is large, the structure may not be clear; if the granularity is small, the amount of code will be larger;

• MVP is a UI and event-driven model, data acquisition is passive based on UI changes, we want to be data changes to update the UI, rather than the reverse;

• The coupling ratio of presenter and view is high;

• Presenter class in the business complex case, the code is relatively large;

MVVM

MVVM is based on the MVP, a flexible and efficient framework redesigned by Google's datebinding solution, which MVVM uses ViewModel instead of the original presenter layer;

Use of MVVM

• Model: Data models, JavaBean

• View:activty and layout

• Viewmodel:view and model business logic interactions

The advantages of MVVM

Data-driven

In MVVM, changes to the data can automatically update the view without the need to obtain a reference to the view;

Low coupling

In MVP mode, view and presenter are strongly coupled, presenter need to get the view reference, so when the view changes, presenter also need to change, coupling is too high; now in MVVM, ViewModel is only responsible for data and business, View changes, ViewModel do not need a relationship, data changes, view automatic updating, the coupling ratio is low;

View Update

The MVVM model does not have to consider whether updating the ui,datebinding in the main thread will be responsible for updating the UI in the main thread, we do not have to worry about threading problems, simply a little bit more;

Reusable

A viewmodel is a data source that can bind a viewmodel to a different view to update the view.

The criticism of MVVM

• MVVM is based on the databinding framework of Google, and DataBinding supports less binding view, so you may encounter some scenarios where view cannot use datebinding during use. That's why I didn't use MVVM before.

• Since there is a problem above, the domestic and foreign Daniel has helped us to encapsulate a set of view library using datebinding, in order to avoid the repetition of the wheel, we can introduce it to our project directly to use, now I know that has supported all the common view;

Summarize

After the comparison of the different frames above, I believe that we all have a basic understanding, some people will ask so many frameworks, we use that better?

Personally, the technology is constantly improving, the old framework will eventually be replaced by new frameworks, and I think MVVM's proposed solves many of the pain points we use in other frameworks, and I think using MVVM would be a better point.

Android Design Pattern Comparison