Comment définir les options de connectivité en arrière-plan (HTML)

Article
12/11/2015

[ 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 les fonctionnalités de connectivité réseau en arrière-plan disponibles pour une application Windows Runtime écrite en JavaScript et HTML et comment configurer les options de connectivité en arrière-plan.

Ce que vous devez savoir

Technologies

IXMLHTTPRequest2

Permet l’accès aux ressources Web à l’aide d’une extension de l’objet XMLHttpRequest.
System.Net.Http

Permet la connexion aux services Web à l’aide d’un client Web moderne.

Prérequis

Les informations suivantes concernent les applications Windows Runtime connectées ou réseau qui dépendent de connexions réseau devant être connectées en permanence. Cette rubrique concerne les applications écrites en JavaScript et HTML pour Windows 8.1, Windows Phone 8.1 et Windows Server 2012 R2. Pour plus d’informations sur les tâches en arrière-plan relatives aux applications JavaScript, voir Définition de tâches en arrière-plan pour les besoins de votre application.

Pour plus d’informations sur les applications du Windows Store connectées ou réseau écrites en C++/XAML et les applications utilisant .NET Framework 4.5 en C#, VB.NET ou C++ managé dans Windows 8.1 et Windows Server 2012 R2, voir Comment rester connecté en arrière-plan.

Modèle de cycle de vie pour les applications du Windows Store

Windows 8 et versions ultérieures offrent un nouveau modèle de cycle de vie pour les applications Windows Runtime qui diffère du modèle utilisé pour les applications de bureau Windows 8 et les applications sous les versions antérieures de Windows. Par défaut, le fonctionnement d’une application Windows Runtime est entièrement interrompu lorsqu’elle passe en arrière-plan. Il existe toutefois quelques exceptions à l’interruption d’une application (impression active, accès à un flux audio ou transfert de fichiers en arrière-plan via Windows.Networking.BackgroundTransfer, par exemple). Pour certaines de ces exceptions (Windows.Networking.BackgroundTransfer, par exemple), l’application peut toujours être suspendue, mais Windows continue le transfert réseau dans un processus distinct.

Ce nouveau modèle destiné aux applications Windows Runtime améliore la réactivité de l’application exécutée au premier plan tout en réduisant l’énergie globale consommée par le système. Cela permet d’économiser la batterie du système, qui fonctionne alors plus longtemps sans rechargement. En outre, ce nouveau modèle intègre un mécanisme grâce auquel l’utilisateur final bénéficie d’une expérience de connexion permanente au niveau des applications devant s’exécuter en arrière-plan (telles que les applications de voix sur IP (VoIP), messagerie instantanée et messagerie électronique). Ainsi, une application dépendant d’une connexion réseau longue durée à un serveur distant peut continuer à fonctionner en état de suspension. La connexion permanente requise par une application en temps réel entre en concurrence avec une réduction de la consommation d’énergie et un accroissement de la réactivité des applications.

Plusieurs nouvelles fonctionnalités introduites dans Windows 8 autorisent des scénarios de mise en réseau en temps réel pour les applications Windows Runtime écrites en JavaScript et nécessitant une connexion permanente :

Tâches en arrière-plan
Déclencheur système pour SessionConnected
Minuteurs
Services de notifications Push Windows (WNS)
Notifications Push brutes

Ces fonctionnalités fournissent une prise en charge des applications à connexion permanente qui doivent recevoir des notifications Push brutes lors de l’interruption d’une application Windows Runtime. Ces applications sont également décrites comme accessibles à tout moment. La présente rubrique a pour objectif d’indiquer comment un développeur peut créer une application connectée en permanence en temps réel à l’aide du service WNS et de notifications Push brutes. Pour utiliser ces fonctionnalités, l’application doit être une application de l’écran de verrouillage.

D’autres fonctionnalités de tâches en arrière-plan peuvent également être utilisées par une application réseau. Vous trouverez ci-dessous plusieurs autres déclencheurs possibles pour une application Windows Runtime :

Déclencheurs de maintenance (événements périodiques de maintenance)
Déclencheurs système relatifs aux utilisateurs et sessions (session utilisateur connectée/déconnectée, utilisateur présent/absent et changement d’ID en ligne)
Déclencheurs système relatifs au statut de mise en réseau (changement d’état réseau, Internet disponible/non disponible)
Déclencheurs système relatifs aux écrans de verrouillage (ajout/suppression d’application)

Un minuteur est envisageable lorsque aucune connectivité en temps réel n’est requise pour une application, mais que cette dernière doit être exécutée un court instant à un intervalle défini. Un déclencheur système est envisageable lorsque l’application doit être informée d’événements (par exemple, la disponibilité de la connectivité Internet ou la présence d’un utilisateur). Il est possible de combiner plusieurs déclencheurs au sein d’une même application afin de prendre en charge une variété de scénarios. Pour plus d’informations, voir Définition de tâches en arrière-plan pour les besoins de votre application.

L’utilisation des notifications Push brutes décrites dans cette rubrique n’est pas requise pour la plupart des applications Windows Runtime. Une application peut donner l’impression à l’utilisateur qu’elle s’exécute en permanence en arrière-plan via une vignette dynamique ou via une vignette dynamique avec des notifications Push (autres que des notifications Push brutes) provenant du service WNS. Pour pouvoir recourir à une vignette dynamique, il n’est pas obligatoire que votre application soit une application de l ’écran de verrouillage (décrite plus loin dans cette rubrique) ou qu’elle s’exécute en arrière-plan. Toutefois, votre application doit figurer sur l’écran de verrouillage pour utiliser une vignette dynamique avec des notifications Push brutes.

Conditions requises pour une connexion permanente

Deux éléments sont généralement requis pour qu’une application reste connectée et accessible en permanence :

un processus longue durée permettant de s’assurer de la réception de toute notification réseau entrante et de son traitement rapide par l’application,
une connexion réseau longue durée à un point de terminaison distant capable de recevoir et d’envoyer des données lorsque cela est nécessaire.

Dans les versions antérieures de Windows, les applications continuent à s’exécuter lorsqu’elles passent en arrière-plan (et ne sont donc plus celles actives). Ces applications peuvent maintenir des connexions longue durée lorsqu’elles sont en arrière-plan, puisqu’elles peuvent envoyer et recevoir des données et des messages de persistance. La consommation de ressources résultant de cette exécution en arrière-plan est susceptible d’affecter la réactivité des autres applications et l’autonomie de la batterie.

Applications Windows Runtime et écran de verrouillage

Windows 8 introduit un nouveau modèle logiciel qui interrompt les applications Windows Runtime lors de leur passage en arrière-plan. Quand une application est interrompue, tous les paquets reçus par le système peuvent ne pas être immédiatement remis à l’application et les paquets réseau entrants peuvent être supprimés. Aucun nouveau paquet n’est envoyé quand l’application est suspendue. Toutes ces conditions peuvent aboutir à la fermeture de connexions réseau existantes.

Pour qu’une application reste connectée en permanence, il doit s’agir d’une application d’écran de verrouillage. Ce type spécial d’application peut afficher des notifications sur l’écran de verrouillage et exécuter du code en arrière-plan lorsque l’application ne se trouve pas au premier plan. Seules les applications utilisant une ou plusieurs tâches en arrière-plan peuvent être des applications d’écran de verrouillage.

Les applications d’écran de verrouillage ont des caractéristiques spécifiques :

Elles peuvent recevoir une notification Push brute du service WNS pouvant exécuter du code à la réception de la notification.
Elles peuvent exécuter du code au déclenchement d’un minuteur.
Elles peuvent exécuter du code au démarrage d’une session utilisateur.

Les applications épinglées sur l’écran de verrouillage peuvent présenter des informations à l’utilisateur lorsqu’elles sont en arrière-plan. Pour ce faire, une icône de badge mise à jour et affichée sur l’écran de verrouillage en cas de nouvelles informations est utilisée. Ces applications peuvent également afficher une notification à l’écran à réception d’un message. Si l’utilisateur appuie ou clique sur la notification, il est invité à déverrouiller l’appareil. Lorsque ce dernier est déverrouillé, l’application correspondant à la notification se lance avec des informations contextuelles.

Certaines restrictions considérables existent pour les applications d’écran de verrouillage. L’utilisateur ne peut pas disposer de plus de sept applications d’écran de verrouillage à tout moment. L’utilisateur peut ajouter une application à l’écran de verrouillage ou en supprimer une de cet écran à tout moment.

Les applications d’écran de verrouillage sont idéales pour fournir aux utilisateurs des informations sur ce qu’ils ont manqué lorsqu’ils ne se servaient pas de leur appareil. Elles sont également idéales pour fournir des notifications à l’écran nécessitant une action immédiate de l’utilisateur, telles qu’un appel téléphonique entrant, un message instantané entrant ou un message électronique urgent.

La plupart des applications ne devront pas être des applications d’écran de verrouillage. Lorsqu’une application est suspendue en arrière-plan, des notifications Push (autres que brutes) provenant du service WNS peuvent être utilisées pour actualiser une vignette dynamique et donner aux utilisateurs l’impression que l’application est en cours d’exécution, active et avec du contenu à jour. Le service WNS peut également servir à générer à tout moment une notification toast à l’attention de l’utilisateur ou à mettre à jour le nombre du badge sur la vignette de l’application.

Comme le nombre de connecteurs applicatifs d’écran de verrouillage est limité, prévoyez de créer une application de manière à ce qu’elle fonctionne même sans les autorisations relatives aux applications d’écran de verrouillage. L’utilisateur doit permettre explicitement l’ajout d’une application à l’écran de verrouillage. Votre application doit toujours fonctionner lorsqu’elle est visible au premier plan. Lorsqu’une application est une application d’écran de verrouillage, cela lui permet simplement de prendre en charge certains scénarios identiques en arrière-plan.

Une fonctionnalité permet à une application écrite en JavaScript et HTML de recevoir des paquets réseau entrants lorsque l’application est en arrière-plan.

Notifications Push brutes qui sont reçues par le système et qui entraînent l’exécution d’une tâche en arrière-plan dans l’application. En utilisant cette fonctionnalité, l’application reçoit les données brutes provenant des services de notifications Push Windows (WNS). Le contenu de ces données doit être compris par l’application. L’application doit s’inscrire auprès du service WNS pour recevoir la notification Push brute.

Pour que des scénarios en temps réel soient possibles pour les applications placées sur l’écran de verrouillage, vous pouvez procéder de l’une des façons décrites ci-dessous. Chaque approche a ses propres avantages et inconvénients. Les mécanismes indiqués ne s’excluent pas mutuellement. Vous pouvez les combiner dans certaines applications.

Utilisation du service WNS dans les applications du Windows Store

WNS est un service cloud hébergé par Microsoft pour Windows 8. Il permet aux applications Windows Runtime de recevoir des notifications pouvant exécuter du code, de mettre à jour une vignette dynamique ou de générer une notification à l’écran. Pour que ce service soit utilisé, l’ordinateur local doit être connecté à Internet pour que les services WNS puisse communiquer avec lui. Pour plus d’informations, voir Vue d’ensemble des notifications Push.

Le service WNS peut être utilisé pour une application Windows Runtime au premier plan afin de mettre à jour des vignettes dynamiques, de générer des notifications à l’attention de l’utilisateur ou d’actualiser des badges. Les applications n’ont pas besoin de se trouver sur l’écran de verrouillage pour pouvoir utiliser les services WNS. Envisagez d’utiliser ce service au sein de l’application si du code doit être exécuté en réponse à une notification Push.

Vous pouvez utiliser WNS afin de fournir une mise à jour de vignette dynamique pour les applications qui ne doivent pas nécessairement se trouver sur l’écran de verrouillage (soit la plupart des applications).

Si vous épinglez l’application Windows Runtime sur l’écran de verrouillage et que vous utilisez le service WNS en arrière-plan, l’application peut recevoir des notifications Push brutes de WNS en temps réel et les afficher sur l’écran de verrouillage sous la forme d’une mise à jour de badge ou d’une notification. Quand une notification Push brute est transmise à une application de l’écran de verrouillage, l’application peut exécuter du code en réponse à cette notification. L’utilisation des services WNS peut permettre d’économiser davantage d’énergie que l’utilisation des déclencheurs réseau disponibles pour les applications du Windows Store en C++/XAML et les applications utilisant .NET Framework 4.5 en C#, VB.NET ou C++ managé dans Windows 8.1 et Windows Server 2012 R2.

Avantages du service WNS :

Mécanisme de livraison de notifications en temps réel aux applications d’écran de verrouillage le moins consommateur d’énergie.
Simplification du modèle développeur de l’application. Dans la plupart des scénarios, il n’est pas nécessaire que les développeurs rédigent de tâches en arrière-plan car le système d’exploitation effectue le rendu des vignettes ou toasts. Toutefois, pour un petit ensemble de scénarios, si l’application doit exécuter une tâche en arrière-plan, elle doit inscrire la notification Push brute et la tâche en arrière-plan à exécuter.
Il n’est pas nécessaire de conserver une connexion de socket persistante entre l’application cliente et un serveur distant car Windows maintient la connexion au service WNS. Ainsi, la surcharge que constitue l’envoi de messages de persistance de connexion n’est pas nécessaire.
Une seule connexion WNS entre le client et le service cloud prend en charge toutes les applications sur l’ordinateur local, ce qui permet d’économiser potentiellement l’autonomie de la batterie du client.
Le coût opérationnel peut être réduit pour le service du côté serveur car il n’est pas nécessaire de maintenir de nombreuses connexions de sockets TCP entre le client et le service distant.
Votre application n’a pas besoin d’être en mémoire à tout moment. En effet, lorsqu’elle est arrêtée, le service WNS continue de mettre la vignette à jour, de générer le toast ou de déclencher une tâche en arrière-plan à exécuter à la réception d’une notification Push brute entrante.
Les tâches en arrière-plan qui utilisent les notifications Push brutes peuvent être écrites en JavaScript, C++/XAML et en utilisant .NET Framework 4.5 en C#, VB.NET ou C++ managé dans Windows 8.1 et Windows Server 2012 R2.

La fonctionnalité de déclencheur réseau qui utilise ControlChannelTrigger n’est pas disponible en JavaScript.

Remarque ControlChannelTrigger n’est pas pris en charge sur Windows Phone.

La mise en réseau en arrière-plan qui utilise des déclencheurs réseau peut être écrite uniquement en C++/XAML et en utilisant .NET Framework 4.5 en C#, VB.NET ou C++ managé dans Windows 8 et Windows Server 2012. Pour plus d’informations, voir Comment rester connecté en arrière-plan.

Il existe également des limitations de WNS susceptibles d’affecter certaines applications. Le service WNS n’est pas disponible pour les ordinateurs locaux connectés à un réseau d’entreprise ou domestique privé bloquant l’accès public à Internet. Certains pare-feux réseau peuvent également bloquer ce service même lorsqu’un accès à Internet est disponible. L’utilisation de WNS peut présenter d’autres inconvénients à prendre en considération. Les notifications sont notamment livrées autant que faire se peut, mais leur livraison n’est pas garantie. La taille maximale de la charge utile dans une notification Push brute est de 5 kilo-octets.

Au vu des avantages, nous recommandons aux développeurs créant des applications VoIP, de messagerie instantanée ou de messagerie électronique d’envisager d’utiliser des notifications WNS pour les applications de l’écran de verrouillage, à moins qu’elles ne répondent pas à leurs besoins, auquel cas d’autres alternatives peuvent être envisagées.

Il est inutile de créer une application d’écran de verrouillage si vous souhaitez simplement disposer d’une mise à jour de vignette dynamique ou générer un toast via le service WNS. Une application d’écran de verrouillage n’est requise lors de l’utilisation de WNS que lorsque l’application nécessite une notification Push brute pour déclencher une tâche à exécuter en arrière-plan.

Utilisation des minuteurs ou des déclencheurs d’événement système dans les applications Windows Runtime

Vous pouvez configurer des applications d’écran de verrouillage de manière à ce qu’elles exécutent du code de façon périodique via un minuteur dont l’intervalle minimum est de 15 minutes. Par exemple, cela peut être le cas lorsque des interrogations portant sur les nouveaux messages électroniques doivent être déclenchées, notamment lorsqu’une application est connectée à un serveur de messagerie POP3 ou IMAP.

Il est également possible d’utiliser un déclencheur d’événement système pour les applications d’écran de verrouillage afin qu’elles exécutent du code lorsque l’utilisateur ouvre une session sur l’ordinateur local (déclencheur système de démarrage de session). Connecter l’utilisateur à un service de messagerie instantanée au lancement de sa session afin qu’il puisse recevoir des messages instantanés constitue un exemple de ce type d’utilisation.

Cette rubrique est axée sur la création d’applications d’écran de verrouillage utilisant des notifications Push brutes avec le service WNS ou la fonctionnalité de déclencheur réseau. Pour plus d’informations sur l’utilisation d’un minuteur, voir Comment exécuter une tâche en arrière-plan sur un minuteur. Pour plus d’informations sur les tâches en arrière-plan, voir Définition de tâches en arrière-plan pour les besoins de votre application.

Tâche en arrière-plan et sandboxing

La durée de vie d’une tâche en arrière-plan est déterminée par la fonction qui implémente la tâche en arrière-plan. Pour garantir que les tâches en arrière-plan n’ont pas d’impact négatif sur l’autonomie de la batterie, Windows applique une limite en termes de ressources de processeur et d’E/S réseau qu’une application peut utiliser durant les tâches en arrière-plan. Chaque application obtient périodiquement un quota de ces ressources et l’épuisement de ce quota suspend la tâche en arrière-plan de votre application. Une application doit disposer de fonctionnalités de résilience pour être suspendue suite à un sandboxing.

Pour plus d’informations, voir Définition de tâches en arrière-plan pour les besoins de votre application.

Étapes ultérieures

Pour plus d’informations sur la façon de créer une application de l’écran de verrouillage pour recevoir des notifications réseau en arrière-plan qui utilisent des notifications Push brutes, voir Comment créer une application d’écran de verrouillage qui utilise des notifications Push brutes en arrière-plan.

Pour plus d’informations sur le processus visant à inscrire un canal de notification Push et à l’envoyer à votre serveur, à inscrire une tâche en arrière-plan à activer à partir d’une notification Push brute, à envoyer une notification Push brute au canal et à activer la tâche en arrière-plan, voir Comment utiliser le service WNS pour transmettre des notifications Push brutes à une application de l’écran de verrouillage.

Pour plus d’informations sur la manière d’écrire une tâche en arrière-plan pour recevoir des notifications réseau en arrière-plan qui utilisent les notifications Push brutes, voir Comment écrire une tâche en arrière-plan pour les notifications Push brutes.

Pour plus d’informations sur les recommandations et la liste de vérification pour l’utilisation des notifications Push brutes, voir Recommandations et liste de vérification sur les notifications brutes.