Cycle de vie de l’application

Cycle de vie de l’application

[ Cet article est destiné aux développeurs de Windows 8.x et Windows Phone 8.x qui créent des applications Windows Runtime. Si vous développez une application pour Windows 10, voir la Documentation ]

Cette rubrique décrit le cycle de vie d’une application Windows Runtime, de l’instant où elle est déployée jusqu’à sa suppression. En lançant, en suspendant et en reprenant correctement votre application, vous assurez à votre client une expérience optimale avec celle-ci.

É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 décrivent ces états et événements. Pour plus d’informations sur chaque transition d’état et quelle doit être la réponse de votre application, voir la documentation relative à l’énumération ApplicationExecutionState.

Diagramme d’état illustrant les transitions entre les états d’exécution de l’application

Déploiement

Pour activer une application, elle doit tout d’abord être déployée. Le déploiement de base est pris en charge quand un utilisateur installe votre application ou lorsque vous utilisez Visual Studio pour générer et exécuter votre application localement lors du développement et du test. Pour plus d’informations sur le déploiement de base et sur les scénarios de déploiement avancé, voir Packages et déploiement d’application.

Lancement d’une application

Une application est lancée chaque fois qu’elle est activée par l’utilisateur et que l’état précédent du processus d’application est NotRunning. Une application peut être en l’état NotRunning parce qu’elle n’a jamais été lancée, parce qu’elle était en cours d’exécution avant d’être bloquée ou parce qu’elle a été suspendue, mais n’a pas pu être conservée en mémoire et a été arrêtée par le système.

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. (HTML ou XAML).

Lorsque l’écran de démarrage est affiché, le code de votre application doit s’assurer que l’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 l’interface utilisateur personnalisée dont elle a besoin pour le chargement de la page initiale. 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 Comment étendre l’écran de démarrage (HTML ou XAML) et Exemple d’écran de démarrage. Une fois que l’application a terminé l’activation, elle passe en l’état Running et l’écran de démarrage disparaît (toutes les ressources et tous les objets sont effacés). 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 Comment activer une application.(HTML ou XAML).

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 WinJS activated (HTML) ou remplacer la méthode OnActivated (XAML). (Pour HTML, WebUIApplication.activated est un autre événement que vous pouvez gérer pour l’activation.)

Le code d’activation de votre application peut réaliser un test pour déterminer la raison de son activation et si elle se trouvait déjà dans l’état Running. Les applications peuvent être activées à l’aide de n’importe lequel de ces types d’activation :

Type d’activation Description
fichier mis en cacheL’utilisateur souhaite enregistrer un fichier dont votre application gère le contenu.
appareil photoL’utilisateur souhaite capturer des photos ou une vidéo à partir d’un appareil photo raccordé.
sélecteur de contactsL’utilisateur souhaite sélectionner des contacts.
périphériqueL’utilisateur souhaite que votre application gère la lecture automatique.
fichierL’application d’un utilisateur a lancé un fichier dont le type est géré par votre application.
sélecteur de fichiers ouvertsL’utilisateur souhaite sélectionner des fichiers ou dossiers fournis par votre application.
sélecteur de fichiers enregistrésL’utilisateur souhaite enregistrer un fichier et a sélectionné votre application.
lancementL’utilisateur a lancé votre application ou appuyé sur une vignette de contenu.
tâche d’impressionL’utilisateur souhaite que votre application gère les tâches d’impression.
protocoleL’application d’un utilisateur a lancé une URL dont le protocole est géré par votre application.
rechercheL’utilisateur souhaite effectuer une recherche avec votre application.
cible de partageL’utilisateur souhaite que votre application soit la cible d’une opération de partage.

 

Les applications conçues pour Windows 8.1 et versions ultérieures peuvent être activées par l’une des conditions ci-dessus ou avec ces types d’activation.

Type d’activation Description
ajouter un rendez-vousL’utilisateur veut ajouter un rendez-vous à son calendrier. Aussi pris en charge sur Windows Phone.
supprimer un rendez-vousL’utilisateur veut supprimer un rendez-vous de son calendrier. Aussi pris en charge sur Windows Phone.
remplacer un rendez-vousL’utilisateur veut remplacer un rendez-vous de son calendrier. Aussi pris en charge sur Windows Phone.
afficher un délai d’exécutionL’utilisateur veut afficher un délai d’exécution spécifique sur son calendrier. Aussi pris en charge sur Windows Phone.
appel d’un contactL’utilisateur veut appeler un contact.
localiser un contact sur une carteL’utilisateur veut localiser un contact (sur une carte).
message à un contactL’utilisateur veut envoyer un message à un contact.
validation de contactL’utilisateur veut valider un contact.
conversation vidéo avec un contactL’utilisateur veut effectuer une conversation vidéo avec un contact.
appel à partir de l’écran de verrouillageL’utilisateur veut accepter un appel à partir de l’écran de verrouillage.
lancement restreintL’utilisateur a lancé votre application restreinte.

 

