Explain in detail the method of implementing Redux in Android

Redux is an open source JavaScript library for application state management. Its core is to describe a system through manageable and controllable state. This means that its idea can be applied to the development of any type of application, including mobile applications.

Redux architecture is based on a strict one-way data flow. All data in the application flows in one direction through components. Redux wants to ensure that the view of the application is rendered according to the determined state. This means that at any point in time, the state of your application is always certain, valid, and can transition to another predictable and valid state. The UI will be rendered according to the state.

There are a lot of relevant information about Redux on the Internet. Here we only introduce the three core components of Redux:

1. Store: save the application status and provide some help methods to access the status, distribute the status and register for listening.

2. Actions: simply put, actions are events that contain information to be passed to the store, indicating how we want to change the state of the application. For example, define an action as follows:

Distributed by store:

3. Reducers: change the state. Like this:

After introducing the core components, let's take a look at how they are combined:

The process of Redux is very simple. Your application presents the UI according to the current state, and the user's interaction triggers the action, which is handed over to reducer to update the state.

Recently, the author tried the Redux architecture on a fairly large project, so here are some lessons learned.

1. It is better not to have multiple stores in the application

It seems a good idea to have different stores for different modules, but from the figure above, we can see that each store and its data flow are a closed-loop system, which makes it difficult to synchronize the states between different stores. In this way, you usually need to distribute the action of another store in the change response of one state, which is easy to cause an infinite loop.

Another reason is that the multi store architecture is very rigid and difficult to change flexibly.

A better approach is to maintain a global application state with multiple sub States, represented by a store:

2. Keep the application status hierarchy as few as possible

Because the state in Redux is immutable, deeply nested States will generate a lot of template code and are difficult to update. For example, consider the following set of data models

Instantiate and update status objects:

Even if kotlin's copy mechanism is used, updating deeply nested attributes (such as article above) is very tedious:

3. Reducers are pure functions

The function of reduce is to process the action and return the new state to the store. It is necessary to ensure that the same input will always get the same output. Reduce itself should not have state and perform any additional work, but only make state transition.

If you need to respond to an action and perform some operations, you should consider using middleware.

4. Only kotlin

Redux is mostly inspired by flux, and the most common complaint about flux is the need to write a lot of template code. The language you choose will largely determine the convenience of managing template code.

Features like data class and when statements in kotlin can make your code much clearer. For example, when matching actions in reducer, you can choose to use the instanceof method.

When there are many actions, this way of writing is very painful. If you use kotlin, it's like this:

conclusion

Although Redux is mainly used for web application development, its idea can still be learned and introduced into Android. But Redux is not a "silver bullet". In fact, there is no architecture. Its application on Android is still very new, but we still hope to see its gradual maturity.