Propriété de Albiri Sigue
customer 27921 at Fri Mar 11 19:19:45 +0100 2011
Chapitre 31
Appel d’un service 311
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 Page 311 Dimanche, 8. novembre 2009 12:23 12
customer 27921 at Fri Mar 11 19:19:45 +0100 2011
Chapitre 31
Appel d’un service 311
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 Page 311 Dimanche, 8. novembre 2009 12:23 12