Appel d’un service

Les services peuvent être utilisés par n’importe quel composant de l’application capable d’attendre pendant un certain temps. Ceci inclut les activités, les fournisseurs de contenu et les autres services. Par contre, ceci ne comprend pas les récepteurs d’intention purs (les écouteurs qui ne font pas partie d’une activité) car ils sont automatiquement supprimés après le traitement d’une intention. Pour utiliser un service local, vous devez le lancer, obtenir un accès à l’objet service, puis appeler ses méthodes. Vous pouvez ensuite arrêter le service lorsque vous n’en avez plus besoin ou, éventuellement, le laisser s’arrêter de lui-même. L’utilisation des services distants est un peu plus complexe et ne sera pas présentée dans ce livre. Dans ce chapitre, nous étudierons la partie cliente de l’application Service/WeatherPlus. L’activité WeatherPlus ressemble énormément à l’application Weather originale – comme le montre la Figure 31.1, il s’agit simplement d’une page web qui affiche les prévisions météorologiques. La différence est qu’ici ces prévisions changent lorsque le terminal « se déplace », en reflétant les modifications fournies par le service. Pour démarrer un service, il suffit d’appeler startService() en lui passant l’intention qui indique le service à lancer (là encore, le plus simple consiste à préciser la classe du service s’il s’agit de votre propre service). Inversement, on l’arrête par un appel à la méthode stopService(), à laquelle on passe l’intention fournie à l’appel startService() correspondant. Lorsque le service est lancé, on doit communiquer avec lui. Cette communication peut être exclusivement réalisée via les « extras » que l’on a fournis dans l’intention ou, s’il s’agit d’un service local qui offre un singleton, vous pouvez utiliser ce dernier. Dans le cas de WeatherPlus et de WeatherPlusService, le client utilise le singleton du service à chaque fois qu’il veut obtenir de nouvelles prévisions : private void updateForecast() { try { String page=WeatherPlusService .singleton .getForecastPage(); browser.loadDataWithBaseURL(null, page, « text/html », « UTF-8 », null); } catch (final Throwable t) { goBlooey(t); } } Figure 31.1 Le client du service WeatherPlus.  Une partie épineuse de ce code consiste à s’assurer que le singleton est bien là quand on a besoin de lui. L’appel à startService() étant asynchrone, vous reprenez le contrôle tout de suite, or le service démarrera bientôt, mais pas immédiatement. Dans le cas de WeatherPlus, on peut s’en contenter car on n’essaie pas d’utiliser le singleton tant que le service ne nous a pas prévenus de la disponibilité d’une prévision, via une intention de diffusion. Cependant, dans d’autres situations, il faudra peut-être appeler la méthode postDelayed() d’un Handler afin de reporter d’une seconde ou deux l’utilisation du service, en espérant que le singleton sera devenu disponible entre-temps. Capture de l’intention Au chapitre précédent, nous avons vu comment le service diffusait une intention pour signaler à l’activité WeatherPlus qu’un mouvement du terminal avait provoqué une modification des prévisions. Nous pouvons maintenant étudier la façon dont l’activité reçoit et utilise cette intention. Voici les implémentations d’onResume() et d’onPause() de WeatherPlus : @Override public void onResume() { super.onResume(); registerReceiver(receiver, new IntentFilter(WeatherPlusService.BROADCAST_ACTION)); } @Override public void onPause() { super.onPause(); unregisterReceiver(receiver); } Dans onResume(), nous enregistrons un BroadcastReceiver statique pour recevoir les intentions qui correspondent à l’action déclarée par le service. Dans onPause(), nous désactivons ce récepteur car nous ne recevrons plus ces intentions pendant que nous sommes en pause. Le BroadcastReceiver, de son côté, met simplement les prévisions à jour : private BroadcastReceiver receiver=new BroadcastReceiver() { public void onReceive(Context context, Intent intent) { updateForecast(); } }; Livre Android.book . Les messages qui surgissent, les icônes et les « bulles » qui leur sont associées, les icônes qui bondissent dans la barre d’état, etc. sont utilisés par les programmes pour attirer votre attention, et parfois pour de bonnes raisons. Votre téléphone vous alerte aussi probablement pour d’autres motifs que la réception d’un appel : batterie faible, alarme programmée, notifications de rendez-vous, réception de SMS ou de courrier électronique, etc. Il n’est donc pas étonnant qu’Android dispose d’un framework complet pour gérer ce genre d’événements, désignés sous le terme de notifications.

Types d’avertissements

Un service qui s’exécute en arrière-plan doit pouvoir attirer l’attention des utilisateurs lorsqu’un événement survient – la réception d’un courrier, par exemple. En outre, le service doit également diriger l’utilisateur vers une activité lui permettant d’agir en réponse à cet événement – lire le message reçu, par exemple. Pour ce type d’action,  Android fournit des icônes dans la barre d’état, des avertissements lumineux et d’autres indicateurs que l’on désigne globalement par le terme de notifications. Votre téléphone actuel peut posséder ce type d’icône pour indiquer le niveau de charge de la batterie, la force du signal, l’activation de Bluetooth, etc. Avec Android, les applications peuvent ajouter leurs propres icônes dans la barre d’état et faire en sorte qu’elles n’apparaissent que lorsque cela est nécessaire (lorsqu’un message est arrivé, par exemple). Vous pouvez lancer des notifications via le NotificationManager, qui est un service du système. Pour l’utiliser, vous devez obtenir l’objet service via un appel à la méthode getSystemService (NOTIFICATION_SERVICE) de votre activité. Le NotificationManager vous offre trois méthodes : une pour avertir (notify()) et deux pour arrêter d’avertir (cancel() et cancelAll()). La méthode notify() prend en paramètre une Notification, qui est une structure décrivant la forme que doit prendre l’avertissement. Les sections qui suivent décrivent tous les champs publics mis à votre disposition (mais souvenez-vous que tous les terminaux ne les supportent pas nécessairement tous).

Notifications matérielles

Vous pouvez faire clignoter les LED du terminal en mettant lights à true et en précisant leur couleur (sous la forme d’une valeur #ARGB dans ledARGB). Vous pouvez également préciser le type de clignotement (en indiquant les durées d’allumage et d’extinction en millisecondes dans ledOnMS et ledOffMS). Vous pouvez faire retentir un son en indiquant une Uri vers un contenu situé, par exemple, dans un ContentManager (sound). Considérez ce son comme une sonnerie pour votre application. Enfin, vous pouvez faire vibrer le terminal en indiquant les alternances de la vibration (vibrate) en millisecondes dans un tableau de valeurs long. Cette vibration peut être le comportement par défaut ou vous pouvez laisser le choix à l’utilisateur, au cas où il aurait besoin d’un avertissement plus discret qu’une sonnerie.