I know that onReceive() of the Broadcast receiver and handleMessage() of Handler run on the same UI thread. Suppose I want to communicate between two services, within the same app (process) . I can extend a broadcast receiver class and register an event
OR
a Handler and then pass its instance to the other service to be used for sendMessage() calls. In both the cases I would need to add some new switch case. But which approach is more efficient ? Lets assume that the code is thread safe (no UI updations).
Broadcast in android is the system-wide events that can occur when the device starts, when a message is received on the device or when incoming calls are received, or when a device goes to airplane mode, etc. Broadcast Receivers are used to respond to these system-wide events.
A Service receives intents that were sent specifically to your application, just like an Activity. A Broadcast Receiver receives intents that were broadcast system-wide to all apps installed on the device.
A broadcast receiver (receiver) is an Android component which allows you to register for system or application events. All registered receivers for an event are notified by the Android runtime once this event happens.
A broadcast receiver will always get notified of a broadcast, regardless of the status of your application. It doesn't matter if your application is currently running, in the background or not running at all.
You should not use normal broadcasts to communicate between Activities
and Services
inside of your own app. You should use local broadcasts instead! First you have to define a BroadcastReceiver
like for normal broadcasts:
private static final String ACTION_EXAMPLE = "ACTION_EXAMPLE";
private final BroadcastReceiver receiver = new BroadcastReceiver() {
@Override
public void onReceive(Context context, Intent intent) {
if(ACTION_EXAMPLE.equals(intent.getAction())) {
...
}
}
};
After that you can get the LocalBroadcastManager
like this:
LocalBroadcastManager manager = LocalBroadcastManager.getInstance(getActivity());
And you can register the BroadcastReceiver
like this (normally you register a BroadcastReciever
in onResume()
):
@Override
public void onResume() {
super.onResume();
LocalBroadcastManager manager = LocalBroadcastManager.getInstance(getActivity());
IntentFilter filter = new IntentFilter(ACTION_EXAMPLE);
manager.registerReceiver(this.receiver, filter);
}
Don't forget to unregister the BroadcastReceiver
later on (in onPause()
):
@Override
public void onPause() {
super.onPause();
LocalBroadcastManager manager = LocalBroadcastManager.getInstance(getActivity());
manager.unregisterReceiver(this.receiver);
}
And finally you can send local broadcasts like this:
LocalBroadcastManager manager = LocalBroadcastManager.getInstance(getActivity());
manager.sendBroadcast(intent);
I can extend a broadcast receiver class and register an event
If you mean that you are doing this via LocalBroadcastManager
(see Mr. Kapeller's excellent answer for details), Handler
will be slightly more efficient, as LocalBroadcastManager
uses a Handler
. However, the performance difference should not be enough to matter. The same goes for other in-process event bus implementations, such as greenrobot's EventBus and Square's Otto. All should be fast enough that other concerns, such as maintainability, should be paramount.
If you mean that you are doing this via system broadcasts (e.g., sendBroadcast()
called on a Context
), then Handler
, LocalBroadcastManager
, or other event bus implementations will be significantly faster, and more secure as well.
All of this assumes that the two services are in the same process.
The fastest solution of all is to combine the two services into one. This is particularly true if they have the same lifespan. There are plenty of cases where having 2+ services in an app is reasonable, but don't create lots of independent little services without a clear reason to do so.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With