Dans ce blog, nous allons approfondir les callbacks du cycle de vie des activités en gardant à l’esprit les différents scénarios que l’utilisateur pourrait rencontrer.
Voici les scénarios les plus courants dans une application utilisateur :
- Activité unique : L’application est terminée et redémarrée
- Activité unique : L’utilisateur s’éloigne de l’activité
- Activité unique : La configuration change en raison de la rotation de l’appareil ou du mode multifenêtre
- Activité unique : L’application est mise en pause par le système
- Back stack : Navigation entre deux activités
- Back stack : Activités dans la pile arrière avec des changements de configuration
- Pile arrière : lorsque le processus de l’application est tué par le système
Maintenant, couvrons-les un par un.
Scénario 1 : Activité unique : L’application est terminée et redémarrée
Ce scénario est déclenché lorsqu’un utilisateur appuie sur le bouton retour ou lorsqu’une activité.finish() est appelée.
Voici le flux normal:
onCreate()
onStart()
onResume()
onPause()
onStop()
onDestroy()
Voici ce qui se passe lorsque l’utilisateur appuie sur le bouton retour:
onPause()
onStop()
onDestroy()
Maintenant, si nous redémarrons l’application, ce qui suit se produit :
- onSaveInstanceState() n’est pas appelé car l’activité est terminée et il n’y a pas besoin de sauvegarder l’état.
- onCreate() n’a pas de bundle, c’est-à-dire d’état sauvegardé, lorsque l’app est rouverte.
- L’activité étant terminée, il n’y a pas d’état à restaurer. Cela suit les rappels normaux du cycle de vie.
onCreate()
onStart()
onResume()
Scénario 2 : Activité unique : l’utilisateur s’éloigne de l’activité
Ce scénario est déclenché soit lorsque l’utilisateur appuie sur le bouton home, soit lorsqu’il passe à une autre application.
Comme nous le savons déjà, la séquence suivante de callbacks se produit au démarrage de l’application :
onCreate()
onStart()
onResume()
Maintenant, si l’utilisateur appuie sur le bouton Home, les callbacks suivants se produisent :
onPause()
onStop()
onSaveInstanceState()
Maintenant, si l’utilisateur navigue à nouveau vers l’application, celle-ci est redémarrée
onRestart()
onStart()
onResume()
Scénario 3 : Activité unique : changements de configuration
Ce scénario est déclenché lorsque des changements de configuration, comme une rotation, se produisent ou que l’utilisateur redimensionne la fenêtre en mode multifenêtre.
Lors de la rotation de l’appareil :
onPause()
onStop()
onSaveInstanceState()
onDestroy()
onCreate(paquet)
onStart
onRestoreInstanceState(paquet)
onResume
Lorsqu’un changement de configuration se produit en raison d’une rotation du dispositif ou d’un redimensionnement de la fenêtre, l’application doit permettre aux utilisateurs de reprendre exactement là où ils se sont arrêtés.
- L’activité est complètement détruite, mais l ‘état est sauvegardé et restauré pour la nouvelle instance.
- Le Bundle dans onCreate et onRestoreInstanceState est le même.
Scénario 4 : Activité unique : L’application est mise en pause par le système
Ce scénario est déclenché par les éléments suivants :
- Activation du mode multifenêtre (API 24+) et perte du focus https://developer.android.com/guide/topics/large-screens/multi-window-support
- Une autre application recouvre partiellement l’application en cours d’exécution (une boîte de dialogue d’achat, une boîte de dialogue d’autorisation d’exécution, une boîte de dialogue de connexion d’un tiers…)
- Un sélecteur d’intention apparaît, comme une boîte de dialogue de partage
Sur Multi window démarré
onPause()
Le focus revient sur l’App
onResume()
Veuillez noter : Ce scénario ne s’applique pas à :
- Dialogues dans la même application : L’affichage d’un AlertDialog ou d’un DialogFragment ne met pas en pause l’activité sous-jacente.
- Notifications : L’utilisateur qui reçoit une nouvelle notification ou qui tire la barre de notification vers le bas ne mettra pas en pause l’activité sous-jacente.
Scénario 5 : Back stack : Navigation entre deux activités
Supposons que nous ayons 2 activités : Activité A et Activité B
Lorsque l’utilisateur démarre une activité (Activité B) à partir de l’activité A, les callbacks suivants se produisent :
Dans ce scénario, lorsqu’une nouvelle activité est lancée, l’activité A est ARRÊTÉE (mais pas détruite), comme si l’utilisateur s’éloignait (comme s’il appuyait sur « Home »).
Lorsque l’utilisateur appuie sur le bouton « Retour », l’activité B est détruite et terminée.
Veuillez noter que :
- onSaveInstanceState() est appelé, mais onRestoreInstanceState() ne l’est pas. S’il y a un changement de configuration lorsque la deuxième activité est active, la première activité sera détruite et recréée uniquement lorsqu’elle sera de nouveau en focus.
- Si le système tue le processus de l’application pour économiser des ressources, c’est un autre scénario dans lequel l’état doit être restauré.
Scénario 6 : Pile arrière : Activités dans la pile arrière avec des changements de configuration
Dans l’activité A :
onCreate()
onStart()
onResume()
L’activité A lance maintenant l’activité B :
L’activité A est maintenant dans la pile arrière, l’activité B est au premier plan, maintenant la rotation du dispositif se produit, la séquence suivante de callbacks se produit dans l’activité B:
onPause()
onStop()
onSaveInstanceState()
onDestroy()
onCreate(paquet)
onStart()
onRestoreInstanceState()
onResume()
Lorsque l’utilisateur appuie sur le bouton de reprise de l’activité B:
Veuillez noter :
- Lasauvegarde de l’état n’est pas seulement importante pour l’activité au premier plan. Toutes les activités de la pile doivent restaurer l’état après un changement de configuration pour recréer leur interface utilisateur.
- Le système peut tuer le processus de votre application à presque tout moment. Nous devons donc être prêts à restaurer l’état dans n’importe quelle situation.
Scénario 7 : Pile arrière : lorsque le processus de l’application est tué par le système
Lorsque le système d’exploitation Android a besoin de ressources, il tue les applications en arrière-plan.
Dans l’activité A :
onCreate()
onStart()
onResume()
L’activité A lance maintenant l’activité B :
L’activité A est maintenant dans la pile arrière, l’activité B est au premier plan, l’utilisateur appuie maintenant sur le bouton home.
L’activité B qui est au premier plan a les callbacks suivants :
onPause()
onStop()
onSaveInstanceState()
À ce stade, supposons que l’OS tue l’application pour les ressources, l’utilisateur ouvre à nouveau l’application :
Activité B
onCreate(bundle)
onStart()
onRestoreInstanceState(paquet)
onResume()
Maintenant, supposons que l’utilisateur appuie sur le bouton de retour de l’activité B :
Veuillez noter
- L ‘état de la pile arrière complète est sauvegardé mais, afin d’utiliser efficacement les ressources, les activités ne sont restaurées que lorsqu’elles sont recréées.
C’est tout, les amis !
Merci de votre lecture. Dans le prochain article, nous couvrirons les bases du service dans le développement d’applications Android.
Restez à l’écoute.