Intive Blog

EventBus: An alternative to BroadcastReceiver

It is good to understand the purpose of a tool in order not to overuse it. To do this, before explaining what the star of this article is, the EventBus, it is necessary to shed some light upon some notions.
Whenever you want to develop an app for Android OS two basic questions should be considered:

1) JAVA is the language used when programming

2) A SDK platform is used that, broadly speaking, has four pillars: Activity, Service, BroadcastReceiver and ContentProvider.

An Activity is the means to interact with the user. Generally, one is created for each screen that makes up the application. If the app is, for example, a Post manager, you will probably have an Activity to write a new email and another one to display the inbox.

Instead, the Service has no interaction with the user and is designed to make “long” background tasks. Since Android OS allows you to work with different threads, it is recommended not to overload the main thread with tasks that prevent the user from interacting with the application so agile. An example will show us things in a simpler way.

Suppose we have an audio player. The user should always be able to change track, no matter if a track different from the desired one is being played. Therefore, the main thread will display on screen the menu users will use to play different tracks, while a service, running in the background, will play the selected track.

From all the above, a question arises: How to communicate Activities among themselves, or a Service with an Activity?

a. How to communicate Activities among themselves

For the first of the two cases we should be bear in mind that you can only have an Activity running in running time. There will always be only one that will have the main thread and, therefore, will interact with the user.

Now, when an Activity has fulfilled its aim and it is time to move on to the next, it is usually necessary to pass data to the next. Therefore, the SDK available gives us a helping hand, by providing us with the Intent. This allows us to tell the OS what the next Activity is and attach extra information. Given that this is JAVA and OOP, any instance can be adjusted and received through an Intent, provided it implements a simple interface: Parcelable.

b. How to communicate Activity with a Service

Now we find that an Activity launches a Service, for this, it needs to provide data. In this case, the procedure is almost identical to the previous one, by using an Intent the OS is prompted to start a service in the background, adjusting Intent data. The return could be equally easy, but it is not. Remember then:

  • The Service turn on a thread different to the main thread
  • A Service could be launched by an Activity A and command it to interact with a B and a C.

Consequently, how can the Service know which is the Activity which is actually taking place? Simple, SDK provides with a tool called LocalBroadcastManager which, basically, publishes Intents for its subscribers to receive in execution time. Now it is easy to describe the BroadcastReceiver, since it is an abstract class that, by extending it, we detail what kind if Intents we expect to receive and what to do in case one is received.

At this stage, there is already some notion to understand what the strength of the tool that this article wants to introduce is: the EventBus.

When should we consider using EventBus?

When a Service is used to perform different tasks and a feedback from it is expected, it is important to notice that it generates an Intent of a given type (customizable) and – after attaching the corresponding information to the result of the processing of that task – publishes it using LocalBroadcastManager , to be received by the Activity on hold that contains the corresponding BroadcastReceiver. It should be remembered that BroadcastReceivers, through the intents-filters declared on the Manifest, determine what kinds of Intents must be notified.

That said, a same Service can return different types of Intents with different kinds of attached data, being BroadcastReceiver responsible for decoding those data depending on the Intent. This is why BroadcastReceiver must be smart enough to understand what type of Intent it is, to properly decode later the data attached. When an application escalates, this may become messy since the BroadcastReceiver class should be extended every time we want to use a new type of Intent.

EventBus is born here, to replace the LocalBroadcastManager, therefore allowing any Activity to register itself easily, to implement a callback later for each type of Event you want to have control of. Consequently, the Service, once the processing is over, creates a resulting Event and sends it to the EventBus which analyzes whether the running Activity is subscribed and in case it is and it has a specific callback for that kind of Event it runs it.

The advantage is that it is no longer necessary to extend the class BroadcastReceiver, neither to modify the Manifest according to this, Events and callbacks are simply created for them inside the Activities, which is far more legible and easy to implement.

Below, we can see an example that can be obtained from the official website.


1: Events Implementation

This is part of the model to be implemented. The instances of this classes will contain information to be communicated along the app.

2: Activity Subscription to the EventBus

You can implement an onEvent method for each type of event you want to receive.

3: Post of events

This can be performed from a Service for instance. This way all the subscribed activities would receive messages sent from it which can easily run in the background.


Pablo Gotuzzo

Pablo Gotuzzo works as a Java developer for intive – FDV. He is a member of the Android Team. He is currently studying I.T. engineering at Universidad de Buenos Aires (UBA). He is mainly interested in facing new challenges which involve teamwork and integration of new technologies.

Add comment