Bound services

Bound services

A bound service is the server in a client-server interface. A bound service allows components (such as activities) to bind to the service, send requests, receive responses, and even perform interprocess communication (IPC). A bound service typically lives only while it serves another application component and does not run in the background indefinitely.

The Basics

Multiple clients can connect to the service at once. However, the system calls your service's onBind() method to retrieve the IBinder only when the first client binds. The system then delivers the same IBinder to any additional clients that bind, without calling onBind() again.

Creating a Bound Service

When creating a service that provides binding, you must provide an IBinder that provides the programming interface that clients can use to interact with the service. There are three ways you can define the interface:

a> Extending the Binder class

If your service is private to your own application and runs in the same process as the client (which is common), you should create your interface by extending the Binder class and returning an instance of it from onBind().

This is the preferred technique when your service is merely a background worker for your own application. The only reason you would not create your interface this way is because your service is used by other applications or across separate processes.

b> Using a Messenger

If you need your interface to work across different processes, you can create an interface for the service with a Messenger.

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.

Extending the Binder class

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

Here's how to set it up:

1> In your service, create an instance of Binder that either:

a> contains public methods that the client can call

b> returns the current service instance, which has public methods the client can call

c> or, return an instance of another class hosted by the service with public methods the client can call

2> Return this instance of Binder from the onBind() callback method.

3> In the client, receive the Binder from the onServiceConnected() callback method and make calls to the bound service using the methods provided.

The reason the service and client must be in the same application is so the client can cast the returned object and properly call its APIs. The service and client must also be in the same process, because this technique does not perform any marshalling across processes.

Using a Messenger

If you need your service to communicate with remote processes, then you can use a Messenger to produce the interface for your service. This technique allows you to perform interprocess communication (IPC) without the need to use AIDL.

Here's a summary of how to use a Messenger:

a> The service implements a Handler that receivers a callback for each call from a client.

b> The Handler is used to create a Messenger object (which is reference to the Handler).

c> The Messenger creates an IBinder that the service returns to clients from onBind().

d> Clients use the IBinder to instantiate the Messenger (that references the service's Handler), which the client uses to send Message objects to the service.

e> The service receives each Message in its Handler --- specifically, in the handleMessage() method.

In this way, there are no "methods" for the client to call on the service. Instead, the client delivers "messages" (Message objects) that the service receives in its Handler.

Binding to a Service

Application components (clients) can bind to a service by calling bindService(). The Android system then calls the service's onBind() method, which returns an IBinder for interacting with the service.

The binding is asynchronous. bindService() returns immediately and does not return the IBinder to the client. To receive the IBinder, the client must create an instance of ServiceConnection and pass it to bindService(). The ServiceConnection includes a callback method that the system calls to deliver the IBinder.

Only activities, services, and content providers can bind to a service --- you cannot bind to a service from a broadcast receiver.

So, to bind to a service from your client, you must:

1> Implement ServiceConnection.

onServiceConnected()

onServiceDisconnected()

The Android system calls this when the connection to the service is unexpectedly lost, such as when the service has crashed or has been killed. This is not called when the client unbinds.

2> Call bindService(), passing the serviceConnection implementation.

3> When the system calls your onServiceConnected() callback method, you can begin making calls to the service, using the methods defined by the interface.

4> To disconnect from the service, call unbindService().

Additional notes

a> You should always trap DeadObjectException exceptions, which are thrown when the connection has broken. This is the only exception thrown by remote methods.

b> Objects are reference counted across processes.

c> You should usually pair the binding and unbinding during matching bring-up and tear-down moments of the client's lifecycle.

d> You should usually not bind and unbind during your activity's onResume() and onPause().

Managing the Lifecycle of a Bound Service