Changement d'état d'une activité

Différents événements, certains déclenchés par l'utilisateur et d'autres par le système, peuvent entraîner la transition d'un Activity d'un état à un autre. Ce document décrit certains cas courants dans lesquels de telles transitions se produisent et explique comment les gérer.

Pour en savoir plus sur les états d'activité, consultez Cycle de vie d'une activité. Pour en savoir plus sur la manière dont la classe ViewModel peut vous aider à gérer le cycle de vie de l'activité, consultez la présentation de ViewModel.

La configuration est modifiée

Plusieurs événements peuvent déclencher une modification de la configuration. L'exemple le plus marquant est sans doute un changement entre les orientations portrait et paysage. Les modifications des paramètres de langue ou du périphérique d'entrée peuvent également entraîner des changements de configuration.

En cas de modification de la configuration, l'activité est détruite et recréée. Cela déclenche les rappels suivants dans l'instance d'activité d'origine:

  1. onPause()
  2. onStop()
  3. onDestroy()

Une instance de l'activité est créée, et les rappels suivants sont déclenchés:

  1. onCreate()
  2. onStart()
  3. onResume()

Utilisez une combinaison d'instances ViewModel, de la méthode onSaveInstanceState() ou d'un espace de stockage local persistant pour conserver l'état de l'interface utilisateur d'une activité en cas de modification de la configuration. Le choix de la combinaison de ces options dépend de la complexité des données de l'interface utilisateur, des cas d'utilisation de votre application, ainsi que de la vitesse de récupération par rapport à l'utilisation de la mémoire. Pour en savoir plus sur l'enregistrement de l'état de l'interface utilisateur de votre activité, consultez Enregistrer les états de l'interface utilisateur.

Gérer les coques multifenêtres

Lorsqu'une application passe en mode multifenêtre, disponible sur Android 7.0 (niveau d'API 24) ou version ultérieure, le système avertit l'activité en cours d'une modification de configuration, en effectuant ainsi les transitions de cycle de vie décrites précédemment.

Ce comportement se produit également si une application déjà en mode multifenêtre est redimensionnée. Votre activité peut gérer elle-même la modification de configuration ou permettre au système de détruire l'activité et de la recréer avec les nouvelles dimensions.

Pour en savoir plus sur le cycle de vie multifenêtre, consultez la description du cycle de vie multifenêtre sur la page Compatibilité avec le mode multifenêtre.

En mode multifenêtre, bien que deux applications soient visibles par l'utilisateur, seule celle avec laquelle il interagit se trouve au premier plan et est ciblée. Cette activité est réactivée, tandis que l'application de l'autre fenêtre est mise en pause.

Lorsque l'utilisateur passe de l'application A à l'application B, le système appelle onPause() sur l'application A et onResume() sur l'application B. Elle passe d'une méthode à l'autre chaque fois que l'utilisateur passe d'une application à une autre.

Pour en savoir plus sur le mode multifenêtre, consultez la section Compatibilité avec le mode multifenêtre.

L'activité ou la boîte de dialogue s'affiche au premier plan

Si une nouvelle activité ou boîte de dialogue apparaît au premier plan, la sélection s'ouvrant et recouvrant partiellement l'activité en cours, l'activité couverte perd son focus et passe à l'état "Mise en pause". Le système appelle ensuite onPause() sur celui-ci.

Lorsque l'activité couverte revient au premier plan et repasse au premier plan, le système appelle onResume().

Si une nouvelle activité ou boîte de dialogue apparaît au premier plan et recouvre entièrement l'activité en cours, l'activité couverte perd son focus et passe à l'état "Arrêtée". Le système appelle ensuite rapidement onPause() et onStop().

Lorsque la même instance de l'activité couverte revient au premier plan, le système appelle onRestart(), onStart() et onResume() sur l'activité. S'il s'agit d'une nouvelle instance de l'activité couverte qui passe en arrière-plan, le système n'appelle pas onRestart(), mais seulement onStart() et onResume().

L'utilisateur appuie sur le bouton ou fait un geste pour revenir en arrière.

Si une activité est exécutée au premier plan et que l'utilisateur appuie ou fait revenir en arrière, l'activité passe par les rappels onPause(), onStop() et onDestroy(). L'activité est détruite et supprimée de la pile "Retour".

Par défaut, le rappel onSaveInstanceState() ne se déclenche pas dans ce cas. Ce comportement suppose que l'utilisateur appuie sur "Retour" sans s'attendre à revenir à la même instance de l'activité.

Toutefois, vous pouvez ignorer la méthode onBackPressed() pour implémenter un comportement personnalisé, par exemple afficher une boîte de dialogue demandant à l'utilisateur de confirmer qu'il souhaite quitter votre application.

Si vous forcez la méthode onBackPressed(), nous vous recommandons vivement d'appeler toujours super.onBackPressed() à partir de votre méthode remplacée. Sinon, le comportement "Retour" du système risque de perturber l'utilisateur.

Le système arrête le processus de l'application.

Si une application est exécutée en arrière-plan et que le système doit libérer de la mémoire pour une application au premier plan, le système peut fermer l'application en arrière-plan. Lorsque le système ferme une application, il n'y a aucune garantie que onDestroy() soit appelé dans l'application.

Pour en savoir plus sur la manière dont le système décide des processus à détruire, consultez État de l'activité et éjection de la mémoire et Processus et cycle de vie de l'application.

Pour savoir comment enregistrer l'état d'interface utilisateur de votre activité lorsque le système arrête le processus de votre application, consultez Enregistrer et restaurer l'état temporaire de l'interface utilisateur.