Propriété de Albiri Sigue
customer 27921 at Fri Mar 11 19:19:45 +0100 2011
Chapitre 30
Création d’un service 305
La méthode onDestroy() est bien plus simple :
@Override
public void onDestroy() {
super.onDestroy();
singleton=null;
myLocationManager.removeUpdates(onLocationChange);
}
On se contente ici de stopper la surveillance des déplacements, après avoir appelé la
méthode onDestroy() de la superclasse pour qu’Android puisse effectuer les travaux de
nettoyage nécessaires.
Outre ces méthodes du cycle de vie, votre service doit également implémenter la méthode
onBind(), qui renvoie un IBinder, la composante fondamentale du mécanisme d’IPC.
Pour les services locaux – ce qui nous intéresse dans ce chapitre –, il suffit que cette
méthode renvoie null.
Il ne peut en rester qu’un !
Par défaut, les services s’exécutent dans le même processus que tous les autres composants de l’application – les activités, par exemple. On peut donc appeler les méthodes de
l’API sur l’objet service... à condition de mettre la main dessus. Dans l’idéal, il devrait
exister un moyen de demander à Android de nous donner l’objet du service local ; malheureusement, ce moyen n’existe pas encore et nous en sommes donc réduits à tricher.
Il ne peut y avoir, au plus, qu’une seule copie d’un même service qui s’exécute en
mémoire. Il peut n’y en avoir aucune si le service n’a pas été lancé mais, même si
plusieurs activités tentent d’utiliser le service, un seul s’exécutera vraiment. Il s’agit donc
d’une implémentation du patron de conception singleton – il suffit donc que l’on expose le
singleton lui-même pour que les autres composants puissent accéder à l’objet.
Dans le cas de WeatherPlusService, nous utilisons un membre statique public, singleton, pour stocker ce singleton (nous pourrions évidemment rendre ce membre privé et
fournir une méthode d’accès). Dans onCreate(), nous initialisons singleton avec l’objet
lui-même, tandis que, dans onDestroy(), nous le réinitialisons à null. Cette dernière
étape est très importante. Les données statiques sont dangereuses car elles peuvent provoquer des fuites mémoire : si nous oublions de remettre singleton à null dans onDestroy(), l’objet WeatherPlusService restera indéfiniment en mémoire, bien qu’il soit
déconnecté du reste d’Android. Assurez-vous de toujours réinitialiser à null les références
statiques de vos services !
Comme nous le verrons au chapitre suivant, les activités peuvent désormais accéder aux
méthodes publiques de votre objet service grâce à ce singleton.
Livre Android.book Page 305 Dimanche, 8. novembre 2009 12:23 12
customer 27921 at Fri Mar 11 19:19:45 +0100 2011
Chapitre 30
Création d’un service 305
La méthode onDestroy() est bien plus simple :
@Override
public void onDestroy() {
super.onDestroy();
singleton=null;
myLocationManager.removeUpdates(onLocationChange);
}
On se contente ici de stopper la surveillance des déplacements, après avoir appelé la
méthode onDestroy() de la superclasse pour qu’Android puisse effectuer les travaux de
nettoyage nécessaires.
Outre ces méthodes du cycle de vie, votre service doit également implémenter la méthode
onBind(), qui renvoie un IBinder, la composante fondamentale du mécanisme d’IPC.
Pour les services locaux – ce qui nous intéresse dans ce chapitre –, il suffit que cette
méthode renvoie null.
Il ne peut en rester qu’un !
Par défaut, les services s’exécutent dans le même processus que tous les autres composants de l’application – les activités, par exemple. On peut donc appeler les méthodes de
l’API sur l’objet service... à condition de mettre la main dessus. Dans l’idéal, il devrait
exister un moyen de demander à Android de nous donner l’objet du service local ; malheureusement, ce moyen n’existe pas encore et nous en sommes donc réduits à tricher.
Il ne peut y avoir, au plus, qu’une seule copie d’un même service qui s’exécute en
mémoire. Il peut n’y en avoir aucune si le service n’a pas été lancé mais, même si
plusieurs activités tentent d’utiliser le service, un seul s’exécutera vraiment. Il s’agit donc
d’une implémentation du patron de conception singleton – il suffit donc que l’on expose le
singleton lui-même pour que les autres composants puissent accéder à l’objet.
Dans le cas de WeatherPlusService, nous utilisons un membre statique public, singleton, pour stocker ce singleton (nous pourrions évidemment rendre ce membre privé et
fournir une méthode d’accès). Dans onCreate(), nous initialisons singleton avec l’objet
lui-même, tandis que, dans onDestroy(), nous le réinitialisons à null. Cette dernière
étape est très importante. Les données statiques sont dangereuses car elles peuvent provoquer des fuites mémoire : si nous oublions de remettre singleton à null dans onDestroy(), l’objet WeatherPlusService restera indéfiniment en mémoire, bien qu’il soit
déconnecté du reste d’Android. Assurez-vous de toujours réinitialiser à null les références
statiques de vos services !
Comme nous le verrons au chapitre suivant, les activités peuvent désormais accéder aux
méthodes publiques de votre objet service grâce à ce singleton.
Livre Android.book Page 305 Dimanche, 8. novembre 2009 12:23 12