Cycle de vie d’une application (applications du Windows Store)
Découvrez le cycle de vie d’une application du Windows Store, depuis son déploiement jusqu’à sa suppression. En utilisant Windows pour suspendre et reprendre correctement votre application, vous assurez à votre client une expérience optimale avec celle-ci.
Déploiement d’application
Les utilisateurs achètent votre application sur le Windows Store sous forme de package d’application. Les packages d’application ont l’extension de fichier .appx. Chaque package contient un manifeste et les fichiers qui constituent l’application. En plus de décrire l’application, le manifeste du package est utilisé par Windows lors de l’installation et la suppression de l’application.
Le manifeste du package peut également spécifier si l’application requiert un accès par programme aux ressources protégées ou aux périphériques connectés. Vos clients peuvent avoir l’assurance que votre application ne peut pas accéder à ces ressources système ni aux fichiers de leurs bibliothèques, à moins qu’ils n’approuvent cet accès. Voir Déclarations des fonctionnalités d’application.
Pour plus d’informations, voir Packages et déploiement d’applications.
État d’exécution de l’application
Cette illustration représente les transitions entre les états d’exécution de l’application. Les sections suivantes de cette page décrivent ces états et événements. Pour plus d’informations sur le moment où chaque transition se produit et quelle doit être la réponse de votre application, voir la documentation relative à l’énumération ApplicationExecutionState.
Lancement d’une application
Le lancement d’une application intervient chaque fois qu’elle est activée par l’utilisateur, mais que le processus est dans l’état NotRunning, car elle vient d’être déployée, elle s’est bloquée ou elle a été suspendue sans pouvoir être gardée en mémoire.
Lors du lancement d’une application, Windows affiche un écran de démarrage pour l’application. Pour configurer cet écran de démarrage, voir Ajout d’un écran de démarrage.
Pendant que son écran de démarrage est affiché, une application doit s’assurer que son interface utilisateur est prête à être affichée à l’utilisateur. Les tâches principales pour l’application consistent à inscrire des gestionnaires d’événements et à configurer une interface utilisateur personnalisée dont elle a besoin pour le chargement. Ces tâches ne doivent prendre que quelques secondes. Si une application doit demander des données au réseau ou récupérer de grandes quantités de données à partir du disque, ces activités doivent être effectuées hors activation. Une application peut utiliser sa propre interface utilisateur de chargement personnalisée ou un écran de démarrage étendu pendant qu’elle attend la fin de ces longues opérations. Pour plus d’informations, voir la documentation sur l’écran de démarrage étendu et l’exemple d’écran de démarrage. Une fois que l’application a terminé l’activation, elle entre dans l’état Running et l’écran de démarrage disparaît. Affichage d’une fenêtre, retour du gestionnaire d’activation et réalisation d’un report : tels sont les procédés spécifiques qu’utilise une application pour mener à bien une activation. Pour plus d’informations, voir :
Activation d’une application
Une application peut être activée par l’utilisateur via différents contrats et extensions. Pour participer à l’activation, votre application doit s’inscrire pour recevoir l’événement Activated | activated. Le gestionnaire d’événements d’activation de votre application peut réaliser un test pour déterminer la raison de son activation et s’il se trouvait déjà dans l’état Running. Les applications peuvent être activées comme suit.
| Type d’activation | Description |
|---|---|
| fichier mis en cache | L’utilisateur souhaite enregistrer un fichier dont votre application gère le contenu. |
| appareil photo | L’utilisateur souhaite capturer des photos ou une vidéo à partir d’un appareil photo raccordé. |
| sélecteur de contacts | L’utilisateur souhaite sélectionner des contacts. |
| périphérique | L’utilisateur souhaite que votre application gère la lecture automatique. |
| fichier | L’application d’un utilisateur a lancé un fichier dont le type est géré par votre application. |
| sélecteur de fichiers ouverts | L’utilisateur souhaite sélectionner des fichiers ou dossiers fournis par votre application. |
| sélecteur de fichiers enregistrés | L’utilisateur souhaite enregistrer un fichier et a sélectionné votre application. |
| lancement | L’utilisateur a lancé votre application ou appuyé sur une vignette de contenu. |
| tâche d’impression | L’utilisateur souhaite que votre application gère les tâches d’impression. |
| protocole | L’application d’un utilisateur a lancé une URL dont le protocole est géré par votre application. |
| recherche | L’utilisateur souhaite effectuer une recherche avec votre application. |
| cible de partage | L’utilisateur souhaite que votre application soit la cible d’une opération de partage. |
Votre application peut utiliser l’activation pour restaurer des données précédemment enregistrées au cas où Windows mettrait fin à votre application et l’utilisateur la relancerait par la suite. Windows peut arrêter votre application une fois qu’elle a été suspendue pour différentes raisons. L’utilisateur peut fermer manuellement votre application ou se déconnecter, ou le système peut être sur le point de manquer de ressources. Si l’utilisateur lance votre application après que Windows l’a arrêtée, il reçoit un événement activated et voit l’écran de démarrage de votre application jusqu’à ce que celle-ci soit activée. Vous pouvez utiliser cet événement pour déterminer si votre application doit restaurer les données qu’elle avait enregistrées lors de sa dernière suspension ou si vous devez charger les données par défaut de votre application. Les arguments de l’événement activated incluent une propriété PreviousExecutionState qui vous indique l’état dans lequel se trouvait votre application avant d’être activée. Cette propriété est l’une des valeurs de l’énumération ApplicationExecutionState. Le tableau ci-dessous récapitule les possibilités :
| Raison de l’arrêt | Valeur de la propriété PreviousExecutionState | Action à entreprendre |
|---|---|---|
| Terminé par le système (par exemple, en raison de contraintes liées aux ressources) | Terminated | Restaurer les données de session |
| Fermée par l’utilisateur | ClosedByUser | Démarrer avec les données par défaut |
| Arrêtée de manière inattendue, ou l’application n’a pas été exécutée depuis le démarrage de la session de l’utilisateur | NotRunning | Démarrer avec les données par défaut |
PreviousExecutionState peut aussi présenter la valeur Running ou Suspended mais, dans ces cas, votre application n’a pas été auparavant arrêtée et vous n’avez donc pas à vous soucier de la restauration des données.
À noter que si vous ouvrez une session en utilisant le compte Administrateur de l’ordinateur, vous ne pouvez activer aucune application du Windows Store.
Pour plus d’informations, voir Extensions d’application.
Suspension d’une application
La suspension d’une application intervient lorsque l’utilisateur la quitte ou lorsque Windows entre dans un état de faible alimentation. La plupart des applications cessent de s’exécuter lorsque l’utilisateur les quitte.
Lorsque l’utilisateur met une application en arrière-plan, Windows patiente quelques secondes, le temps de voir si l’utilisateur retourne immédiatement dans l’application. Si l’utilisateur n’y retourne pas, Windows la suspend.
Si un gestionnaire d’événements pour l’événement Suspending | suspending a été inscrit par une application, il est appelé juste avant la suspension de l’application. Vous pouvez utiliser le gestionnaire d’événements pour enregistrer des données utilisateur et d’application pertinentes sur un périphérique de stockage persistant. Pour cela, nous vous recommandons d’utiliser les API de données d’application, car elles terminent l’opération avant que l’application n’entre dans l’état Suspended. Pour plus d’informations, voir Données d’application. Vous devez également libérer les ressources exclusives et les descripteurs de fichiers afin de permettre aux autres applications d’y accéder pendant que votre application ne les utilise pas.
En règle générale, votre application doit immédiatement enregistrer son état ainsi que libérer ses ressources exclusives et descripteurs de fichiers dans le gestionnaire d’événements lorsque l’événement de suspension est reçu. Ces opérations prennent généralement une seconde. Si une application ne réagit pas à l’événement de suspension dans un délai de 5 secondes, Windows considère qu’elle a cessé de répondre et l’arrête.
Windows essaie de garder un maximum d’applications suspendues en mémoire. Windows permet ainsi aux utilisateurs de basculer de façon rapide et fiable entre les applications suspendues. Toutefois, si les ressources pour conserver votre application en mémoire sont insuffisantes, Windows peut arrêter votre application. Notez que les applications ne sont pas notifiées de leur arrêt. De ce fait, vous ne pouvez enregistrer les données de votre application qu’au cours de la suspension. Lorsqu’une application détermine qu’elle est activée après avoir été arrêtée, elle doit charger les données d’application enregistrées lors de la suspension pour retrouver l’état qui était le sien à ce moment-là.
Certaines applications doivent continuer de s’exécuter pour effectuer des tâches en arrière-plan. Votre application peut continuer de lire du contenu audio en arrière-plan ; pour plus d’informations, voir Démarrage rapide : ajout de son dans une application du Windows Store. Les opérations de transfert en arrière-plan continuent même si votre application est suspendue, voire arrêtée ; pour plus d’informations, voir Démarrage rapide : téléchargement d’un fichier.
Pour obtenir des recommandations, voir Recommandations pour la suspension et la reprise d’une application.
Pour obtenir un exemple de code, voir :
Visibilité de l’application
Lorsque l’utilisateur passe de votre application à une autre, votre application n’est plus visible, mais demeure à l’état d’exécution jusqu’à ce que Windows puisse la suspendre (pendant environ 10 secondes). Si l’utilisateur quitte votre application, mais l’active ou y revient avant que Windows ne puisse la suspendre, l’application reste à l’état d’exécution.
Votre application ne reçoit pas d’événement d’activation lorsque la visibilité change, car elle est toujours en cours d’exécution. Windows quitte l’application et y revient simplement autant de fois que nécessaire. Si votre application doit effectuer une opération lorsque l’utilisateur la quitte et y revient, elle peut gérer l’événement VisibilityChanged | msvisibilitychange.
L’événement de visibilité n’est pas sérialisé avec les événements de reprise ou d’activation. Ne partez pas du principe que ces événements se produisent dans un ordre particulier.
Reprise d’une application
Une application suspendue est reprise lorsque l’utilisateur bascule vers elle ou que Windows quitte un état de faible alimentation.
Pour obtenir une énumération des états possibles pour votre application lors de sa reprise, voir ApplicationExecutionState. Lorsqu’une application quitte l’état Suspended, elle entre dans l’état Running et reprend là où elle s’est arrêtée. Aucune donnée d’application n’est perdue, car les données sont conservées en mémoire, Par conséquent, la plupart des applications n’ont aucune opération à effectuer lors de leur reprise. Toutefois, l’application peut avoir été suspendue pendant des heures, voire des jours. Dans ce cas, si votre application présente du contenu ou des connexions réseau caduques, il convient de les actualiser lors de la reprise. Si une application a inscrit un gestionnaire d’événements pour l’événement Resuming | resuming, ce gestionnaire d’événements est appelé lorsque l’application quitte l’état Suspended. Vous pouvez actualiser votre contenu à l’aide de ce gestionnaire d’événements.
Si une application suspendue est activée pour participer à un contrat ou une extension d’application, elle reçoit d’abord l’événement Resuming | resuming, puis l’événement Activated | activated.
Lorsqu’une application est suspendue, elle ne reçoit pas les événements réseau auxquels elle est inscrite. Ces événements ne sont pas mis en file d’attente ; ils sont simplement manqués. Par conséquent, votre application doit tester l’état du réseau lors de sa reprise.
Pour obtenir des recommandations, voir Recommandations pour la suspension et la reprise d’une application.
Pour obtenir un exemple de code, voir :
Fermeture d’une application
Généralement, les utilisateurs n’ont pas besoin de fermer les applications et peuvent laisser Windows les gérer. Toutefois, ils peuvent décider de fermer une application en effectuant un mouvement de fermeture ou en appuyant sur Alt+F4. Vous ne pouvez pas inclure d’interface utilisateur dans votre application pour permettre à l’utilisateur de la fermer, ou elle ne réussira pas le processus de certification du Windows Store.
Il n’existe aucun événement spécial pour indiquer que l’utilisateur a fermé une application. Une fois qu’une application a été fermée par l’utilisateur, elle est suspendue et arrêtée, et entre dans l’état NotRunning dans un délai de 10 secondes environ. Si un gestionnaire d’événements pour l’événement Suspending | suspending a été inscrit par une application, il est appelé lors de la suspension de l’application. Vous pouvez utiliser ce gestionnaire d’événements pour enregistrer des données utilisateur et d’application pertinentes sur un périphérique de stockage persistant.
Vous devez décider de la façon dont votre application doit se comporter lorsqu’elle est activée après avoir été fermée par l’utilisateur. Il peut ne pas vous importer que l’application soit arrêtée par Windows ou par l’utilisateur. Si votre application doit se comporter différemment selon qu’elle est fermée par l’utilisateur ou par Windows, le gestionnaire d’événements d’activation peut déterminer si l’application a été arrêtée par Windows ou par l’utilisateur. Voir les descriptions des états ClosedByUser et Terminated dans la documentation relative à l’énumération ApplicationExecutionState.
Les applications ne doivent pas se fermer par programme, sauf en cas d’absolue nécessité. Par exemple, si une application détecte une fuite de mémoire, elle peut se fermer pour assurer la sécurité des données personnelles de l’utilisateur. Lorsque vous fermez une application par programme, Windows considère qu’il s’agit d’un blocage d’application.
Blocage d’application
Les applications sont tenues de suivre la procédure en cas de panne du système, qui consiste à retourner simplement à l’écran d’accueil. La procédure en cas de panne du système étant conçue pour permettre aux utilisateurs de poursuivre leurs tâches aussi rapidement que possible, vous ne devez pas présenter de boîte de dialogue d’avertissement ni d’autre notification pour ne pas retarder l’utilisateur. La disparition de l’application doit indiquer clairement à l’utilisateur qu’un problème est survenu.
Si votre application se bloque, cesse de répondre ou génère une exception, Windows demande à l’utilisateur la permission d’envoyer un rapport de problèmes à Microsoft. Microsoft vous fournit un sous-ensemble des données d’erreur dans le rapport de problèmes pour que vous puissiez les utiliser afin d’améliorer votre application. Vous pouvez consulter ces données dans la page Qualité de votre application dans votre tableau de bord dans le Centre de développement Windows pour les applications du Windows Store. (Notez que vous ne pouvez pas envoyer des applications ni afficher les données de votre application tant que le Windows Store n’est pas ouvert aux propositions d’ordre général.)
Lorsque l’utilisateur active une application après une panne, son gestionnaire d’événements d’activation reçoit une valeur NotRunning d’énumération ApplicationExecutionState et doit simplement afficher son interface utilisateur et ses données d’origine.
Suppression d’une application
Lorsqu’un utilisateur supprime votre application, elle est supprimée avec toutes ses données locales. La suppression d’une application n’affecte pas les données de l’utilisateur, telles que les fichiers contenus dans Documents ou les bibliothèques d’images.
Interfaces de programmation du cycle de vie des applications
- Espace de noms Windows.ApplicationModel
- Espace de noms Windows.ApplicationModel.Activation
- Espace de noms Windows.ApplicationModel.Core
- Espace de noms Windows.UI.WebUI
- Classe Windows.UI.Xaml.Application
- Classe Windows.UI.Xaml.Window
- Espace de noms WinJS.Application
Rubriques associées
- Recommandations pour la suspension et la reprise d’une application
- Exemples
- Exemple d’activation, d’interruption et de reprise d’une application à l’aide de WRL
