1. The Intentspecifying the service to start (again, the easiest way is probably to specify the service class, if it’s your own service)
2. A Bundleproviding configuration data, which eventually gets passed to the service’s onStart()method
Conversely, to stop the service, call stopService()with the Intentyou used in the corresponding startService()call.
In Chapter 31, we showed how the service sends a broadcast to let the WeatherPlusactivity know a change was made to the forecast based on movement. Now, we can see how the activity receives and uses that broadcast.
Here are the implementations of onResume()and onPause()for WeatherPlus:
@Override
publicvoid onResume() {
super. onResume();
registerReceiver(receiver,
new IntentFilter(WeatherPlusService.BROADCAST_ACTION));
}
@Override
publicvoid onPause() {
super. onPause();
unregisterReceiver(receiver);
}
In onResume(), we register a static BroadcastReceiverto receive Intentsmatching the action declared by the service. In onPause(), we disable that BroadcastReceiver, since we will not be receiving any such Intentswhile paused, anyway.
The BroadcastReceiver, in turn, simply arranges to update the forecast on the UI thread:
privateBroadcastReceiver receiver = new BroadcastReceiver() {
publicvoid onReceive(Context context, Intent intent) {
runOnUiThread( new Runnable() {
publicvoid run() {
updateForecast();
}
});
}
};
And updateForecast()uses the interface stub to call into the service and retrieve the latest forecast page, also handling the case where the forecast is not yet ready ( null):
privatevoid updateForecast() {
try{
String page = service. getForecastPage();
if(page== null) {
browser. postDelayed( new Runnable() {
publicvoid run() {
updateForecast();
}
}, 4000);
Toast
. makeText( this, "No forecast available", 2500). show();
} else{
browser. loadDataWithBaseURL( null, page, "text/html",
"UTF-8", null);
}
} catch( finalThrowable t) {
svcConn. onServiceDisconnected( null);
runOnUiThread( new Runnable() {
publicvoid run() {
goBlooey(t);
}
});
}
}
CHAPTER 32
Alerting Users via Notifications
Pop-up messages. Tray icons and their associated “bubble” messages. Bouncing dock icons. You are no doubt used to programs trying to get your attention, sometimes for good reason. Your phone also probably chirps at you for more than just incoming calls: low battery, alarm clocks, appointment notifications, incoming text message or email, etc.
Not surprisingly, Android has a whole framework for dealing with these sorts of things, collectively called notifications .
A service, running in the background, needs a way to let users know something of interest has occurred, such as when email has been received. Moreover, the service may need some way to steer the user to an activity where they can act upon the event — reading a received message, for example. For this, Android supplies status-bar icons, flashing lights, and other indicators collectively known as notifications .
Your current phone may well have such icons, to indicate battery life, signal strength, whether Bluetooth is enabled, and the like. With Android, applications can add their own status-bar icons, with an eye towards having them appear only when needed (e.g., when a message has arrived).
In Android, you can raise notifications via the NotificationManager. The NotificationManageris a system service. To use it, you need to get the service object via getSystemService(NOTIFICATION_SERVICE)from your activity. The NotificationManagergives you three methods: one to pester ( notify()) and two to stop pestering ( cancel()and cancelAll()).
The notify()method takes a Notification, which is a data structure that spells out what form your pestering should take. The following sections describe all the public fields at your disposal (but bear in mind that not all devices will necessarily support all of these).
You can flash LEDs on the device by setting lights to true, also specifying the color (as an #ARGBvalue in ledARGB) and what pattern the light should blink in (by providing off/on durations in milliseconds for the light via ledOnMSand ledOffMS).
You can play a sound, using a Urito a piece of content held, perhaps, by a ContentManager(sound). Think of this as a ringtone for your application.
You can vibrate the device, controlled via a long[]indicating the on/off patterns (in milliseconds) for the vibration ( vibrate). You might do this by default, or you might make it an option the user can choose when circumstances require a more subtle notification than an actual ringtone.
While the flashing lights, sounds, and vibrations are aimed at getting somebody to look at the device, icons are designed to take them the next step and tell them what’s so important.
To set up an icon for a Notification, you need to set two public fields: icon, where you provide the identifier of a Drawableresource representing the icon, and contentIntent, where you supply a PendingIntentto be raised when the icon is clicked. You should be sure the PendingIntentwill be caught by something, perhaps your own application code, to take appropriate steps to let the user deal with the event triggering the notification.
You can also supply a text blurb to appear when the icon is put on the status bar ( tickerText).
If you want all three, the simpler approach is to call setLatestEventInfo(), which wraps all three of those in a single call.
Читать дальше