Android,
A Complete Course, From
Basics to Enterprise Edition
Android, A Complete Course, From Basics to Enterprise
Edition
1.1 Gestion des évènements du cycle de vie d’une activité
Cet
article est extraie du livre « Android, A Complete Course »,
disponible sur Android2ee.com.
Les
exemples ou les programmes présents dans cet ouvrage sont fournis pour
illustrer les descriptions théoriques. Ce code est libre de toute utilisation
mais n'est pas distribuable.
La
distribution du code est reservée au site :
La
propriété intellectuelle du code appartient à :
L’utilisation
de ces codes est sous votre unique responsabilité et personne d’autre que vous
ne pourra être tenu responsable des préjudices ou dommages de quelques natures
que ce soit pouvant résulter de son utilisation.
Tous
les noms de produits ou marques cités dans cet ouvrage sont des marques déposés
par leurs propriétaires respectifs.
Publié par http://android2ee.com
Titre Original : Android, A Complete Course, From
Basics to Enterprise Edition. Édition Française.
ISBN : 979-10-90388-00-0
Copyright © 2011 by Mathias Séguy
Aucune
représentation ou reproduction, même partielle, autre que celles prévues à
l’article L. 122-5 2° et 3° a) du code de la propriété intellectuelle ne peut
être faite sans l’autorisation expresse de Mathias Seguy ou, le cas échéant,
sans le respect des modalités prévues à l’article L. 122-10 dudit code
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 4 états :
· Active. L’activité est lancée par l’utilisateur, 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é à é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’états :
Ainsi les différentes méthodes sont :
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 à ces états (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é 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 une 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.
Typiquement, une connexion, un ensemble de thread filles, les sockets ouvertes… 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.