I came to the new company at the end of October last year. When I took over the Android project at the beginning, I found it was really a mess. There was no architecture to speak of in the project development, and the developers did not know the simple MVC and MVP. So I decided to re-analyze the prevailing development architectures and choose the one that fits the current project.

This is the first chapter of “My Android Refactoring Journey”. In this chapter, I will introduce the mainstream architecture design of MVVM, MVP, MVC and AndroidFlux in turn. This article will not analyze the code differences of these architectures in depth, but just bring their design ideas to you. Make it easier for everyone to choose the appropriate architecture in the project.

MVC

MVC simply divides the entire application into three parts: Model, View and Controller

  • View: Manages graphic and text output displayed as a bitmap on the screen.
  • Controller: Translates user input and operates on models and views based on user input.
  • Model: Manages the behavior and data of the application, responding to requests for data (often from views) and instructions to update state (often from controllers).

MVC architecture

It can be seen from the above figure that the View layer needs to be notified by the event initiated by the Controller and then the View gets the data from the Model. This is difficult to implement in the APP. Our events are usually initiated and dominated by the Activity or View. If the event initiation and control are handed over to Controller, some unexpected problems will often occur, such as memory leakage, which leads to the emergence of MVC variant MVP. The design of Android itself conforms to MVC architecture. However, Android’s XML View function as a View is too weak. We can only write a lot of View logic in the Activity, so the Activity acts as the View and Controller. This directly causes the code in the Activity to explode. Most Android developers have encountered a situation where Acitivty has thousands of lines of code. So, it’s more appropriate to say that the MVC structure is really just a Model-View (Activity:View&Controller) structure in the end.

MVP

The MVP architectural pattern is a variation of MVC, and many frameworks claim to follow the MVC architectural pattern, but they actually implement the MVP pattern. The difference between MVC and MVP is not that obvious. I think the biggest difference between the two is that the View layer can initiate events.

MVC architecture

In MVP, a Presenter can be understood as a loose controller that contains the UI business logic of the view. All events emitted from the view are handled by the Presenter through a proxy, and the Presenter communicates with the Presenter through the interface exposed by the view.

Application in APP

In MVC, the controller is responsible for responding to different actions requested by the client in different views. However, unlike MVC, in MVP, the view hands all actions to the Presenter for processing. In MVC, all actions correspond to method calls of a controller. Each action in a Web application is an operation on a URL. The controller operates on the data according to the access route and method (such as GET) and finally selects the correct view to return the data.

The view returned by the controller in MVC is not directly bound to the model, it is only rendered by the controller and is completely stateless with no logic, but the view in MVP must delegate the corresponding event to the Presenter for execution, otherwise the event cannot be responded to.

The above is taken from What are MVP and MVC and What is the difference? · Model-View-Controller in Stack Overflow.

As you can see, the Presence of the Presenter layer helps reduce the stress of activities and is structurally clear, but the View layer will have more code to communicate with presenters, which is less desirable, and the MVVM architecture is proposed in this case.

MVVM

The MVVM architecture pattern was created by Microsoft in 2005, and first came to the attention of Android people when Google launched DataBinding in 2015. Subsequently, Google continuously launched ViewModels, LiveData, Android Loader, Lifecycles and other components suitable for MVVM architecture. Google has “anointed” MVVM as the first architecture for the future of Android development.

The MVVM architecture

From the name model-view-ViewModel, it is composed of three parts, namely Model, View and ViewModel. The ViewModel is actually the presentation Model in PM mode, which is called ViewModel in MVVM. In addition to the familiar Model, View, and ViewModel parts, the MVVM implementation introduces an implicit Binder layer through which declarative data and commands are bound in the MVVM pattern.

Binder layer

The MVVM architecture renames presenters to ViewModels, which is basically the same as the MVP model, except that it uses data-binding to automatically reflect changes to a View in the ViewModel and vice versa. This makes it difficult to introduce MVVM into a project because we must be familiar with DataBinding and other basic components if we want to fully adopt MVVM.

AndroidFlux

AndroidFlux is an Android implementation of Facebook’s Flux architecture. Flux is a Web front-end architecture introduced by Facebook in 2014 to deal with the consistency of complex UI logic (at the time, to solve the problem of message notification for Web pages). After practice, it is found that this architecture can be well applied to the Android platform. Compared with other MVC/MVP/MVVM modes, it has good documentation and more specific design, which is suitable for rapid development and implementation. The biggest feature of Flux mode is one-way data flow, and its UI state update mode inherits the design idea of MVC mode. Flux is not a concrete framework, but a set of patterns for dealing with UI problems. AndroidFlux is also not a concrete framework. You don’t need to import or integrate any new code to use it, but you need to understand the idea and follow the development pattern.

AndroidFlux architecture

The structure of AndroidFlux is very reminiscent of functional-reactive programming, and AndroidFlux has been emphasizing that it is not a specific framework itself but a UI or data flow direction. Much like the familiar RxJava design idea, all events, uIs can be treated as a data stream and processed.

AndroidFlux data flow

There is only one Dispatcher

The Dispatcher is the central hub in the AndroidFlux application, managing all the data flows. It actually manages a set of callbacks for the Store registry and has no logic of its own — it’s just a simple mechanism for sending actions to stores. Each Store registers itself here and provides its own callback method. When ActionCreato sends an Action to the Dispatcher, all stores in the application are notified through the callback interface.

As the App grows, the Dispatcher becomes more important and can manage Store dependencies by adjusting the order in which callback methods are triggered. A Store can declare that it will wait for other stores to update itself.

Stores

Store contains the State and Logic of an application. It plays a similar role to the Model in the MVC pattern, but it manages the state of multiple objects — it’s not a single data set like the ORm-Model. Store is responsible for managing the state of a Domain in an App, rather than a simple ORM data set.

Because AndroidFlux is a string of grammar and structure specifications, it does not have any components to assist us in development, so it is difficult to use AndroidFlux. It is not considered for the time being in the application of small and medium-sized teams, just as a knowledge expansion.

conclusion

In the selection of architectural patterns, we often don’t have much say, mainly because the platform itself often on application layer has its own design, we in the development of the client or front application, only need to follow the inherent design can complete application development platform, however, in some cases, due to engineering becomes large, the business logic is complicated, We can also consider implementing a new architecture on top of the existing one to meet engineering needs.

In the end, due to the shortage of staff in the project, it was a pity that our project could only choose MVP for reconstruction. However, other architectures also provided us with good ideas, such as the binding component officially provided by Google in MVVM architecture, and the UI in AndroidFlux as a part of responsive programming. These good points are worth reviewing and studying. In the following articles, we will discuss some of the problems we experienced in project refactoring and how we designed a common development architecture that is relatively easy to use.

Public id: Programmer Cat