Les applications Windows Phone peuvent être activées avec ces types.

Type d’activation Description
VoiceCommand L’application a été activée à l’issue d’une commande vocale.
PickerReturned L’application a été activée à l’issue de l’utilisation d’un sélecteur.
WalletAction L’application a été activée pour effectuer une opération Portefeuille.
PickFileContinuation L’application a été activée après la suspension de l’application pour une opération de sélection de fichier.
PickSaveFileContinuation L’application a été activée après la suspension de l’application pour une opération de sélection d’enregistrement de fichier.
PickFolderContinuation L’application a été activée après la suspension de l’application pour une opération de sélection de dossier.
WebAuthenticationBrokerContinuation L’application a été activée après la suspension de l’application pour une opération du service Broker d’authentification Web.

 

Votre application peut utiliser l’activation pour restaurer des données précédemment enregistrées au cas où le système d’exploitation 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, l’application reçoit un événement activated ou un rappel Application.OnActivated (XAML) et l’écran de démarrage de votre application reste affiché 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. Lorsque l’écran de démarrage est affiché, le code de votre application peut consacrer du temps de traitement à effectuer cette opération sans retard apparent pour l’utilisateur. Les problèmes mentionnés précédemment concernant les opérations à long terme s’appliquent également lorsque vous redémarrez ou que vous poursuivez l’utilisation. Les données de l’événementactivated/OnActivated 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.

Raison de l’arrêtValeur 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é par l’utilisateur ou processus interrompu par l’utilisateurClosedByUser 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 utilisateur activeNotRunningDémarrer avec les données par défaut

 

Remarque  La session utilisateur active est basé sur l’ouverture de session Windows. Tant que l’utilisateur actuel ne s’est pas déconnecté ou n’a pas arrêté la session de manière explicite, ou que Windows n’a pas redémarré pour une autre raison, la session utilisateur active persiste à travers les événements, tels que l’authentification de l’écran de verrouillage, le changement d’utilisateur, etc.
 

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.

Remarque  

Si vous ouvrez une session en utilisant le compte Administrateur de l’ordinateur, vous ne pouvez activer aucune application Windows Runtime.

Pour plus d’informations, voir Extensions d’application.

Comparaison entre OnActivated et des activations spécifiques dans une application XAML

Pour le modèle d’activation XAML et la classe Application, la méthode OnActivated permet de gérer tous les types d’activation possibles. Toutefois, il est plus courant d’utiliser différentes méthodes pour gérer les types d’activation les plus courants et d’utiliser OnActivated uniquement comme méthode de secours pour les types d’activation moins courants. Par exemple, Application a une méthode OnLaunched qui est appelée sous forme de rappel chaque fois que ActivationKind est Launch. Il s’agit de l’activation standard pour la plupart des applications. Il existe plus de 6 méthodes On* pour les activations spécifiques : OnCachedFileUpdaterActivated, OnFileActivated, OnFileOpenPickerActivated, OnFileSavePickerActivated, OnSearchActivated, OnShareTargetActivated. Les modèles de départ pour une application XAML ont une implémentation pour OnLaunched et un gestionnaire pour Suspending, incorporant tous les deux des méthodes issues de la classe SuspensionManager prédéfinie dans chaque modèle. La description de ce que SuspensionManager fait sort du cadre de cette rubrique. Pour plus d’informations, voir Modèles de projet C#, VB et C++ pour les applications.

Suspension d’une application

La suspension d’une application intervient quand l’utilisateur la quitte ou quand l’appareil entre dans un état de faible alimentation. La plupart des applications sont suspendues 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 ne revient pas dans l’application dans ce laps de temps, Windows la suspend.

Si une application a inscrit un gestionnaire d’événements à l’événement WinJS checkpoint (pour HTML) ou à l’événement Application.Suspending (pour XAML), ce code est immédiatement appelé avant la suspension de l’application. Vous pouvez utiliser le gestionnaire d’événements pour enregistrer des données utilisateur et d’application pertinentes. 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 Accès aux données de l’application à l’aide de Windows Runtime. 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 lors de la gestion de l’événement interrompu. L’exécution du code ne doit pas prendre plus d’une seconde. Si une application ne réagit pas à l’événement interrompu dans un délai de 5 secondes sous Windows et dans un délai compris entre 1 et 10 secondes sous Windows Phone, 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. Cela 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. 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 les fonctions qui étaient les siennes à ce moment-là.

Certaines applications doivent continuer de s’exécuter pour effectuer des tâches en arrière-plan. Par exemple, votre application peut continuer de lire du contenu audio en arrière-plan. Pour plus d’informations, voir Comment lire du contenu audio en arrière-plan (HTML ou XAML). 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 Comment télécharger un fichier (HTML ou XAML).

