Multithreaded event processing for the use of eventbus in Android

In the last article in this series of tutorials, I want to talk about how simple and effective GR's eventbus is when dealing with multithreaded asynchronous tasks.

Asynctask, loader and executor... Please!

There are many ways to perform asynchronous operations (parallel to UI threads) in Android. Asynctask is the simplest mechanism for users and requires only a small amount of setup code. However, its use is limited, as described in the official Android documentation:

Asynctask is designed as a tool class, which contains thread and handler, but it is not part of the general threading framework. Asynctask should be used to perform short operations (up to a few seconds) as much as possible. If you need to perform tasks in a thread for a long time, it is recommended that you directly use various APIs provided in the java.util.concurrent package, such as executor, ThreadPoolExecutor and futuretask.

However, even short-term operations can cause some problems, especially in areas related to the activity / fragment life cycle. Because asynctask will continue to run (even if the activity / fragment that started them has been destroyed). In this way, once you try to update the UI in the onpostexecute method, you will eventually throw an IllegalStateException.

The loader API is introduced in Android 3.0 to solve the problem of activity / fragment life cycle (they are really effective). The loader API is designed to load data asynchronously into activity / fragment. Although loading data is a very common asynchronous operation, it is not the only one that needs to be separated from the UI thread. Loader also needs to implement another listening interface in activity / fragment. Although there is nothing wrong with this, I personally don't like this mode (I mean that eventually your code will contain many callback functions, resulting in poor readability of the code). Finally, activity and fragment are not the only places where asynchronous operations need to be threaded. For example, if you are in a service, you cannot access the loadermanager, so eventually you have to use asynctask or java.util.concurrent.

The java.util.concurrent package is very good. I can use it in both Android and non Android projects. However, you need to configure and manage it a little more when using it, which is not as simple as asynctask. You need to initialize executorservice, manage and monitor its life cycle, and may need to deal with some future objects.

Asynctask, loader, and executor are very effective when used properly. However, in complex applications, you need to select the appropriate tools for each task. Eventually, you may use all three. In this way, you have to maintain three different framework codes to deal with concurrency.

Green robot is here to help!

GR's eventbus has built-in a great concurrent processing mechanism. In the listening class, you can implement four different types of processing methods. When a matching event is sent, eventbus will send the event to the corresponding processing method according to different concurrency models:

Onevent (t event): runs in the same thread as the sent event. Onevent mainthread (t event): runs in the main (UI) thread, regardless of which thread the event is sent from. Oneventasync (t event): runs in a separate thread, that is, neither the UI thread nor the thread that sends events. Onevent backgroundthread (t event): if the thread sending the event is not a UI thread, it runs in that thread. If the event is sent by a UI thread, it runs in a separate thread maintained by eventbus. Multiple events are processed synchronously by this single background thread.

These methods are powerful and easy to use. For example, there is a time-consuming operation (possibly network call, large amount of data processing, etc.), which needs to be triggered by the behavior on the UI, and the UI needs to be updated after the operation is completed. In this example, the UI behavior is button click, the button is in the activity, and the time-consuming operation is in the service. We can implement it in the following ways:

Java

Although this example is relatively simple, it illustrates the problem very briefly. There is no need to implement the listening interface, and there will be no problems such as life cycle (because the activity can receive operationcompleteevent event only when it exists). In addition, if a configuration change (rotating the screen) or any other reason causes the activity to be destroyed and rebuilt between the two events, the operationcompleteevent event event can still be received.

In addition, we can easily think of some other uses. For example, if you need to send the update progress, you just need to implement another event class that encapsulates the progress value, and then send it. Alternatively, if you want some other events (whether the same or different types) not to be processed in parallel (synchronous execution), you can choose to use onevent backgroundthread.

Dependent on bus

The easiest way to instantiate eventbus is through eventbus. Getdefault(). However, there are other useful configuration methods in the eventbusbuilder class (obtained through eventbus. Builder()). Especially the use of your own executorservice mentioned in this article. By default, eventbus creates its own executorservice through executors. Newcachedthreadpool(), which meets your needs in most cases. However, sometimes you may still want to explicitly control the number of threads used by the eventbus. In this case, you can initialize the eventbus as follows:

Java

Other configurable controls in eventbus builder are those related to exception handling and a control switch to allow event classes to be inherited. These are beyond the scope of this article, but I suggest you study them carefully. GR may not have written all these contents in the document, but if you read the source code of eventbusbuilder and eventbus, I believe you will easily understand them.