Flux Architecture for Android

• Original link: Flux Architecture on Android
• Developed technical front line www.devtf.cn. Without permission, not reproduced!
• Translator: Mr.simple

Finding a good application architecture is not easy for Android, and Goodle doesn't seem to care much about it because they don't recommend a suitable application architecture. But a good architecture for the application is very important. Regardless of whether you agree, each application should have a schema. Therefore, you'd better design a schema for your application, rather than letting it evolve.

# # Clear Software Architecture

Today's popular architecture is a clear software architecture for Web applications published by Uncle Bob in 2012.

But I found this clear software architecture too heavyweight for Android apps.
In general, mobile apps are easier than web apps. Mobile technology has changed so quickly that applications released today may be out of date a year later.
Mobile apps are usually relatively simple, and more usage scenarios are just processing data. Get the data from the API and show the data to the user. More is reading, there is little need to write content.

This also makes the business logic of mobile applications less complex, at least not more complex than back-end applications. Of course, you also need to deal with some of the mobile platform's problems: memory, storage, pause, re-run, network, geolocation, etc. But these are not your business logic.

Therefore, for most applications, there is not much benefit from a complex hierarchical architecture or a prioritized task queue.

They may simply need to organize the code in a simple way, so that parts of the components work together efficiently and easily find bugs.

# # Introduction to Flux Application architecture

The Flux application Architecture is used by Facebook for architecting client-side Web applications, similar to clean Architecture and not for mobile applications, and its simplicity allows us to apply a lot to Android apps.

There are two key features that can help us understand flux:

• Data flow is always one-way
  A one-way data stream is at the heart of the Flux application architecture, which makes it easy to learn. It also provides a convenient condition when you need to test your application.

• The application is divided into three parts:

  • View : The application interface, which is used to convert the user's interaction to an action.
  • Dispatcher : The central dispatcher distributes all the actions to each store that handles them;
  • Store : maintains the status of a specific application area. They process the action based on the current state, execute the business logic, and issue a change event when processing is complete. This event is used to notify the view update UI.

These three parts interact with the action, which is a simple object identified by type, which contains some data related to the action.

# # Flux Architecture for Android

The main goal of using the flux principle in Android development is to create a simple, scalable, easy-to-test application architecture.

The first step is to create a relational mapping of the flux elements between Android components .

These two types of elements are very easy to implement:

• View: Activity or Fragment;
• Dispatcher: An event bus, I used Otto in the example, but other implementations can also be considered, such as Androideventbus.

# # Actions

Action is not complex, they are usually simple objects that contain the following two main attributes:

• Type: A string field that identifies the event type;
• Data: A map field that contains the action information.

For example, an action that shows some user detail is as follows:

1 2 3 4

Bundle Data = New Bundle ( ) ;      Data . put ( "user_id" , ID ) ;      Action Action = New viewaction ( "Show_user" , Data ) ;

# # Stores

Stores should be the most difficult to understand in the flux concept.

If you've used clean Architecture before, you'll feel it's not so easy to understand, because stores assumes responsibility has been split into different layers.

Stores contains the state of the application and the business logic , which is much like a fully functional data Model , but they can manage the state of various objects, not just one.

Stores responds to the action issued by dispatcher, executes the business logic, and issues a change event after the processing is complete.

Stores only outputs a change event, and any component that is interested in the internal state of a store needs to listen for the event and use it to fetch the data.

Other parts of the system do not need to know the state of the app.

Finally, the store must expose an interface to get the app state. This allows the view element to query the status of the store and update the UI.

For example, in a Bar finder app, Searchstore is used to track search bars, search results, and past bar history data. The other reviewedstore contains a list of the bars that have been viewed, as well as the necessary logic, such as sorting.

Then there is an important concept you have to remember: the store is not repositories. Their responsibility is not to fetch data from external sources (APIs or databases), but to chase the data provided by the action.

So how does flux get the data?

# # Network requests and asynchronous calls

In the previous flux chart, I purposely omitted part of it: network invocation . The next chart will refine this part of the details.

Asynchronous network calls are triggered from the actions Creator , and a network adapter triggers an asynchronous network call and returns the results to the actions Creator .

The final Actions Creator will distribute the action with the corresponding type and data.

There are two advantages to isolating all network requests and asynchronous operations from the store:

• The operations in the store are fully synchronized : This makes the business logic in the store very simple and bugs easy to spot. And, since the application of "all state changes must be synchronous" into practice, the test store becomes very easy, just load the action and then make an assertion judgment on the final state;

• all actions are triggered from Action creator : Creating and starting all user actions from a single point makes it easy to find errors. Eliminates the need to find the point of origin of the action between classes, all actions are from action Creator. Because the asynchronous call has been called before the action is issued, the other Actioncreator functions are synchronous, which greatly improves the traceability and testability of the code.

# Show me the code:to-do App

This example is a to-do Android application implemented in accordance with the flux architecture.

I tried to demonstrate as simple as possible how to use the flux architecture to build a well-organized application.

Some explanations for this implementation:

• The dispatcher is implemented using the Otto event bus. Any event bus is OK. In the original flux definition, it is not allowed to distribute a new event before the end of the previous event, and an exception is thrown. For the sake of simple code, I did not implement this function in this project;
• The Actionscreator class is used to create an action and post it to dispatcher. This is a more common pattern in flux.
• The action type has only string constants. This may not be the best implementation, but it is the quickest and most simple to keep.

The data in the action is also stored using only HashMap with the key string, value as the object type. So this requires you to do a forced type conversion in the store, generally getting specific action data. Of course, this is not type-safe, or that sentence: to keep it simple.

# # Conclusion

There is no best Android app architecture, only the one that works best for your application. This architecture allows you and your teammates to work together conveniently to complete your application in the specified time frame.

I believe that the flux structure in these areas is still more reliable, do not believe in their own hands to try it!

Sample code

Here's the code.

Deep reading

• Facebook Flux
  Overview
• Testing Flux
  Applications
• Flux Architecture Step by
  Step
• Async requests and
  Flux
• Flux and
  Android

Flux Architecture for Android