EventBus in Android: a complete guide to the event bus

Development of complex mobile applications on the platform Android often faces the problem of efficient data exchange between components. Traditional methods such as callback interfaces or broadcasts can become cumbersome and difficult to maintain as a project grows. This is where EventBus comes in, a popular library that simplifies communication within an application.

This tool allows objects to send and receive events without having to know about each other directly, significantly reducing code coupling. Understanding the principles of operation EventBus is critical for architects and developers seeking to create scalable systems. In this article, we will look in detail at how this event bus works, when it should be used, and what pitfalls can await beginners.

Many developers confuse the event bus with other asynchrony mechanisms, but it has its own clear niche of application. We will look at real use cases, compare the library with more modern analogues from Google and give practical recommendations for implementation.

The principle of operation and architecture of the event bus

The basis of the work EventBus The “Publisher-Subscriber” pattern lies. This is an architectural pattern that allows you to separate message sending and message processing. Instead of Component A directly calling a method on Component B, Component A simply publishes the event to the public bus.

Any other component that has subscribed to this event type in advance will automatically receive a notification. This approach makes the code modular: you can add new functions by simply creating new subscribers, without touching the logic of those who generate events. This is especially useful in large projects where modules are developed by different teams.

The library takes care of all the routine work of managing queues and threads. You don't need to manually create Handler or manage thread lifecycles for simple interface synchronization tasks. Just annotate the subscription method, and the delivery mechanism will work automatically.

⚠️ Warning: Using a global event bus can turn the application architecture into "spaghetti code" if you do not follow clear rules for naming events and documenting which components are subscribed to what.

It is important to understand the difference between synchronous and asynchronous delivery. By default, events are delivered on the same thread where they were published. However, the library allows you to flexibly configure this behavior, switching execution to a background thread or a Main Thread thread depending on the needs of the task.

Connecting and basic project setup

To get started, you need to add a dependency to your project's build file. Today, the current version is the 3rd branch of the library, which supports working with AndroidX. The integration process is as simple as possible and does not require complex manifest settings.

In the file build.gradle (module level) you need to add the following line to the dependency block:

implementation'org.greenrobot:eventbus:3.3.1'

After synchronizing the project, the library becomes available for use. The main class through which interaction occurs is called EventBus. You can get a bus instance through the static method EventBus.getDefault. This is an implementation of the Singleton pattern, ensuring that there is only one central point of event coordination throughout the entire application.

However, simply including the library is not enough. The key is to register and unsubscribe components correctly. If you forget to unsubscribe Activity or Fragment when they are destroyed, this will lead to memory leaks and application crashes when trying to deliver an event to an already non-existent object.

Creating subscribers and processing events

For a component to start responding to events, it must be registered in the bus. This is usually done in the onStart life cycle Activity or Fragmentmethod. Accordingly, unsubscription should occur in the onStopmethod. This approach ensures that the component will receive events only when it is visible to the user or active.

The method EventBus.getDefault.register(this)is used for registration. The method itself that will process the event must be marked with annotation @Subscribe. The signature of a method is strictly defined: it must be public, return void and take exactly one argument - an event object.

Consider an example of creating a simple event. Let's say we need to update the list of products after successfully downloading data from the network. We create an event class:

public class ProductsLoadedEvent {
private final List products;
public ProductsLoadedEvent(List products) {
this.products = products;
}
public List getProducts {
return products;
}
}

Now in Activity, which displays the list, we create a subscriber method. The annotation allows you to set the priority and flow mode. The default mode is PostingThread, which means execution on the sender thread.

Using different flow modes allows you to flexibly manage performance. For example, it is better to carry out heavy calculations in Background, and updating the UI - strictly in Main. An error in thread selection can lead to interface freezes or thread safety exceptions.

Publishing events and stream types

Posting an event is the simplest operation, performed with a single line of code. You create an event object and pass it to the bus via the postmethod. At this moment, the library instantly finds all subscribers and calls their processing methods according to the specified parameters threadMode.

There are four main delivery modes, each of which solves a specific problem. Mode POSTING executes the subscriber code in the same thread as posting. This is the fastest option, ideal for light operations that do not affect the UI.

Mode MAIN guarantees execution in the main application thread. If an event is sent from a background thread, it will be queued and executed later. This is the standard choice for updating interface elements such as TextView or RecyclerView.

For tasks that require time, but do not require strict sequence, the ASYNCmode is suitable. Events are processed in a separate thread from the pool, which allows neither the sender nor the main thread to block. However, the order of delivery in this mode is not guaranteed.

⚠️ Warning: Never perform long operations or network requests in the subscriber method with MAIN mode. This will lead to an ANR (Application Not Responding) error and a deterioration in user experience.

The fourth mode, BACKGROUNDworks the other way around: if you are already in the main thread, the event will go into the background, and if in the background, it will be executed in the same place. This is convenient for processing data coming from the UI that needs to be saved to the database.

Comparison of EventBus with LiveData and Flow

With the advent of architectural components Android Jetpacksuch as LiveData and Kotlin Flow, the question of the relevance of EventBus has become very acute. Many developers believe that the event bus is obsolete, but this is not entirely true. Each tool has its own strengths.

LiveData is tied to the owner's lifecycle (LifecycleOwner), which automatically solves the problem of memory leaks, which was the bane of earlier versions of EventBus. It also stores the last value and gives it to the new subscriber immediately after registration. This makes LiveData ideal for displaying the state of data.

However, EventBus benefits in scenarios where the event is a one-time action signal rather than state. For example, navigating between screens, showing a pop-up notification (Toast), or sending analytics. In such cases, storing the "last value" in LiveData may cause the action to fire again when the screen is rotated, which is an error.

android {
defaultConfig {
javaCompileOptions {
annotationProcessorOptions {
arguments = [eventBusIndex:'com.example.MyEventBusIndex']
}
}
}
}