1. The Intent
specifying the service to start (again, the easiest way is probably to specify the service class, if it’s your own service)
2. A Bundle
providing configuration data, which eventually gets passed to the service’s onStart()
method
Conversely, to stop the service, call stopService()
with the Intent
you used in the corresponding startService()
call.
In Chapter 31, we showed how the service sends a broadcast to let the WeatherPlus
activity 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 BroadcastReceiver
to receive Intents
matching the action declared by the service. In onPause()
, we disable that BroadcastReceiver
, since we will not be receiving any such Intents
while 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 NotificationManager
is a system service. To use it, you need to get the service object via getSystemService(NOTIFICATION_SERVICE)
from your activity. The NotificationManager
gives 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 #ARGB
value in ledARGB
) and what pattern the light should blink in (by providing off/on durations in milliseconds for the light via ledOnMS
and ledOffMS
).
You can play a sound, using a Uri
to 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 Drawable
resource representing the icon, and contentIntent
, where you supply a PendingIntent
to be raised when the icon is clicked. You should be sure the PendingIntent
will 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.
Читать дальше