STING 91 A skeleton Service class

import android.app.Service; import android.content.Intent; import android.os.IBinder;

public class MyService extends Service {

©Override public void onCreate() {

// TODO: Actions to perform when service is created.

Available for download on Wrox.com

©Override public IBinder onBind(Intent intent) {

// TODO: Replace with service binding implementation. return null;

In most cases you'll also want to overridenStartCommand. This is called whenever the Service is started with a call to startService, so it may be executed several times within a Service's lifetime. You should ensure that your Service accounts for this.

The onStartCommand handler replaces the onStart event that was used prior to Android 2.0. By contrast, it enables you to tell the system how to handle restarts if the Service is killed by the system prior to an explicit call to stopService or stopSelf.

The following snippet extends Listing 9-1 to show the skeleton code for overriding the onStartCommand handler. Note that it returns a value that controls how the system will respond if the Service is restarted after being killed by the run time.

©Override public int onStartCommand(Intent intent, int flags, int startId) { // TODO Launch a background thread to do processing. return Service.START_STICKY;

Services are launched on the main Application thread, meaning that any processing done in the onStartCommand handler will happen on the main GUI thread. The standard pattern for implementing a Service is to create and run a new thread from onStartCommand to perform the processing in the background and stop the Service when it's complete (you will be shown how to create and manage background threads later in this chapter).

This pattern lets onStartCommand complete quickly, and lets you control the restart behavior using one of the following Service constants:

> start_sticky Describes the standard behavior, which is similar to the way in which onStart was implemented prior to Android 2.0. If you return this value, onStartCommand will be called any time your Service restarts after being terminated by the run time. Note that on a restart the Intent parameter passed in to onStartCommand will be null.

This mode is typically used for Services that handle their own states, and that are explicitly started and stopped as required (via startService and stopService). This includes Services that play music or handle other ongoing background tasks.

> start_not_sticky This mode is used for Services that are started to process specific actions or commands. Typically they will use stopSelf to terminate once that command has been completed.

Following termination by the run time, Services set to this mode will restart only if there are pending start calls. If no startService calls have been made since the Service was terminated, the Service will be stopped without a call being made to onStartCommand.

This mode is ideal for Services that handle specific requests, particularly regular processing such as updates or network polling. Rather than restarting the Service during a period of resource contention, it's often more prudent tolet the Service stop and retry at the next scheduled interval.

> start_redeliver_intent In some circumstances you will want to ensure that the commands you have requested from your Service are completed.

This mode is a combination of the first two —if the Service is terminated by the run time, it will restart only if there are pending start calls or the process was killed prior to its calling stopSelf.

In the latter case, a call to onStartCommand will be made, passing in the initial Intent whose processing did not properly complete.

Note that each mode requires you to explicitly stop your Service, through stopService or stopSelf respectively, when your processing has completed. Both of these methods are discussed in more detail later in this chapter.

Prior to Android SDK 2.0 (SDK API level 5) the Service class triggered the onStart event handler to let you perform actions when the Service started. Implementing the onStart handler is now the equivalent of overriding onStartCommand and returning the start_sticky flag.

The restart mode you specify in your onStartCommand return value will affect the parameter values passed in to subsequent calls.

Initially the Intent will be the parameter you passed in to startService to start your Service. After system-based restarts it will be either null, in the case of start_sticky mode, or the original Intent, if the mode is set to start_redeliver_intent.

The flag parameter can be used to discover how the Service was started. In particular you can use the code snippet shown in Listing 9-2 to determine if either of the following cases is true:

> start_flag_redelivery Indicates that the Intent parameter is a redelivery caused by the system run time's having terminated the Service before it was explicitly stopped by a call to stopSelf.

> start_flag_retry Indicates that the Service has been restarted after an abnormal termination. Passed in when the Service was previously set to start_sticky.

Mobile Apps Made Easy

Mobile Apps Made Easy

Quick start guide to skyrocket your offline and online business success with mobile apps. If you know anything about mobile devices, you’ve probably heard that famous phrase coined by one of the mobile device’s most prolific creators proclaiming that there’s an app for pretty much everything.

Get My Free Training Guide


Post a comment