Pour obtenir des recommandations, voir Recommandations pour la suspension et la reprise d’une application.

Pour un exemple de code, voir Comment suspendre une application (HTML ou XAML).

Visibilité de l’application

Lorsque l’utilisateur passe de votre application à une autre, votre application n’est plus visible, mais demeure en l’état Running jusqu’à ce que Windows la suspende. Si l’utilisateur quitte votre application, mais l’active ou y revient avant qu’elle ne puisse être suspendue, l’application reste en l’état Running.

Votre application ne reçoit pas d’événement d’activation quand 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 faire quelque chose quand l’utilisateur la quitte et y revient, elle peut gérer l’événement visibilitychange (pour HTML) ou l’événement Window.VisibilityChanged (pour XAML).

L’événement de visibilité n’est pas sérialisé avec les événements d’interruption/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 le périphérique 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 n’est perdue du moment qu’elles ont été stocké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 WebUIApplication.resuming (HTML) ou l’événement Application.Resuming (XAML), ce gestionnaire d’événements est appelé lorsque l’application quitte l’état Suspended. Vous pouvez actualiser le contenu et les données de votre application à l’aide de ce gestionnaire d’événements.

Remarque  

En général, les applications HTML n’ont pas besoin de gérer resuming de façon plus spécifique, car activated est déclenché dans les mêmes circonstances. Vous pouvez utiliser les informations ActivationKind à partir des données d’événement activated pour déterminer si l’application est relancée. Ce modèle est indiqué dans le fichier default.js de modèles de projet de démarrage.

 

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, puis l’événement 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 un exemple de code, voir Comment relancer une application (HTML ou XAML).

Remarque  Dans les applications du Windows Phone Store, pour une application XAML, OnLaunched est appelée chaque fois que l’utilisateur lance l’application à partir de la vignette d’accueil ou de la liste des applications, même si l’application est actuellement suspendue en mémoire. Sous Windows, le lancement d’une application suspendue à partir de la vignette d’accueil ou de la liste d’applications n’appelle pas cette méthode.

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 (sur Windows) ou en utilisant le sélecteur de tâche (sur Windows Phone). 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, puis entre en l’état NotRunning.

Sous Windows 8.1 et versions ultérieures, une fois qu’une application a été fermée par l’utilisateur, elle est supprimée de l’écran et de la liste de répartition sans être arrêtée de manière explicite.

Remarque  Si votre application dépend du comportement de fermeture par l’utilisateur propre à Windows 8, vous pouvez activer ce comportement dans votre application quand vous la mettez à niveau vers Windows 8.1. Pour activer le comportement de fermeture par l’utilisateur propre à Windows 8, configurez votre application Windows 8.1 pour qu’elle s’arrête quand la dernière fenêtre est fermée à l’aide de la propriété ApplicationView.TerminateAppOnFinalViewClose.

Si un gestionnaire d’événements pour l’événement 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.

Comportement fermé par l’utilisateur:  Nous vous recommandons de 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, vous pouvez utiliser le gestionnaire d’événements d’activation pour déterminer si l’application a été arrêtée par l’utilisateur ou par Windows. Voir les descriptions des états ClosedByUser et Terminated dans la documentation relative à l’énumération ApplicationExecutionState. Si vous gérez une application Windows 8, la gestion de ClosedByUser est potentiellement différente de celle pour une application Windows 8.1.

Nous recommandons que les applications ne puissent se fermer par programme qu’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, le système 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é du tableau de bord.

Lorsque l’utilisateur active une application après une panne, son gestionnaire d’événements d’activation reçoit une valeur ApplicationExecutionState de NotRunning et doit afficher son interface utilisateur et ses données d’origine. Après une panne, n’utilisez pas de manière automatique les données d’application utilisées pour Resuming avec Suspended, car ces données peuvent être endommagées. Consultez Recommandations en matière d’interruption et de reprise d’une application.

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 stockées dans des emplacements communs, tels que les fichiers contenus dans Documents ou dans les bibliothèques d’images.

Cycle de vie de l’application et modèles de projet Visual Studio

Pour les applications HTML ou XAML, le code de base pertinent pour le cycle de vie est fourni dans les modèles de projet de démarrage Visual Studio. L’application de base gère l’activation de lancement et affiche son interface utilisateur principale avant même que vous ayez ajouté votre propre code. Pour plus d’informations, voir Modèles de projet JavaScript pour les applications du Windows Store ou Modèles de projet en C#, VB et C++ pour les applications.

API de clé du cycle de vie de l’application

Rubriques associées

Recommandations pour la suspension et la reprise d’une application
Exemple d’activation, de reprise et de suspension d’une application

 

 

Afficher:
© 2017 Microsoft