Vue d’ensemble des notifications brutes
Les notifications brutes sont des notifications push courtes et à usage général. Ils sont strictement pédagogiques et n’incluent pas de composant d’interface utilisateur. Comme avec d’autres notifications Push, la fonctionnalité Windows Push Notification Services (WNS) fournit des notifications brutes de votre service cloud à votre application.
Vous pouvez utiliser des notifications brutes à diverses fins, notamment pour déclencher l’exécution d’une tâche en arrière-plan si l’utilisateur a donné l’autorisation d’effectuer cette opération. En utilisant WNS pour communiquer avec votre application, vous pouvez éviter la surcharge de traitement de la création de connexions de socket persistantes, l’envoi de messages HTTP GET et d’autres connexions de service à application.
Important
Pour comprendre les notifications brutes, il est préférable d’être familiarisé avec les concepts abordés dans la vue d’ensemble de Windows Push Notification Services (WNS).
Comme pour les notifications Push toast, vignette et badge, une notification brute est envoyée par le service cloud de votre application via un URI (Uniform Resource Identifier) de canal affecté à WNS. WNS, à son tour, remet la notification à l’appareil et au compte d’utilisateur associé à ce canal. Contrairement à d’autres notifications Push, les notifications brutes n’ont pas de format spécifié. Le contenu de la charge utile est entièrement défini par l’application.
Comme illustration d’une application qui pourrait tirer parti des notifications brutes, examinons une application théorique de collaboration de documents. Considérez deux utilisateurs qui modifient le même document en même temps. Le service cloud, qui héberge le document partagé, peut utiliser des notifications brutes pour avertir chaque utilisateur lorsque des modifications sont apportées par l’autre utilisateur. Les notifications brutes ne contiennent pas nécessairement les modifications apportées au document, mais signalent plutôt la copie de l’application à chaque utilisateur pour contacter l’emplacement central et synchroniser les modifications disponibles. En utilisant des notifications brutes, l’application et son service cloud peuvent économiser la surcharge de maintenance des connexions persistantes pendant toute la durée d’ouverture du document.
Fonctionnement des notifications brutes
Toutes les notifications brutes sont des notifications Push. Par conséquent, la configuration requise pour envoyer et recevoir des notifications Push s’applique également aux notifications brutes :
- Vous devez disposer d’un canal WNS valide pour envoyer des notifications brutes. Pour plus d’informations sur l’acquisition d’un canal de notification Push, consultez Comment demander, créer et enregistrer un canal de notification.
- Vous devez inclure la fonctionnalité Internet dans le manifeste de votre application. Dans l’éditeur de manifeste Microsoft Visual Studio, vous trouverez cette option sous l’onglet Fonctionnalités en tant que Client (Internet). Pour plus d’informations, consultez Fonctionnalités.
Le corps de la notification est dans un format défini par l’application. Le client reçoit les données sous la forme d’une chaîne terminée par null (HSTRING) qui doit uniquement être comprise par l’application.
Si le client est hors connexion, les notifications brutes sont mises en cache par WNS uniquement si l’en-tête X-WNS-Cache-Policy est inclus dans la notification. Toutefois, une seule notification brute sera mise en cache et remise une fois que l’appareil revient en ligne.
Il n’existe que trois chemins possibles pour qu’une notification brute prenne sur le client : ils seront remis à votre application en cours d’exécution via un événement de remise de notification, envoyé à une tâche en arrière-plan ou supprimé. Par conséquent, si le client est hors connexion et que WNS tente de remettre une notification brute, la notification est supprimée.
Création d’une notification brute
L’envoi d’une notification brute est similaire à l’envoi d’une vignette, d’un toast ou d’une notification Push de badge, avec ces différences :
- L’en-tête HTTP Content-Type doit être défini sur « application/octet-stream ».
- L’en-tête HTTP X-WNS-Type doit être défini sur « wns/raw ».
- Le corps de notification peut contenir n’importe quelle charge utile de chaîne inférieure à 5 Ko, mais ne doit pas être une chaîne vide.
Les notifications brutes sont destinées à être utilisées en tant que messages courts qui déclenchent l’exécution d’une action, par exemple pour contacter directement le service pour synchroniser une plus grande quantité de données ou pour apporter une modification d’état local en fonction du contenu de notification. Notez que les notifications Push WNS ne peuvent pas être garanties pour être remises. Par conséquent, votre application et votre service cloud doivent tenir compte de la possibilité que la notification brute n’atteigne pas le client, par exemple lorsque le client est hors connexion.
Pour plus d’informations sur l’envoi de notifications Push, consultez Démarrage rapide : Envoi d’une notification Push.
Réception d’une notification brute
Il existe deux avenues par lesquelles votre application peut recevoir des notifications brutes :
- Par le biais d’événements de remise de notification pendant l’exécution de votre application.
- Via les tâches en arrière-plan déclenchées par la notification brute si votre application est activée pour exécuter des tâches en arrière-plan.
Une application peut utiliser les deux mécanismes pour recevoir des notifications brutes. Si une application implémente à la fois le gestionnaire d’événements de remise de notification et les tâches en arrière-plan déclenchées par des notifications brutes, l’événement de remise de notification est prioritaire lors de l’exécution de l’application.
- Si l’application est en cours d’exécution, l’événement de remise de notification prend la priorité sur la tâche en arrière-plan et l’application aura la première occasion de traiter la notification.
- Le gestionnaire d’événements de remise de notification peut spécifier, en définissant la propriété PushNotificationReceivedEventArgs.Cancel de l’événement sur true, que la notification brute ne doit pas être passée à sa tâche en arrière-plan une fois le gestionnaire arrêté. Si la propriété Cancel a la valeur false ou n’est pas définie (la valeur par défaut est false), la notification brute déclenche la tâche en arrière-plan une fois que le gestionnaire d’événements de remise de notification a effectué son travail.
Événements de remise de notification
Votre application peut utiliser un événement de remise de notification (PushNotificationReceived) pour recevoir des notifications brutes pendant l’utilisation de l’application. Lorsque le service cloud envoie une notification brute, l’application en cours d’exécution peut la recevoir en gérant l’événement de remise de notification sur l’URI du canal.
Si votre application n’est pas en cours d’exécution et n’utilise pas de tâches en arrière-plan), toute notification brute envoyée à cette application est supprimée par WNS lors de la réception. Pour éviter de perdre les ressources de votre service cloud, vous devez envisager d’implémenter une logique sur le service pour déterminer si l’application est active. Il existe deux sources de ces informations : une application peut indiquer explicitement au service qu’elle est prête à commencer à recevoir des notifications, et WNS peut indiquer au service quand arrêter.
L’application avertit le service cloud : l’application peut contacter son service pour lui indiquer que l’application s’exécute au premier plan. L’inconvénient de cette approche est que l’application peut contacter votre service très fréquemment. Toutefois, il présente l’avantage que le service saura toujours quand l’application est prête à recevoir des notifications brutes entrantes. Un autre avantage est que lorsque l’application contacte son service, le service sait ensuite envoyer des notifications brutes à l’instance spécifique de cette application plutôt que de diffuser.
Le service cloud répond aux messages de réponse WNS : votre service d’application peut utiliser les informations X-WNS-NotificationStatus et X-WNS-DeviceConnectionStatus retournées par WNS pour déterminer quand arrêter l’envoi de notifications brutes à l’application. Lorsque votre service envoie une notification à un canal en tant que HTTP POST, il peut recevoir l’un de ces messages dans la réponse :
- X-WNS-NotificationStatus : supprimé : cela indique que la notification n’a pas été reçue par le client. Il s’agit d’une hypothèse sûre que la réponse supprimée est due à l’absence de votre application au premier plan sur l’appareil de l’utilisateur.
- X-WNS-DeviceConnectionStatus : déconnecté ou X-WNS-DeviceConnectionStatus : tempconnected : cela indique que le client Windows n’a plus de connexion à WNS. Notez que pour recevoir ce message de WNS, vous devez le demander en définissant l’en-tête X-WNS-RequestForStatus dans http POST de la notification.
Le service cloud de votre application peut utiliser les informations contenues dans ces messages d’état pour cesser les tentatives de communication via des notifications brutes. Le service peut reprendre l’envoi de notifications brutes une fois qu’il est contacté par l’application, lorsque l’application bascule au premier plan.
Notez que vous ne devez pas vous appuyer sur X-WNS-NotificationStatus pour déterminer si la notification a été correctement remise au client.
Pour plus d’informations, consultez les en-têtes de demande et de réponse du service de notification Push
Tâches en arrière-plan déclenchées par des notifications brutes
Important
Avant d’utiliser des tâches en arrière-plan de notification brutes, une application doit disposer d’un accès en arrière-plan via BackgroundExecutionManager.RequestAccessAsync.
Votre tâche en arrière-plan doit être inscrite auprès d’un PushNotificationTrigger. S’il n’est pas inscrit, la tâche ne s’exécute pas lorsqu’une notification brute est reçue.
Une tâche en arrière-plan déclenchée par une notification brute permet au service cloud de votre application de contacter votre application, même lorsque l’application n’est pas en cours d’exécution (bien qu’elle puisse la déclencher pour s’exécuter). Cela se produit sans que l’application ait à maintenir une connexion continue. Les notifications brutes sont le seul type de notification qui peut déclencher des tâches en arrière-plan. Toutefois, alors que les notifications Push toast, vignette et badge ne peuvent pas déclencher des tâches en arrière-plan, les tâches en arrière-plan déclenchées par des notifications brutes peuvent mettre à jour des vignettes et appeler des notifications toast par le biais d’appels d’API locaux.
Comme illustration de la façon dont les tâches en arrière-plan déclenchées par des notifications brutes fonctionnent, prenons l’exemple d’une application utilisée pour lire des livres électroniques. Tout d’abord, un utilisateur achète un livre en ligne, éventuellement sur un autre appareil. En réponse, le service cloud de l’application peut envoyer une notification brute à chacun des appareils de l’utilisateur, avec une charge utile qui indique que le livre a été acheté et que l’application doit la télécharger. L’application contacte ensuite directement le service cloud de l’application pour commencer un téléchargement en arrière-plan du nouveau livre afin que, plus tard, lorsque l’utilisateur lance l’application, le livre est déjà là et prêt à la lecture.
Pour utiliser une notification brute pour déclencher une tâche en arrière-plan, votre application doit :
- Demandez l’autorisation d’exécuter des tâches en arrière-plan (que l’utilisateur peut révoquer à tout moment) à l’aide de BackgroundExecutionManager.RequestAccessAsync.
- Implémentez la tâche en arrière-plan. Pour plus d’informations, consultez Prendre en charge votre application avec des tâches en arrière-plan
Votre tâche en arrière-plan est ensuite appelée en réponse à PushNotificationTrigger, chaque fois qu’une notification brute est reçue pour votre application. Votre tâche en arrière-plan interprète la charge utile propre à l’application de la notification brute et agit dessus.
Pour chaque application, une seule tâche en arrière-plan peut s’exécuter à la fois. Si une tâche en arrière-plan est déclenchée pour une application pour laquelle une tâche en arrière-plan est déjà en cours d’exécution, la première tâche en arrière-plan doit se terminer avant l’exécution du nouveau.
Autres ressources
Vous pouvez en savoir plus en téléchargeant l’exemple de notifications brutes pour Windows 8.1 et l’exemple de notifications Push et périodiques pour Windows 8.1, et en réutilisant leur code source dans votre application Windows 10.
Rubriques connexes
- Recommandations en matière de notifications brutes
- Démarrage rapide : Création et inscription d’une tâche en arrière-plan de notification brute
- Démarrage rapide : Interception des notifications Push pour l’exécution d’applications
- RawNotification
- BackgroundExecutionManager.RequestAccessAsync
Windows developer