Android, A Complete Course, From Basics to Enterprise Edition

Cycle de vie de l’activité

Android, A Complete Course, From Basics to Enterprise Edition. 1

Cycle de vie de l’activité. 1

Le cœur du système. 1

1.1         Gestion des évènements du cycle de vie d’une activité. 1

 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 :

http://android2ee.com.

La propriété intellectuelle du code appartient à :

Mathias Séguy

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 cœur du système

1.1       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 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.

1.1.1       Gérer ce qui ne se gère pas avec un Bundle.

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.