Blog de Steven Hanquez

Cycle de vie d’une application Metro Style

Nous avons déjà détaillé, au travers de plusieurs billets, les modifications apportées sur le plan visuel par les applications Metro Styles. Aujourd’hui, nous allons nous intéresser à la façon dont les applications sont lancées et exécutées sous Windows 8, autrement dit, à leur cycle de vie. Comme vous allez le voir, beaucoup de choses ont changé !

La capture d’écran ci-dessus montre clairement l’un des premiers changements importants. Sous Windows 7 (et antérieurs), c’est l’utilisateur qui manage lui-même la durée de vie d’une application. Ce dernier peut lancer 1 ou plusieurs applications en même temps et a également la liberté de fermer les applications de son choix, mettant par la même occasion fin à leur processus.

Sous Windows 8, les choses sont différentes. C’est désormais le système qui manage la durée de vie des applications. Quand une application est lancée pour la première fois (on appelle cette étape l’activation), celle-ci rejoint les applications en mémoire et y demeure. Si l’application est au premier plan, elle est dite « active ». A l’inverse, toutes les applications en arrière plan sont considérées comme « suspendues ». Par défaut, l’utilisateur n’a pas la possibilité de fermer complètement une application lancée (sauf en passant par le Gestionnaire de Tâches pour forcer la fermeture). Le passage d’une application en mode Actif ou Suspendu est donc géré par le système. L’utilisateur choisi simplement l’application qui apparait au premier plan.

On distingue donc 3 états dans la durée de vie d’une application : Running, Suspended et Terminated. Une application au premier plan est en exécution (Running) et est mise en pause (suspending) dés son passage en arrière plan. En réalité, ce passage se fait après un court délai (quelques secondes). Elle passe alors en mode « suspended ». Si l’application passe de nouveau au premier plan, elle repasse en exécution automatiquement (resuming). Ce passage se fait lui instantanément afin d’assurer une fluidité dans les actions de l’utilisateur. Enfin, dans certains cas précis, tel qu’un manque de mémoire, le système peut décider de terminer certaines applications suspendues. Cela intervient également en cas de plantage d’une application, de fermeture de Windows ou de changement d’utilisateur.

Il est bon de préciser que les applications en suspens n’ont aucun impact sur la durée de vie de la batterie. Entendez par là que ces applications ne consomment aucune ressource au niveau du processeur mais subsistent uniquement en mémoire.

Voyons encore un peu plus en détails le processus de transition des différents états de vie d’une application. Comme on peut le constater sur le schéma ci-dessous, les applications mises en suspens le sont en réalité au bout de 5 secondes. Le but étant de permettre aux développeurs de lancer du code sur l’évènement (OnSuspend) afin, par exemple, de sauvegarder l’état de l’application. La sauvegarde est utile car si l’application venait à être terminée (à cause d’un manque de mémoire), celle-ci ne serait pas avertie. Autrement dit, il est impossible d’exécuter du code au moment de la fermeture totale d’une application. Il faut donc anticiper cette possibilité !

Une application en suspens qui redevient active (resuming) est par contre notifiée de cet évènement (OnResume).

Remarquons qu’il est donc impossible de lancer plusieurs instances d’une même application. Si l’application est déjà en suspens, la sélectionner depuis le bureau ne fera que la remettre au premier plan.

Résumons l’état suspendu en quelques points :

• La suspension d’une application n’est pas planifiée. Cela intervient seulement si l’application passe en arrière plan.
• Une application suspendue n’utilise pas le CPU, les disques ou les différentes connectivités (web, …).
• L’application demeure simplement en mémoire, ce qui explique son impact nul sur la batterie de l’appareil.
• Tous les threads sont suspendus.
• Le kernel s’assure que la suspension d’une application n’intervient pas à un moment critique pouvant causer des plantages.
• Le passage de l’état suspendu à l’état actif se fait instantanément.

Différentes manières de lancer une application
Sous Windows 7, le lancement d’une application se faisait la plupart du temps en sélectionnant le raccourci présent sur le bureau ou dans le menu démarrer.

Sous Windows 8, l’activation d’une application peut se faire depuis les tuiles (qui remplacent les icones du bureau) mais peut également intervenir depuis les menus de recherche ou encore de partage (voir schéma ci-dessous).

Comme nous l’avions déjà évoqué dans le billet (« Comment faire une bonne application Metro »), les applications Metro Style peuvent utiliser des Contrats afin de se lier au système et / ou avec d’autres applications. On trouve par exemple un contrat « Search » et un contrat « Share ». Pour plus de détails, je vous invite à lire le billet susmentionné, ou encore d’attendre un prochain article qui détaillera en pratique comment implémenter ces fameux contrats. Mais revenons au cycle de vie de nos applications.

