Starting versus binding in Java

Maker QR Code 2d barcode in Java Starting versus binding

Services serve two purposes in Android, and you can use them in two different ways:

Starting Context.startService(Intent service, Bundle b) Binding Context.bindService(Intent service, ServiceConnection c, int

flag)

Starting a Service tells the platform to launch it in the background and keep it running, without any particular connection to any other Activity or application. You used the WeatherAlertService in this manner to run in the background and issue severe weather alerts. Binding to a Service, as you did with WeatherReporterService, gave you a handle to a remote object, which let you call the service s exported methods from an Activity. Because every Android application runs in its own process, using a bound Service lets you pass data between processes. The actual process of marshaling and unmarshaling remotable objects across process boundaries is complicated. Fortunately, you don t have to deal with all the internals, because Android handles all the complexity through AIDL. Instead, you can stick to a simple recipe that will enable you to create and use remotable objects:

Define your interface using AIDL, in the form of a .aidl file; see listing 4.7. Generate a Java interface for your .aidl file. This happens automatically in Eclipse. Extend from the generated .Stub class and implement your interface methods; see listing 4.8. Expose your interface to clients through a Service and the Service onBind(Intent i) method; see listing 4.8. If you want to make your service available to other applications, export the Service in your manifest; see listing 4.9. Client applications will bind to your Service with a ServiceConnection to get a handle to the remotable object; see listing 4.10.

As we discussed earlier in the chapter, services running in the background can have a detrimental impact on overall device performance. To mitigate these problems, Android enforces a special lifecycle for services, which we re going to discuss now.

We want our weather alerting service to constantly lurk in the background, letting us know of potential dangers. On the other hand, we want our weather reporting service to run only while another application actually needs it. Services follow their own welldefined process phases, similar to those followed by an Activity or an Application. A Service will follow a different lifecycle, depending on whether you start it, bind it, or both.

If you start a Service by calling Context.startService(Intent service, Bundle b), as shown in listing 4.5, it runs in the background whether or not anything binds to it. If the service hasn t been created, the Service onCreate() method is called. The onStart(int id, Bundle args) method is called each time someone tries to start the service, whether or not it s already running. Additional instances of the Service won t be created. The Service will continue to run in the background until someone explicitly stops it with the Context.stopService() method or when the Service calls its own stopSelf() method. You should also keep in mind that the platform might kill services if resources are running low, so your application needs to be able to react accordingly. You can choose to restart the service automatically, fall back to a more limited feature set without it, or take some other appropriate action.

If an Activity binds a Service by calling Context.bindService(Intent service, ServiceConnection connection, int flags), as shown in listing 4.10, it ll run as long as the connection is open. An Activity establishes the connection using the Context and is also responsible for closing it.

When a Service is only bound in this manner and not also started, its onCreate() method is invoked, but onStart(int id, Bundle args) is not used. In these cases, the platform can stop and clean up the Service after it s unbound.