Android IPC Mechanisms #2 — Messenger
In the previous articles, we talked about the definition of IPC and the AIDL method, and we created client-server applications using the AIDL method. You can find all parts of the series at the end of the article.
Now we will improve these two applications to support the Messenger method.
What is Messenger?
Messenger is a Handler sent to the remote process.
This technique has the Binder architecture like the AIDL technique mentioned in the previous article. Messenger is much easier to implement than the AIDL technique because it creates and uses AIDL files in the background. The developer does not need to bother with this implementation.
But as we have encountered from time to time, tools that are easy-to-implement can bring limitations, while hard-to-implement tools can provide flexibility. Messenger and AIDL method fits exactly to this situation:
- For example, with AIDL, you are able to do concurrent operations. In Messenger, the calls are queued and executed sequentially. It is guaranteed that calls will be received from at most one process/thread at a time of t.
How will things work?
As in the previous example, the client will bind to the server’s service. In this way, the server will return the Messenger object to the client. Thus, the two applications will be able to communicate through Message objects.
Begin with the Server Application
Declare the filter in Manifest
- Let’s add the “messengerexample” action to be sent from the client application to the service with intent. Thus, we will determine which IPC method the client uses.
Update the service
- Create a Handler object in the service to handle the messages from the client
- We are updating the RecentClient object to update the GUI according to the incoming message
- Let’s create the Messenger with the Handler object. Communication will take place through this object
- The msg.replyTo object is obtained from the client’s message. In this example, we don’t need that, but it is possible to assign it to a local variable and use it to send a message back to the client at any time. For example, if a long process is triggered on the server, it can be used in a scenario such as returning a callback to the client at the end of the transaction. Perhaps the biggest advantage of Messenger is that two-way communication can be established with little effort
- The constants we use as bundle keys in messages
- Update the onBind method in our service for the client that binds to the service with the “messengerexample” action.
- The Messenger object has an internal binder. We return this to the client.
That’s it for the server application. When a client is connected with Messenger, the GUI will look like this:
Client Application
- Let’s add the constants we use as bundle keys here too
- We are using the same xml we used for the Aidl fragment. Only the button name is different:
Update the Fragment
- This time we are defining two Messenger objects.
- clientMessenger: to send a message to the server
- serverMessenger: to tell the server “use me when replying to my message”
- Define a handler to handle incoming messages. Update the graphical interface here.
- Bind to the server when the connect button is clicked
- Unbind when disconnect button is clicked
- If a connection is established with the service after calling the bindService command, we receive the callback onServiceConnected.
- Send the message to the server when we receive the callback
- Declare the object for which we expect responses by saying message.replyTo = clientMessenger
- If the service connection is lost, let’s remove the information on the GUI
- We will handle the response in our handler object we have defined at the beginning
- The final version of the fragment will look like this,
We have also completed the client application. Once connected, the user interface will look like this:
You can access the next article includes the Broadcast technique here.
Other parts of the series:
