7

Now Activity can connect to services using one of three ways:

I think that BroadcastReceivers is the easiest way to communicate but I'm wondering why and when to use other ways? or in other words in which cases messengers or AIDL will be the best practice to use than broadcastreceivers?

Hazem Hagrass
  • 9,329
  • 10
  • 32
  • 54
  • 1
    You should start from considering whether your service is running in the same process of your activity or it is running on a different process then your activity. – Eido95 Nov 09 '16 at 15:27
  • yeah I have used binding before and in my latest project, I used broadcasts and broadcasts are much easier to work with – yeahman Dec 04 '16 at 05:54

4 Answers4

13

I mostly tend to use LocalBroadcasts. They essentially are like real broadcasts, but only visible to your application. First you have to create a BroadcastReceiver like you would with a normal broadcast:

private final BroadcastReceiver broadcastReceiver = new BroadcastReceiver() {

    @Override
    public void onReceive(Context context, Intent intent) {
        String action = intent.getAction();
        if(Intent.SOME_ACTION.equals(action)) {
            // Do your work
        }
    }
};

You can then register and unregister the BroadcastReceiver like this:

@Override
public void onResume() {
    super.onResume();

    IntentFilter intentFilter = new IntentFilter(Intent.SOME_ACTION);

    LocalBroadcastManager manager = LocalBroadcastManager.getInstance(getActivity());
    manager.registerReceiver(broadcastReceiver, intentFilter);
}

@Override
public void onPause() {
    super.onPause();

    LocalBroadcastManager manager = LocalBroadcastManager.getInstance(getActivity());
    manager.unregisterReceiver(broadcastReceiver);
}

And finally you can send a broadcast from your Service or anywhere else in your application like this:

Intent intent = new Intent(Intent.SOME_ACTION);

LocalBroadcastManager manager = LocalBroadcastManager.getInstance(getActivity());
manager.sendBroadcast(intent);
Xaver Kapeller
  • 49,491
  • 11
  • 98
  • 86
  • 2
    Agreed. This, or third-party message buses (Square's Otto, greenrobot's EventBus), are the current best practices. – CommonsWare May 11 '14 at 20:30
  • `Messengers` are not commonly used, that is also the reason why there is so little documentation on the subject. They are mostly used for communicating across different processes. – Xaver Kapeller May 12 '14 at 13:45
  • you cannot use LocalBroadcastManager across different processes (e.g. when communicating between an activity and a service running on a different process) – Manuela May 08 '20 at 08:32
12

You can use BroadcastReceiver when you want the communication between Service and Activity in your application.

Messenger's and AIDL's are mainly used when your application needs to communicate to other processes(IPC). In this case your interface should have a Service which defines a Handler that responds to different types of Message objects.

Now the difference between Messenger and AIDL is pretty simple. When you use Messenger, it queues all requests into a single thread. So your Service doesn't have to be thread safe. If, you want your Service to handle multiple requests simultaneously, then you can use AIDL directly. In this case, your Service must be capable of multi-threading and be built thread-safe. In fact Messenger is implemented on the top of AIDL.

For better understanding look at Bound Services

You should also check the answer from BroadcastReceiver or Messenger via Handler

Community
  • 1
  • 1
azizulhakim
  • 658
  • 7
  • 24
3

Xaver Kapeller's answer is indeed a good one. However, it has a (major) drawback: broadcasts can be missed.

When the user navigates away from the Activity (for example by showing the recent apps), you unregister your BroadcastReceivers. If the broadcast is sent at that moment, your Activity does not receive it. When navigating back to your Activity, it might be in an invalid state.

Using a ResultReceiver, you still receive the result in this case. Furthermore, a ResultReceiver is parcelable, so you can save and restore it in the lifecycle events.
It causes some overhead though, which is why I've created this experimental library to ease it up a little. For now it only uses IntentServices, but it should be easy enough to extend.

nhaarman
  • 98,571
  • 55
  • 246
  • 278
  • Yeah it's true that broadcasts can be missed, but normally if your app absolutely depends on receiving the broadcast than you are doing something wrong. Local broadcasts should never be used to actually transfer data or anything like that. A use case for local broadcasts would for example be that you notify a `Fragment` that a task has finished or data has changed and needs to be reloaded, in other words things that are irrelevant to the state of the app itself, they just give extra - but essentially unnecessary - info. – Xaver Kapeller May 12 '14 at 13:52
2

If your service is used only by the local application and does not need to work across processes, then you can implement your own Binder class that provides your client direct access to public methods in the service.

Note: This works only if the client and service are in the same application and process`, which is most common.

Extending the Binder class http://developer.android.com/guide/components/bound-services.html#Binder

Libin
  • 16,967
  • 7
  • 61
  • 83