> Creating, starting, and stopping Services
> Binding Services to Activities
> Setting Service priority to foreground
> Using AsyncTasks to manage background processing
> Creating background threads and using Handlers to synchronize with the GUI thread
> Displaying Toasts
> Using the Notification Manager to notify users of application events
> Creating insistent and ongoing Notifications
> Using Alarms to schedule application events
Android offers the Service class to create application components specifically to handle operations and functionality that should run invisibly, without a user interface.
Android accords Services a higher priority than inactive Activities, so they're less likely to be killed when the system requires resources. In fact, should the run time prematurely terminate a Service that's been started, it can be configured to restart as soon as sufficient resources become available. In extreme cases, the termination of a Service —such as an interruption in music playback —will noticeably affect the user experience, and in these cases a Service's priority can be raised to the equivalent of a foreground Activity.
By using Services, you can ensure that your applications continue to run and respond to events, even when they're not in active use.
Services run without a dedicated GUI, but, like Activities and Broadcast Receivers, they still execute in the main thread of the application's process. To help keep your applications responsive,
you'll learn to move time-consuming processeslike network lookups) into background threads using the Thread and AsyncTask classes.
Android offers several techniques for applications to communicate with users without an Activity. You'll learn how to use Notifications and Toasts« alert and update users without interrupting the active application.
Toasts are a transient, non-modal dialog-box mechanism used to display information to users without stealing focus from the active application. You'll learn to display Toasts from any application component to send unobtrusive on-screen messages to your users.
Where Toasts are silent and transient, Notifications represent a more robust mechanism for alerting users. In many cases, when the user isn't actively using the mobile phone it sits silent and unwatched in a pocket or on a desk until it rings, vibrates, or flashes. Should a user miss these alerts, status bar icons are used to indicate that an event has occurred. All these attention-grabbing antics are available to your Android application through Notifications.
Alarms provide a mechanism for firing Intents at set times, outside the control of your application life cycle. You'll learn to use Alarms to start Services, opa Activities, or broadcast Intents based on either the clock time or the time elapsed since device boot. An Alarm will fire even after its owner application has been closed, and can (if required) wake a device from sleep.
Unlike Activities, which present a rich graphical interface to users, Services run in the background — updating your Content Providers, firing Intents, and triggering Notifications. They are the perfect means of performing ongoing or regular processing and of handling events even when your application's Activities are invisible or inactive, or have been closed.
Services are started, stopped, and controlled from other application components, including other Services, Activities, and Broadcast Receivers. If your application performs actions that don't depend directly on user input, Services may be the answer.
Started Services always have higher priority than inactive or invisible Activities, making them less likely to be terminated by the run time's resource management. The only reason Android will stop a Service prematurely is to provide additional resources for a foreground component (usually an Activity). When that happens, your Service will be restarted automatically when resources become available.
If your Service is interacting directly with the user (for example, by playing music) it may be necessary to increase its priority to that of a foreground Activity. This will ensure that your Service isn't terminated except in extreme circumstances, but reduces the run time's ability to manage its resources, potentially degrading the overall user experience.
Applications that update regularly but only rarely or intermittently need user interaction are good candidates for implementation as Services. MP3 players and sports-score monitors are examples of applications that should continue to run and update without a visible Activity.
Further examples can be found within the software stack itself: Android implements several Services, including the Location Manager, Media Controller, and Notification Manager.
Was this article helpful?
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.