En lançant une application depuis un contrat, des informations seront transmises afin de conserver le contexte. Prenons l’exemple d’une application qui permet de gérer sa médiathèque (qu’on appellera sobrement « Médiathèque »). L’utilisateur y stocke les films en sa possession en précisant, entre autre, leur nom. On pourrait trouver utile d’implémenter le contrat « Search » dans cette application. Ainsi, en utilisant le menu recherche de Windows 8, l’utilisateur se verrait automatiquement proposer de lancer sa recherche dans le contexte de l’application « Médiathèque ».

Dans l’application Médiathèque, il est donc primordial de prendre cela en compte afin de récupérer, dans ce cas précis, la saisie initiale de l’utilisateur pour lancer la recherche dans la Médiathèque.

Une application peut donc se lancer de différentes manières, surtout si celle-ci implémente un ou plusieurs contrats.

Utilisation du Splash Screen
En lançant une application pour la première fois (activation), celle-ci doit inévitablement se charger et effectuer quelques traitements. Pendant ce temps, un Splash Screen est affiché sur l’écran de l’utilisateur. A la fin du chargement, le Splash Screen disparait pour laisser place à la vue principale de l’application. Toutes ces étapes sont parfaitement expliquées dans le schéma ci-dessous :

C’est le système qui s’occupe automatiquement d’afficher ce Splash Screen. Le développeur peut très simplement choisir la couleur et l’image à afficher sur cet écran d’attente. Signalons que le Splash Screen ne peut pas être affiché plus de 15 secondes. Au delà de ce délai, si votre application n’est toujours pas chargée et visible à l’écran, le système la terminera automatiquement.

Si votre application nécessite un chargement de plus de 15 secondes à son activation, vous devez mettre en place un Splash Screen « Etendu ». En fait, il s’agit d’une astuce consistant à utiliser la première vue de l’application comme un Splash Screen. Ainsi, pour le système l’application est bien en exécution alors que pour l’utilisateur, le chargement est toujours visible.

Signalons à ce titre que l’API Splash Screen est disponible.

Le schéma ci-dessus résume clairement le processus d’activation d’une application.

Les bonnes pratiques à avoir
Bonnes pratiques de conservation et de restauration du contexte :

• Une application en exécution doit enregistrer de manière incrémentale les données utilisateur.
• Quand l’application passe en arrière plan (Suspending), il faut sauvegarder l’état de l’application à ce moment précis (par exemple, l’écran sur lequel se trouve l’utilisateur, la dernière page lue d’un livre, le dernier niveau terminé d’un jeu, …). Le fait d’avoir sauvegardé les données utilisateur tout au long de l’exécution de l’application permet de gagner du temps lors de la mise en suspens. Vous devez partir du principe que l’application peut être terminée et avoir en mémoire que vous ne serez pas notifié de cet événement. C’est donc votre dernière chance d’enregistrer l’état de l’application !
• Quand une application « En suspens » est activée, vous n’avez rien à faire. En effet, l’application est restée en mémoire tout ce temps.
• Quand une application est activée pour la première fois, il faut restaurer les données utilisateurs qui ont été précédemment sauvegardées. L’utilisateur doit avoir l’impression de n’avoir jamais quitté l’application.

Bonnes pratiques lors de l’activation d’une application :

• Il faut activer une application rapidement. Ce qui n’est pas utile peut être fait en différé.
• L’activation permet d’initialiser l’application et éventuellement de restaurer les données utilisateurs.
• Si le chargement dure plus de 15 secondes, il faut utiliser un Splash Screen « Etendu ».

Bonnes pratiques lors de la suspension d’une application :

• La sauvegarde des données doit être rapide, moins de 5 sec. En effet, c’est le temps que laisse le système à l’application avant de passer réellement à l’état suspendu.
• Sauvegarder les données de manière incrémentale avant que l’application ne soit mise en suspens.
• Avoir à l’esprit qu’une application en suspens peut être terminée sans notification.
• Mettez à jour la tuile de l’application.

En résumé
Le cycle de vie des applications Metro Style est managé par le système et non plus par l’utilisateur. Une fois activée, une application demeure en mémoire sauf si le système décide de la terminer (manque de mémoire, …). Ce changement nécessite quelques modifications au niveau de la conception des applications afin, par exemple, de prendre en compte la gestion de la sauvegarde et de la restauration des données utilisateurs.

Ce billet, qui est dédié au cycle de vie des applications Metro Style, fait volontairement l’impasse sur les Tuiles et les notifications. En effet, il y a beaucoup de choses à dire sur le sujet et un article dédié sera publié très prochainement sur mon blog.