Can someone please distinguish between the scenarios where one should use a broadcast receiver, an AIDL (Android Interface Definition Language), and a messenger? I was told that using a broadcast receiver is battery draining so I should not make use of it. AIDL and messengers are used for IPC (inter process communication) but I could use the AIDL way to pass data from service to an activity within the same process.
So in that scenario, should I prefer an AIDL or a broadcast receiver?
================ UPDATE 24 Jan 2015 ====================
For understanding the difference between Messenger and AIDL mechanism, as per documentation
Using a Messenger
If you need your interface to work across different processes, you can create an interface for the service with a Messenger. In this manner, the service defines a Handler that responds to different types of Message objects. This Handler is the basis for a Messenger that can then share an IBinder with the client, allowing the client to send commands to the service using Message objects. Additionally, the client can define a Messenger of its own so the service can send messages back. This is the simplest way to perform interprocess communication (IPC), because the Messenger queues all requests into a single thread so that you don't have to design your service to be thread-safe.Using AIDL
AIDL (Android Interface Definition Language) performs all the work to decompose objects into primitives that the operating system can understand and marshall them across processes to perform IPC. The previous technique, using a Messenger, is actually based on AIDL as its underlying structure. As mentioned above, the Messenger creates a queue of all the client requests in a single thread, so the service receives requests one at a time. If, however, 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. To use AIDL directly, you must create an .aidl file that defines the programming interface. The Android SDK tools use this file to generate an abstract class that implements the interface and handles IPC, which you can then extend within your service.
In addition to what the docs say, the AIDL implementation involves writing boilerplate code for marshaling and unmarshaling of the transmitted data (using the Parcelable interface) with the ability to receive requests from multiple threads at a time, while the Messenger queues the messages and does the heavy lifting, but in a one request at a time fashion.
For Service-Activity interaction, you should use an asynchronous callback mechanism. The workaround is pretty straightforward, using EventBus library. It basically uses broadcastreceivers for message dispatching and communication between different components of your application.
I highly recommend you take a look at this tutorial and links, since EventBus is nowadays one the most highly-used libraries in android development.
BroadcastReceiver
It is an Asynchronous communication.
Complexity is low- It is the easiest way to communicate between processes.
When sending data via an intent, you should be careful to limit the data size to a few KB. Sending too much data can cause the system to throw a TransactionTooLargeException exception. https://developer.android.com/guide/components/activities/parcelables-and-bundles
The statements that Intents could transfer up to 1Mb worth of data are definitely wrong, 500Kb is more accurate. https://www.neotechsoftware.com/blog/android-intent-size-limit"
Security: A broadcast is transmitted across the Android OS and that could introduce a security threat.Other apps can listen to broadcasts. Any sensitive data should not be broadcasted.
Messenger:
Asynchronous communication.
A reference to a Handler that can be sent to a remote process via an Intent.
Complexity is medium.
Messages sent by the remote process via the messenger are delivered to the local handler.
When using Messenger, it creates a queue of all the client requests that the Service receives one at a time. All this happens on a single thread.
In case you want your Service to handle multiple requests simultaneously then you’ll need to make use of AIDL directly and make sure your Service is capable of multi-threading and also ensure thread-safety.
Ref:http://codetheory.in/android-interprocess-communication-ipc-messenger-remote-bound-services/ https://www.slideshare.net/yoni1984/ipc-aidl-sexy-not-a-curse
AIDL:
It is Synchronous and Asynchronous inter process communication. By default,the AIDL communication is synchronous. In order to make AIDL communication asynchronous, use “oneway” keyword.
Complexity is high - AIDL interface sends simultaneous requests to the service, which must handle multi-threading.
One to One communication
Using the underlying Android OS Binder framework
Requires writing thread-safe code.
The Binder transaction buffer has a limited fixed size, currently 1Mb, which is shared by all transactions in progress for the process. https://developer.android.com/reference/android/os/TransactionTooLargeException.html"
Security: AIDL is allows developers to expose their interfaces to other application. Both the client and service agree upon in order to communicate with each other.
I recommend broadcast receiver.
please see this answer by j2emanue
https://stackoverflow.com/a/22567356/5682331
