I. Gestion des événements du cycle de vie d'une activité▲
Le système, pour des raisons de priorisation d'activités (coup de téléphone), peut tuer une activité quand il a besoin de ressources. Pour cette raison, aucune activité ne peut penser pouvoir vivre jusqu'au bout de son traitement, elle doit être considérée comme un humain. Elle peut avoir un accident, être à l'hôpital et/ou mourir.
Une activité possède quatre états que sont :
- « Active » : l'activité est lancée par l'utilisateur, elle s'exécute au premier plan ;
- « En Pause » : l'activité est lancée par l'utilisateur, elle s'exécute et est visible, mais elle n'est plus au premier plan. Une notification ou une autre activité lui a volé le focus et une partie du premier plan ;
- « Stoppée » : l'activité a été lancée par l'utilisateur, mais n'est plus au premier plan et est invisible. L'activité ne peut interagir avec l'utilisateur qu'avec une notification ;
- « Morte » : l'activité n'est pas lancée.
Le schéma suivant indique le cycle de vie d'une activité et les méthodes appelées lors des changements d'état :
Ainsi, les différentes méthodes sont présentées ci-dessous.
La méthode onCreate est appelée :
- au premier lancement de l'activité ;
- si l'activité est ressuscitée, le bundle passé en paramètre sera celui sauvegardé par onSaveInstanceState() ;
- si l'état du terminal change et que l'activité est associée à cet état (passage du mode portrait au mode paysage).
Elle configure les IHM et tous les traitements d'initialisation qui ne sont effectués qu'une seule fois au lancement de l'activité.
La méthode onDestroy est appelée lors de la mort de l'activité (soit naturelle, soit par le système). Parfois, l'urgence du système détruira l'activité sans même appeler onDestroy. Cette méthode doit libérer les ressources allouées dans la méthode onCreate. La seule méthode qui est appelée avec certitude avant la destruction de l'activité est onPause().
Les méthodes onStart, onRestart et onStop n'ont pas grand intérêt.
Les méthodes onPause et onResume sont celles dans lesquelles l'activité doit sauvegarder ses états et les restituer.
La méthode onResume est appelée immédiatement avant que l'activité ne passe au premier plan. De ce fait, c'est le bon endroit pour reconstruire les données affichées par l'IHM et mettre celle-ci à jour, quitte à lancer un thread de reconstruction des données.
Inversement, la méthode onPause est la seule par laquelle il est certain que l'application passera avant de se faire détruire. Il convient donc de sauvegarder l'état de l'application dans cette méthode.
La sauvegarde et la restauration s'effectuent au travers des méthodes onSaveInstance et onRestoreInstance. L'objet Bundle est passé en paramètre de l'une et renvoyé par l'autre. L'objet Bundle est une carte (map) intelligente qui stocke des paires typées (Key, Object) et possède l'ensemble des méthodes pour enregistrer et récupérer ces paires (putBoolean(String key, boolean value) et boolean getBoolean(String key) par exemple et ce pour la plupart des types connus).
Toute la subtilité du mécanisme réside dans le choix fait par le développeur des données à sauvegarder. Il ne doit pas vouloir y mettre la terre entière et être précis dans ce qu'il choisit de stocker et de restaurer.
II. Gérer ce qui ne se gère pas avec un Bundle▲
Typiquement, une connexion, un ensemble de thread filles, les sockets ouverts… comment les sauvegarder et les restaurer quand l'activité passe en pause ?
Pour cela, il faut utiliser les méthodes onRetainNonConfigurationInstance pour leur sauvegarde et getLastNonConfigurationInstance pour la restauration. Ces méthodes sont à utiliser en plus des méthodes onSaveInstanceState et onRestoreInstance. La seule restriction est que ces méthodes ne peuvent faire référence à une ressource détruite lors du passage de pause à resume.
Ces méthodes sont très utiles lors de la rotation qui, rappelons-le, détruit et reconstruit l'application.
III. Remerciements▲
Nous remercions milkoseck pour sa relecture orthographique et Mickael Baron pour la mise au format Developpez.com.