Introduction to flux architecture for Android learning

Introduction to flux architecture

The flux architecture is used by Facebook to build their client web applications. Like clean architecture, it is not designed for mobile applications, but its features and simplicity can be well adopted in Android projects.

The biggest feature of flux mode is one-way data flow. Its UI state update mode inherits the design idea of MVC mode. Flux is not a specific framework, but a mode to deal with UI problems. Android flux is also not a specific framework. You can use it without importing or integrating any new code. What you need to do is to understand this idea, follow this development mode, check the Android code examples we provide, and write your own code.

To understand flux, there are two key features

1. The data flow is always one-way

A one-way data flow is the core of flux architecture and the reason why it is easy to learn. As discussed below, it provides great help in application testing.

2. The application is divided into three main parts:

. View: application interface. Here, create an action that responds to the user's action.

. Dispatcher: the central hub, which delivers all actions and is responsible for transporting them to each store.

. Store: maintain the state of a specific application domain. They respond to action according to the current state, execute business logic, and issue a change event when it is completed. This event is used to update the view interface.

These three parts are communicated through action: a simple basic object, distinguished by type, containing operation related data.

Flux Android architecture

The purpose of using flux design specification in Android development is to establish an architecture that is relatively balanced between simplicity, easy to expand and easy to test.

The first step is to find the mapping between flux elements and Android App components.

Two of these elements are very easy to find and implement.

View: activity o or fragment

Dispatcher: an event bus. Otto will be used in my example, but any other implementation should be OK.

Actions

Actions is not complicated. Their implementation is as simple as POJO and has two main properties:

1. Type: a string that defines the type of event.

2. Data: a map that loads this operation.

Store is the hardest part of flux theory.

Stores responds to the action sent by the dispatcher, executes business logic and sends change events. The only output of stores is this single event: change. Other components interested in the internal state of the store must listen to this event and use it to obtain the required data. Finally, stores must expose an interface to get the application status. In this way, the view element can query stores and update the UI accordingly.

Here is a simple small demo to describe the whole process. There is a button and a textview on our interface. Click the button to display the text in the textview. For the conventional implementation, the logic is directly completed in the activity, and the MVP mode is carried out in the presenter layer. How do we implement the flux architecture. We can see from the above figure that the view will generate an action, which is then scheduled by the dispatcher, processed by the store and displayed.

How to generate an action

First, you need to know what action is like

Each action has two attributes, one to mark the type, and the other to store the transmitted data through the map.

For action type, we can record through an interface or class and save all types in it. Convenient for our call.

How to create an action and define a class to define various actions according to various view events that may occur.

When we prepared to create an action with actionscreator, we did not directly create a new action, but distributed it through the scheduler. For event distribution here, we use Otto's button to distribute events.

In the process of scheduling, we will parse the data passed in, create corresponding actions based on the data, and then distribute the actions. At this time, the store that pays attention to the corresponding actions will start to execute the corresponding actions according to the corresponding actions. In the store, an abstract method onAction is declared to judge and distribute actions, and then the storechangeevent interface is defined as an event change. When there is a change, it is passed through this. We can implement this interface ourselves, and then add some methods and fields to carry data.

Our custom store class

Then we subscribe to the method of change time in view, that is, activity. At this time, we can dynamically update the data in view.

summary

Through the flux architecture, the process used is that the events of our view will carry data. Create an action of type through an actionscreate. The actual completion process is in the dispatcher's dispatch, and then throw the action to the store method subscribed to the action. Here, various logic and processing can be completed, and even network requests can be initiated to obtain data, After the processing is completed, the result can be encapsulated into an event, and then the event will pass the event to the function subscribing to the event through the emitchangeevent in the scheduler, and the function receiving the response event is defined in our view, so as to update our view. The above is the whole content of this article. I hope the content of this article will help you learn flux architecture.