Les différents états d’une application Windows Phone 7

Autrement dit, elle apparaît sur l’écran Start et/ou dans la liste d’applications. A ce stade, elle ne figure pas dans la pile de retours en arrière car elle n’a pas encore été employée. Dès que l’utilisateur lance l’application, l’événement Launching est généré sur l’objet Application.

Par défaut, un gestionnaire pour cet événement et d’autres événements Application est disponible dans le fichier App.xaml.cs. L’application passe alors à l’état Running. Dans certains cas, une partie de l’écran peut être obscurcie, par exemple lors d’un avertissement de niveau de batterie insuffisant. Si cela se produit, un événement Obscured est généré et l’application place en pause tout ce qui requiert une interaction de l’utilisateur. A l’inverse, l’événement Unobscured est généré lorsque l’écran est entièrement visible, de sorte que l’application est de nouveau utilisable.

A partir de l’état Running, si l’utilisateur effleure le bouton Start, par exemple comme s’il allait lancer une autre application, un événement Deactivated et généré sur l’objet Application et l’application passe à l’état Eligible for Termination. Dans cet état, elle est effectivement en pause, mais reste chargée en mémoire. A ce stade, si l’utilisateur change d’avis et clique sur le bouton Back, l’application s’exécute de nouveau et l’événement Activated est généré sur l’objet Application.

Une alternative consiste, pour l’utilisateur, à effleurer le bouton Start, puis à sélectionner une autre application à ouvrir. Dans ce scénario, l’application passe à l’état Eligible for Termination (action sur le bouton Start) et à l’état de fermeture. Notez qu’il vous est impossible d’intercepter cette transition pour annuler l’opération ou pour faire persister l’état. Cela permet de garantir que tout état est persistant dès la fin de l’événement Deactivated et que l’état repasse au mode d’exécution après l’événement Activated.

Lorsqu’une application se termine de la sorte, elle passe en fait dans un état de restauration du dernier état (tombstoning). Imaginons que votre application soit enterrée avec l’inscription de son état courant, y compris la pile de retours en arrière au moment de sa fin de vie. Si l’utilisateur décide de revenir à l’application en appuyant sur le bouton Back, elle sera ressuscitée. Ce processus inclut le lancement de l’application, la génération de l’événement Activated sur l’objet Application et l’accès directement à la page qui se trouvait en haut de la pile.

Notez qu’indépendamment du chemin employé pour revenir à l’état Running, l’événement Activated est généré. Toutefois, il existe deux scénarios non couverts par ce diagramme. Dans le premier, l’application est dans l’état Eligible for Termination ou Tombstoned, et l’utilisateur clique de nouveau sur l’application à partir de l’écran Start ou de la liste d’applications. Dans ce cas, l’application est retirée de la pile de retours en arrière, toutes les informations d’état sont supprimées et l’application revient à l’état Not Running. A partir de là, l’application sera lancée comme à l’accoutumée, ce qui générera l’événement Launching.

Le deuxième scénario concerne la longueur de la pile de retours en arrière inter-applications. Seules cinq applications peuvent être présentes dans la pile. Lorsque l’utilisateur ouvre la sixième, la première application est supprimée de la pile et revient à l’état Not Running.