UWP est une plateforme issue de WinRT mais elle s’en éloigne car elle est cross-form-factors et que ses Apps universelles le sont vraiment : un seul code C#, un seul code XAML, un seul exécutable, pas de dépendances à .NET, et un seul OS. Forcément il y a des petites nuances pour réaliser un tel tour de force, mais on retrouve un cycle de vie proche d’un OS mobile…
Une même UX du smartphone au PC
Le modèle de cycle de vie des applications sous UWP est calqué sur celui mis en place dans les OS de smartphones : l’utilisateur n’a pas à gérer la fin d’exécution d’un programme. Ce qui était trop voyant sur PC avec Windows 8 et ses applications plein écran est aujourd’hui plus subtile avec Windows 10 mais les bases restent semblables.
Sur les OS pour smartphone l’intention est manifestement technique bien plus qu’ergonomique. En effet, la durée de vie des batteries, les simplifications nécessaires pour en faire des machines “grand public”, la faible mémoire installée, la puissance limitée des processeurs, etc, tous ces éléments ont forcé les concepteurs d’OS à imaginer un mécanisme permettant de donner l’illusion d’une fonctionnement fluide et multitâche là où en réalité il n’y a qu’une application d’avant-plan et nécessitée de supprimer de la mémoire certaines applications sans que cela ne gêne l’utilisateur. Ce dernier doit en effet pouvoir revenir à l’une des applications précédentes comme on passe d’une fenêtre à l’autre sur un PC : sans rupture (sans avoir l’impression que l’application vient d’être relancée en ayant perdu le contenu en cours au moment de son abandon).
Sous UWP qui se voue aussi bien aux PC qu’aux unités mobiles (tablettes, smartphones mais aussi XBox, IoT et Hololens) toutes ces motivations sont présentes. Toutefois sur PC Microsoft est revenu à la raisons avec Windows 10 qui rétablit un brai bureau et le multifenêtrage. Néanmoins ce changement cosmétique ne remet pas en cause les motivations techniques d’une gestion du cycle de vie des applications bien plus contrainte que sous les versions précédentes de Windows (de Windows 1 à 7).
En compensation à ces contraintes les développeurs peuvent tirer meilleur parti des machines en concevant une expérience utilisateur fluide qui n’affecte pas la durée de vie des batteries lorsque l’application passe en arrière-plan. Nuance sous Windows 10, minimiser une application ou en activer une autre n’a pas l’air de faire basculer les autres en mode suspendu. Certainement en raison de l’énergie et de la RAM dont un PC dispose. Il s’agit là d’une meilleure prise en charge d’un PC qui n’est donc pas qu’une grosse tablette comme certains ont voulu nous le faire croire un moment (et qui heureusement ont quitté Microsoft).
En utilisant les nouveaux évènements de cycle de vie, vos applications UWP donneront la sensation qu’elles sont toujours vivantes, même si elles ne fonctionnent réellement plus lorsqu’elles passent hors de l’écran sur un mobile ou lorsqu’elle sont arrêtées sur PC.
L’utilisateur, certainement habitué au bureau classique et à ses facilités quitte souvent une application en cours d’exécution pour faire autre chose, momentanément ou non. Sur un PC il sait qu’il retrouvera la fenêtre minimisée ou laissée en arrière-plan dans l’état où il l’a laissée. Il s’attend à ce que cela se passe de la même façon sur son smartphone ou sa tablette. Avec UWP comme il n’y a plus qu’une seule application qui peut tourner dans tous ces contextes il convient donc d’être attentif et de gérer convenablement ces situations différentes…
Quant aux nouveaux utilisateurs ou ados se fichant bien des contraintes techniques, il est évident que pour eux il est “naturel” de pouvoir revenir sur qu’on a abandonné sans avoir tout perdu du travail en cours. Ces utilisateurs là ne se posent aucune question sur cette gestion du cycle de vie des applications car elle est tout simplement ce à quoi ils s’attendent puisqu’ils n’ont de contact avec l’informatique que via les smartphones ou les tablettes la plupart du temps !
C’est ainsi que UWP depuis Windows 8 généralise sur PC un mode de gestion du cycle de vie des applications qui nous vient des unités mobiles à la fois parce que UWP fonctionne aussi sur les machines de ce type et que Microsoft a eu le courage d’innover en imposant une expérience utilisateur cohérente, fluide et transparente quel que ce soit le type d’ordinateur le faisant tourner.
Ainsi, le nouveau modèle de cycle de vie met l'accent sur les applications au premier plan pour assurer à l’utilisateur une expérience dynamique et immersive en exploitant au mieux la puissance de la machine qu’il utilise, quelle qu’elle soit.
En rupture totale avec le passé, Microsoft propose un OS qui consomme moins que les versions précédentes et qui sait s’adapter aussi bien à un Arduino lent avec peu de mémoire qu’à une bombe de bureau dotée d’un processeur 8 cœurs et de plusieurs Gigas de RAM...
Le nouveau cycle de vie des applications participe pleinement à ce nouvel objectif. Il est donc essentiel de le comprendre et de le maitriser. Je serai même tenté de comparer ce changement radical à celui que nous avons vécu lorsque Windows est passé du multitâche coopératif au multitâche préemptif. Toutefois UWP a été conçu avec tout ce qu’il faut pour gérer simplement ces nouvelles contraintes là où le passage du multitâche coopératif au préemptif fut plus douloureux pour certains développeurs...
Le cycle de vie d’une application UWP
Les choses sont simples, au départ au moins : une application UWP est à tout moment dans l’un des trois états suivants :
- not running (ne tournant pas)
- running (en cours d’exécution)
- suspended (suspendue)
L’état “terminé” n’est pas vraiment un état de l’application, un peu comme les états “joyeux”, “fatigué”, “énervé” sont des états possibles d’un être vivant mais que “mort” n’en est pas un, et pour cause, celui qui l’est n’est plus vivant par définition et n’en a pas conscience ni ne peut revenir tout seul à l’état “vivant” et connaitre de nouveau des états “joyeux”, “fatigué”, etc…
Comme durant toute sa “vie” une application ne fera que passer de l’un de ces états à un autre, il existe des transitions d’état matérialisées par des évènements qu’elle peut (et doit) gérer. La mort, l’état terminé ne donnant lieu à aucun signal ni évènement. Il vient quand le grand ordonnateur l’a décidé, sans prévenir ni laisser le temps de faire autre chose. On peut d'ailleurs assimiler "not running" à l'état "terminé", dans les faits c'est la même chose, philosophiquement cela se discute mais laissons la philo de côté :-)
Ce que j’appelle la “vie” d’une application est l’espace de temps de son existence sur une machine donnée, c’est à dire entre le moment où elle installée et celui où elle est désinstallée. Entre ces deux bornes, elle ne pourra être que de l’un des trois états listés ci-dessus (plus l’état “terminé” car le grand ordonnateur de UWP est très gentil et sait faire revenir les applications du pays des morts pour qu’elles connaissent encore d’autres cycles de vie). Donc de l’intérieur une application ne peut connaitre que 3 états, mais de l’extérieur on sait qu’elle peut être dans 4 (avec l’état “terminé” donc).
Le schéma ci-dessous montre ces quatre états ainsi que les quatre évènements de transition que l’application aura à gérer :
Toute application Windows 10 oscille entre ces 4 états au gré des actions de l’utilisateur qui passe d’une application à l’autre et de l’OS qui peut décider de mettre fin totalement à son activité comme de la rappeler à la vie.
Généralement une application passera son temps à basculer entre l’état “running” et “suspended” au moins sur unités mobiles. Il est donc indispensable de gérer les transitions correctement. Mais en fait l’état “suspendu” n’est pas éternel, au bout d’un moment, si l’OS a besoin de mémoire il fera passer sans autre forme de procès l’application en mode “terminé”. Mais comme je le disais aucun évènement n’est déclenché à ce moment. C’est donc bien “suspendu” l’état de la dernière chance…
On peut résumer tout cela par le tableau suivant :
Raison de l’arrêt | PreviousExecutionState | Action à exécuter |
Terminée par l’OS | Terminated | Restaurer la session |
Fermée par l’utilisateur | ClosedByUser | Démarrage normal |
Fin inopinée ou autre | NotRunning | Démarrage normal |
Le graphique suivant illustre la succession des états dans le temps :
On remarque que l’état suspendu correspond à l’arrêt total de l’activité CPU de l’application alors que sa mémoire n’est pas totalement vidée. On voit aussi intervenir en fin de graphique l’état “terminé” qui arrive après l’état suspendu et qui correspond à l’arrêt de l’activité CPU + vidage total de la mémoire.
La Suspension
En général une application UWP s’arrête de fonctionner quand l’utilisateur passe à une nouvelle application (ou retourne au menu principal). Sur PC et depuis Windows 10 le fait d’être toujours sur le bureau même dans un état minimisé laisse l’application en mode “running”. C’est là une grosse différence avec Windows 8 notamment (d’un autre côté le fenêtrage avait disparait de ce dernier, ce qui lui a couté la vie d’ailleurs).
Sur mobiles Windows 10 suspend toujours une application qui n’est plus en avant-plan (évènement “suspending”). Quand l’application est suspendue son état est figé en mémoire. Elle ne peut pas tourner dans cet état qui est une sorte de “parking à application”, leur mémoire subsiste mais leur moteur est arrêté. En revanche Windows 10 peut instantanément la sortir du “parking” et la réactiver lorsque l’utilisateur la fera passer à nouveau en avant-plan (évènement “resuming”).
La suspension d’une application garantit notamment qu’elle ne peut plus tirer sur la batterie ce qui est essentiel sur les unités mobiles et IoT, et que l’application d’avant-plan qui arrive à sa place bénéficiera de toutes les ressources disponibles pour en assurer sa fluidité.
L’astuce est simple, mais elle donne d’excellents résultats à tel point que tous les OS mobiles fonctionnent de la sorte sans que l’un ou l’autre ne fasse preuve d’originalité à ce niveau.
Le mécanisme réelle est malgré tout plus subtile. En fait quand une application perd l’avant-plan Windows 10 attend quelques secondes avant de la suspendre. Ce petit temps contribue lui aussi à assurer une meilleure fluidité de l’expérience utilisateur puisque si ce dernier revient rapidement sur l’application l’OS n’a pas eu à perdre de temps à la ranger puis à la ressortir du “parking” des applications suspendues. L’application elle-même n’ayant reçu aucun évènement particulier dans ce laps de temps n’a pas perdu de temps à enregistrer puis à relire son état.
Passé ce petit délai, Windows 10 va décider de suspendre l’application puisque l’utilisateur ne la reprend pas tout de suite. C’est à ce moment qu’elle va recevoir l’évènement suspending.
C’est un moment particulier pour l’application car elle doit utiliser cette (courte) opportunité pour sauvegarder son état sur un stockage permanent (disque, ssd, flash...). Très souvent l’application est “résumée” (réactivée) tel quel, c’est à dire depuis la mémoire de la machine et il n’y a alors rien de spécial à faire (son état n’a pas changé puisque son image mémoire est restée intacte). Toutefois il est nécessaire de sauvegarder l’état quand l’évènement “suspending” arrive car l’application ne pas savoir à l’avance si elle va rester en mémoire ou bien si l’OS va décider à un moment donné de la supprimer totalement de la RAM pour gagner de la place. Et là, lorsque “resuming” sera reçu par l’application ce sera après avoir été rechargée depuis le stockage et il lui faudra se remettre dans l’état dans lequel l’utilisateur l’a quitté sans que celui-ci ne se doute de quoi que ce soit.
C’est une partie du mécanisme qui donne l’impression à l’utilisateur que les applications sont toujours “vivantes” peu importe combien de temps il les a laissé en arrière-plan (et même si la machine a été éteinte entre temps !).
Windows 10 laisse 5 secondes à une application pour sauvegarder son état, un peu plus (entre 5 et 10) sur les mobiles. 5 secondes après avoir notifié l’application par l’évènement “suspending” Windows 10 la “terminera” (suppression de la mémoire). Par rapport à WinRT UWP apporte un petit changement, le temps donné aux applications est un peu plus long mais dès la suspension leur priorité CPU est revue à la baisse (donnant-donnant !).
C’est là que les choses se compliquent un peu. Comme le temps imparti à la sauvegarde de l’état est limité, comme certains machines peuvent être lentes, comme il peut y avoir beaucoup de choses à sauvegarder, on comprend vite que si on veut que cette phase reste déterministe l’application doit se débrouiller pour sauvegarder son état au fur et à mesure de son fonctionnement, sans toutefois trop consommer en invoquant sans cesse des entrées/sorties... Jeu d’équilibriste !
Typiquement la gestion de suspending ressemble à cela :
public App()
{
InitializeComponent();
this.Suspending += new OnSuspending;
}
async protected void OnSuspending(object sender, SuspendingEventArgs args)
{
// La suspension donne une chance à l'application de sauvegarder son état
// Comme l'écriture disque est asynchrone nous demandons un defferal
// qui s'assure que l'application ne sera pas terminée avant la fin
// d'écriture sur disque.
SuspendingDeferral deferral = args.SuspendingOperation.GetDeferral();
// Nous utilisons SuspensionManager qui gère les données de session
// dans un dictionnaire et le sérialise vers un fichier disque.
SuspensionManager.SessionState["CodeClient"] = currentCustomerID;
SuspensionManager.SessionState["Facture"] = currentInvoice;
SuspensionManager.SessionState["Solde"] = currentCustomer.Balance;
await SuspensionManager.SaveAsync();
// envoi d'une notification sur la tuile (optionnel)
Tile.SendTileUpdate(currentCustomer.Name, currentInvoice.ID, currentInvoice.Total);
deferral.Complete();
}
Dans cet exemple fictif nous voyons :
- La prise en charge de l’évènement Suspending
- Le gestionnaire d’évènement OnSuspending
- L’obtention d’un “deferral” pour bloquer en quelque sorte le processus le temps de sauvegarder l’état de l’application
- L’utilisation de SuspensionManager qui permet de gérer des données de session
- La sauvegarde asynchrone des données (avec await)
- La mise à jour de la tuile de l’application, ce qui est optionnel
- L’indication de fin de traitement en “relâchant” le “deferral”
Un “deferral” est un objet particulier permettant de demander à l’OS un sursis. La traduction française est d’ailleurs explicite pour une fois, puisque “deferral” se traduit par “ajournement” ou “report”.
- Le Resume (reprise)
Quand une application est “résumée” (horrible anglicisme puisqu’on peut traduire “resume” par “reprise” mais qui permet d’appuyer sur le sens techniquement particulier qu’on donne ici au terme) elle reprend l’avant-plan dans l’état où elle était au moment où Windows l’a suspendue.
Techniquement : les données et l’état de l’application sont gardées en mémoire pendant la suspension (le fameux “parking”), ainsi quand Windows 10 la reprend (resume) elle se trouve toujours dans le même état et il n’y a pas de nécessité de restaurer les données préalablement sauvegardées.
Néanmoins, comme vous voulez que votre application donne l’impression d’être “vivante”’ il sera peut-être nécessaire d’effectuer quelque rafraichissements. Par exemple si vous affichez des données provenant d’un service Web, d’une base de données distante, etc, et comme votre application peut rester longtemps en état suspendu, il sera certainement nécessaire de faire quelques requêtes pour afficher les données dans leur état actuel et non celui dans lequel elles étaient lors de la suspension...
Quand l’application sort du “parking des suspendues”, elle reçoit un évènement “resuming”, c’est dans le gestionnaire de ce dernier que vous effectuerez les mises à jours nécessaires.
Si nous reprenons l’exemple de code précédent (une gestion commerciale fictive, l’application affichant un client et une facture de ce dernier ainsi que le solde du compte client) nous comprenons que si le client ou sa facture ne risquent pas d’avoir changés il convient malgré tout :
- de vérifier que la facture est toujours dans le même état (par exemple toujours due ou réglée),
- que le compte client existe toujours (il peut avoir été supprimé),
- dans tous les cas il faudra interroger le solde du compte client qui a toutes les chances d’avoir bouger (nouvelles factures émises, nouveaux règlements reçus...).
Suivant cet exemple, le code d’une reprise sera le suivant :
public App(){
InitializeComponent();
this.Resuming += new EventHandler<object>(App_Resuming);
}
async private void App_Resuming(object sender, object e)
{
//mise à jour des données
currentInvoice = await IsInvoiceValid(currentInvoice.ID) ? currentInvoice : null;
currentCustomer =
await IsCustomerValid(currentCustomer.ID) ? currentCustomer : null;
currentCustomer.Balance = await GetCustomerBalance(currentCustomer.ID);
if (currentCustomer==null) customerSelection.Visible = true;
if (currentInvoice==null && currentCustomer!=null) invoiceSelection.Visible = true;
// notifications de la tuile
Tile.SendTileUpdate(currentCustomer==null?"":currentCustomer.Name,
currentInvoice==null?"":currentInvoice.ID,currentCustomer==null?
0d:currentCustomer.Balance);
}
Encore une fois, cet exemple est purement fictif, ce sont les mécanismes et leurs principes qui comptent, pas l’exactitude du code.
Plus de temps ?
L’utilisation du deferral fait partie du mécanisme normal de gestion de la suspension, sans demande d’un tel objet l’OS ne laissera aucun temps disponible pour la sauvegarde.
Mais que ce passe-t-il si dans un cas exceptionnel il y a besoin de plus de temps que 5 secondes ?
La première chose est certainement de revoir l’organisation de l’application pour faire en sorte comme je le disais déjà bien plus haut de sauvegarder en permanence des petits bouts d’information pour ne pas tout avoir à sauvegarder en une fois à la fin. Mais cela peut ne pas être applicable et même ne pas être suffisant.
Il existe dans Windows 10 un mécanisme de demande d’extension de temps qui s’ajoute à la demande de temps du deferral.
Pour cela on utilise un ExtendedExecutionSession, qu’on créé et manipule généralement dans un bloc using afin d’être certain de le relâcher quoi qu’il se passe.
Lorsqu’on fait une telle demande à l’OS on lui indique la raison qui peut par exemple être “sauvegarde de données, une description et un gestionnaire pour l’évènement de révocation. Puis on fait la sauvegarde et à la fin on relâche tout, extension de session et deferral.
L’Activation
Au départ les choses sont simples : l’activation de l’application n’est rien d’autre que le moment où elle lancée par Windows.
Mais nous sommes dans un environnement hautement collaboratif et intégré... De fait c’est au moment de l’activation qu’une application peut prendre connaissance du contexte de cette activation et celui-ci peut dépendre des contrats pris en charge ainsi que du mode “main view activation” ou “hosted view activation”. La différence est importante puisque dans un cas l’application sera appelée “pour elle-même” alors que dans l'autre elle sera invoquée à l’intérieur d’un process dont elle n’est pas l’acteur principal (par exemple si elle est choisie comme cible ou source d’un partage de données).
Le sujet méritant de plus amples explications j’y reviendrais dans un autre billet. Pour l’instant nous resterons concentrés sur le cycle de vie, considérant l’activation sous cet unique angle de vue.
Une application peut être terminée par Windows 10 à n’importe quel moment une fois qu’elle a été suspendue. De multiples raisons peuvent entrainer l’arrêt définitif d’une application : l’utilisateur la ferme volontairement, ou se délogue, ou bien l’OS a besoin de ressources et il doit libérer de la mémoire.
Si l’utilisateur lance l’application après qu’elle ait été “terminée” elle reçoit l’évènement d’activation et Windows affiche son Splash Screen le temps qu’elle se charge. Le Splash Screen est présent dans les assets du projet créé par défaut par Visual Studio, charge bien entendu au développeur (ou plutôt au designer) de le personnaliser. Mais c’est un mécanisme désormais intégré au fonctionnement “normal” d’un logiciel après 15 ou 20 ans d’existence sous la forme d’un ajout optionnel que chacun faisait à sa manière. Windows 10 normalise ainsi de nombreuses choses, et ce côté normatif fort est à la fois un avantage certain et une contrainte à bien gérer tant pour le designer que pour le développeur. D’ailleurs la grande bataille chez les Designers notamment dans le monde Android c’est de bannir le spash screen qui aurait tendance à démontrer le manque de réactivité des applications, ce qui n’est pas faux… En tout cas Windows 10 en gère un automatiquement.
L’évènement d’activation est un point d’entrée qui permet à l’application de savoir si elle doit ou non restaurer un contexte d’utilisation et d’exécuter le code de restauration dans l’affirmative.
Les arguments de l’évènement précise l’état précédent de l’application (que celle-ci ne peut pas deviner) notamment par la propriété PreviousExecutionState.
La valeur de cette propriété est l’une de celle prévue dans l’énumération Windows.ApplicationModel.Activation.ApplicationExecutionState.
C’est en partie grâce à cette valeur que l’application qui reçoit le signal d’activation peut décider si elle doit se charger avec son affichage par défaut ou bien si elle doit restaurer un état enregistré.
Le tableau ci-dessous résume les cas particuliers et les actions à entreprendre :
Raison de l’arrêt |
PreviousExecutionState |
Action à exécuter |
Terminée par l’OS |
Terminated |
Restaurer la session |
Fermée par l’utilisateur |
ClosedByUser |
Démarrage normal |
Fin inopinée ou autre |
NotRunning |
Démarrage normal |
En réalité comme on le voit, un seul cas réclame la restauration de la session de l’utilisateur : lorsque l’application a été terminée par Windows 10 après une suspension.
Si l’utilisateur a fermé l’application, ou bien si l’application a connu un arrêt inopiné (crash application ou système, ou bien si l’utilisateur n’a pas relancé l’application depuis que la session utilisateur a commencé), aucune restauration n’est nécessaire et l’application doit démarrer avec son affichage par défaut.
Il existe deux autres états possible pour PreviousExecutionState : Running et Suspended. Si ces derniers peuvent être pris en compte dans des cas particuliers ils n’impliquent en revanche pas la restauration de la session puisque l’application est encore “intacte” en mémoire.
Gérer l’activation se fait comme pour les exemples précédents, seul le code de restauration est intéressant et ce dernier varie en fonction des données qui sont sauvegardées. Nous nous passerons ainsi d’un exemple fictif de code ici.
Quelques conseils
Le décor a été posé et le mécanisme décrit. Mais reste à savoir deux ou trois petits choses bien utiles pour bien gérer le cycle de vie d’une application sous Windows 10.
Démarrer sans reprise de session
Parfois il est préférable de ne pas restaurer la session utilisateur. Par exemple cela fait très longtemps que l’utilisateur n’a pas lancé votre application, “longtemps” est ici relatif et dépend de l’application et de la temporalité de son contenu, à vous de voir combien de temps cela fait exactement. Mais dans un tel cas je vous conseille d’afficher l’écran de démarrage normal et non pas les vieilles données. Cela rendra votre application plus intelligente aux yeux de l’utilisateur.
Si nous imaginons une application qui affiche des news par exemple, et si l’utilisateur n’a pas utilisé l’application depuis “longtemps”, restaurer une news qui date donnera une impression négative, dans un tel cas mieux vaut ne rien afficher d’autre que l’écran de démarrage. Les exemples de ce type sont nombreux mais pas aussi évident que les news ou la météo, mais lorsqu’on écrit son application il faut y penser...
Sauvegarder les bonnes données au bon moment
Comme évoqué plus haut dans ce billet, l’évènement de suspension n’est pas un espace sans fin, Windows 10 vous donne du temps pour sauvegarder vos données mais passé un délai il “coupera le jus” à l’application et s’en sera terminé... Si l’application gère des données volumineuses ou longues à sauvegarder, il est préférable alors d’adopter une stratégie de sauvegarde incrémentale au fur et à mesure de l’utilisation.
Il y a deux types de données qu’une application peut manipuler : les données de session et les données utilisateurs.
Les premières sont celles qu’on sauvegarde de façon temporaire (voir les exemples de code dans le billet) pour se rappeler dans quel état est l’application (le numéro de la page d’un document qui était en cours d’affichage, le nom de ce document, le code d’un action boursière affichée, le nom de la page de l’application en cours d’affichage, etc, etc...).
Les secondes sont les données produites par l’utilisateur. Un texte en cours de rédaction, une photo, une capture vocale, un dessin... Ces données là doivent être accessible à l’utilisateur peut importe ce qu’il se passe. Elles ne sont pas sauvegardées dans les données de session mais dans l’espace dédié à l’application pour l’utilisateur en cours.
Il est donc important de bien faire la différence entre ces deux types de données et de les sauvegarder au bon moment et aux bons endroits !
Gestion des ressources externes
Si l’application a acquis des ressources externes comme un handle de fichier, une référence à un service, etc, elle doit absolument les libérer quand elle reçoit l’évènement Suspending. De la même façon, c’est quand elle est reprise (resume) qu’elle doit réclamer à nouveau ces ressources.
C’est un petit détail à ne pas oublier car il peut faire tout planter !
Ne fermez pas vos applications !
Aussi troublant que cela soit au début les applications Widows 10 ne doivent pas donner à l’utilisateur la possibilité d’être fermées. Cela était très stricte sous Windows 8 puis une petite croix de fermeture fit une apparition sous Windows 8.1 et avec le mode fenêtré de Windows 10 cet impératif devient faux, mais sur PC uniquement ! La première fois que j’ai lancé la première bêta de Windows 8 j’ai pesté un bon moment car je ne trouvais pas la petite croix ou un procédé similaire pour fermer les applications trouvant délirant d’être obligé de faire Alt-F4 pour mettre fin à chaque appli lancée... avant de comprendre que j’avais affaire à un OS de téléphone et non plus à Windows 7 . Le bureau de Windows 10 a l’avantage de ne pas frustrer à ce point les utilisateur d’anciennes versions ! Mais sur PC seulement. Dans tous les autres cas l’impératif reste valable : pas de fermeture d’application par l’application elle-même ni par l’utilisateur (sauf en utilisant les mécanismes offerts par l’OS).
Il faut bien comprendre, autant côté développeur qu’utilisateur, que Windows 10 gère le cycle de vie des applications lui-même et qu’il optimise la mémoire tout seul. Ni l’utilisateur ni le développeur ne doivent fermer une application dans l’espoir de gagner de la place. C’est à l’OS de se débrouiller. Le système de suspension est là pour garantir que l’UX reste excellente. Il ne faut pas tenter de lutter contre l’OS mais jouer la partie avec ce qu’il offre.
Conclusion
Avec trois évènements (Suspending, Resuming et Activated) une application Windows 10 / UWP dispose d’un mécanisme lui permettant de paraitre toujours vivante, toujours prête à fonctionner et sachant reprendre le fil de la dernière action en cours comme si elle avait toujours été en avant-plan... Ces évènements sont le reflet d’une gestion totalement nouvelle du cycle de vie des applications, en tout cas sur PC (si on omet la tentative Windows 8 qui est restée confidentielle), et garantissent, par les mécanismes sous-jacents, une utilisation fluide, dynamique et transparente des applications installées tout en préservant la puissance processeur et les ressources de la machine.
La cohérence de l’expérience utilisateur du smartphone au PC est un des avantages de Windows 10 sur l’ensemble de sa concurrence. La cohérence de son fonctionnement pour le développeur aussi.
Après un petit temps d’hésitation on finit par comprendre que ce choix est intelligent. C’est un peu la même démarche intellectuelle que celle que nous avons connu lorsque nous sommes passés de langages et d’environnement dans lesquels les destructeurs d’objet étaient essentiels à C# et son environnement managé qui prenaient en compte totalement la libération des objets. Beaucoup ont résisté, voire pesté contre cette avancée pour finir par l’adopter et la trouver totalement naturelle et normale aujourd’hui...
Il en sera pareil demain pour la gestion du cycle de vie des applications de Windows 10. On sent bien déjà que la surprise créée par Windows 8 malgré son adoption microscopique a marqué les esprit que retrouver dans un PC un mécanisme de smartphone n’a plus l’air de surprendre grand monde. Comme quoi…
Bon Dev, et n’oubliez pas de rester … suspendu à Dot.Blog …
Stay Tuned !