Cette page vous a-t-elle été utile ?
Votre avis sur ce contenu est important. N'hésitez pas à nous faire part de vos commentaires.
Vous avez d'autres commentaires ?
1500 caractères restants
Exporter (0) Imprimer
Développer tout
Informations
Le sujet que vous avez demandé est indiqué ci-dessous. Toutefois, ce sujet ne figure pas dans la bibliothèque.

Vue d’ensemble des notifications brutes (applications Windows Runtime)

Les notifications brutes sont des notifications Push courtes à usage général. Elles ont une finalité exclusivement didactique et n’incluent aucun composant d’interface utilisateur. Comme avec d’autres notifications Push, la fonctionnalité des services de notifications Push Windows (WNS) fournit des notifications brutes de votre service cloud à votre application.

Les notifications brutes peuvent être employées à diverses fins, notamment pour inciter votre application à exécuter une tâche en arrière-plan si l’utilisateur a autorisé l’application à le faire. En faisant appel à la fonctionnalité WNS pour communiquer avec votre application, vous pouvez éviter la surcharge de traitement liée à la création de connexions de sockets permanentes, l’envoi de messages HTTP GET et d’autres connexions entre services et applications.

Important   Pour comprendre les notifications brutes, vous devez connaître les concepts abordés dans la rubrique Vue d’ensemble des services de notifications Push Windows (WNS).

Comme pour les notifications Push par toast, vignette et badge, une notification brute est transmise via un URI (Uniform Resource Identifier) de canal affecté depuis le service cloud de votre application vers WNS. WNS, à son tour, transmet la notification au périphérique et au compte d’utilisateur associé au canal. Toutefois, contrairement à d’autres notifications Push, les notifications brutes n’adoptent aucun format spécifique. Le contenu de la charge utile est entièrement défini pour l’application.

Pour donner un exemple d’application pouvant bénéficier de notifications brutes, examinons une application de collaboration documentaire fictive. Imaginez deux utilisateurs modifiant le même document simultanément. Le service cloud qui héberge le document partagé peut utiliser des notifications brutes pour informer chaque utilisateur dès qu’un autre utilisateur apporte des modifications. Les notifications brutes ne doivent pas nécessairement contenir les modifications apportées au document mais doit plutôt inciter chaque copie de l’application de l’utilisateur à contacter l’emplacement central et à synchroniser les modifications disponibles. À l’aide de notifications brutes, l’application et son service cloud peut enregistrer la surcharge inhérente au maintien de connexions permanentes tant que le document reste ouvert.

Fonctionnement des notifications brutes

Toutes les notifications brutes sont des notifications Push. C’est pourquoi la configuration requise pour envoyer et recevoir des notifications Push concerne également les 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, voir Comment demander, créer et enregistrer un canal de notification.
  • Vous devez inclure la fonctionnalité Internet dans le manifeste de votre application. Vous trouverez cette option sous la forme Internet (client) dans l’onglet Capacités de l’éditeur de manifeste Microsoft Visual Studio. Pour plus d’informations, voir Capabilities.

Le corps de la notification apparaît dans un format défini pour l’application. Le client reçoit les données sous la forme d’une chaîne (HSTRING) terminée par un caractère NULL que seule l’application doit comprendre.

Si le client est hors connexion, les notifications brutes seront mises en cache par la fonctionnalité WNS uniquement si l’en-tête X-WNS-Cache-Policy est inclus dans la notification. Cependant, une seule notification brute sera mise en cache et publiée dès que le périphérique est de nouveau en ligne.

Il existe trois options de traitement d’une notification brute sur le client : la remise à votre application via un événement de remise de notification, l’envoi à une tâche en arrière-plan ou l’abandon. Par conséquent, si le client est hors connexion et si WNS tente d’émettre une notification brute, la notification est annulée.

Création d’une notification brute

L’envoi d’une notification brute est similaire à l’envoi d’une notification push par vignette, toast ou badge avec les différences suivantes :

  • 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 la notification doit contenir une charge utile de chaînes d’une taille inférieure à 5 Ko.

Les notifications brutes sont des messages brefs conçus pour inciter votre application à agir, notamment en contactant directement le service pour synchroniser une grande quantité de données ou modifier un état local fondé sur le contenu des notifications. Notez que la remise des notifications Push WNS est impossible à garantir ; votre application et votre service cloud doivent donc tenir compte de l’éventualité que la notification brute ne parvienne pas au client, notamment lorsque celui-ci est hors connexion.

Pour plus d’informations sur l’envoi de notifications Push, voir Démarrage rapide : envoi d’une notification Push.

Réception d’une notification brute

Il existe deux méthodes par lesquelles votre application peut recevoir des notifications brutes :

Une application peut recourir à ces 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 les notifications brutes, l’événement de remise de notification sera prioritaire lorsque l’application sera exécutée.

  • Si l’application est en cours d’exécution, l’événement de remise de notification aura priorité sur la tâche en arrière-plan et l’application aura l’occasion de gérer la notification.
  • En définissant la propriété PushNotificationReceivedEventArgs.Cancel de l’événement sur true, le gestionnaire d’événements de remise de notification peut préciser de ne pas transmettre la notification brute à sa tâche en arrière-plan dès que le gestionnaire se ferme. Si la propriété Cancel est définie sur false ou n’est pas définie (la valeur par défaut est false), la notification brute déclenchera la tâche en arrière-plan une fois le travail du gestionnaire d’événements de remise de notification terminé.

Événements de remise de notification

Votre application peut utiliser un événement de remise de notification (PushNotificationReceived) pour recevoir des notifications brutes lorsque l’application est en cours d’utilisation. Quand le service cloud envoie une notification brute, l’application est en cours d’exécution peut la recevoir en gérant l’événement de remise de notification sur l’URI de canal.

Si votre application n’est pas en cours d’exécution et ne fait appel à aucune tâche en arrière-plan, toutes les notifications brutes transmises à cette application sont ignorées par WNS dès réception. Pour éviter de gaspiller les ressources de votre service cloud, vous pouvez envisager la mise en place d’une logique sur le service pour contrôler si l’application est active ou non. Pour ces informations, il existe deux sources : une application peut explicitement indiquer au service qu’elle est prête à recevoir des notifications et la fonctionnalité WNS peut indiquer au service quand arrêter.

  • L’application informe le service cloud : l’application peut contacter son service pour l’informer que l’application fonctionne au premier plan. L’inconvénient de cette approche est que l’application peut finir par contacter votre service de manière très fréquente. En revanche, elle présente l’avantage que le service saura toujours lorsque l’application est prête à recevoir des notifications brutes entrantes. Un autre avantage est que, lorsque l’application contacte son service, celui-ci sait alors qu’il faut envoyer des notifications brutes à l’instance spécifique de cette application plutôt que procéder à une diffusion.
  • Le service cloud répond aux messages de réponse WNS.Le service de votre application peut utiliser les informations X-WNS-NotificationStatus et X-WNS-DeviceConnectionStatus renvoyées par la fonctionnalité WNS pour déterminer à quel moment cesser l’envoi de notifications brutes à l’application. Lorsque votre service envoie une notification à un canal sous la forme d’une demande POST HTTP, il peut recevoir l’un des messages suivants en guise de réponse :
    • X-WNS-NotificationStatus: dropped : cela signifie que le client n’a pas reçu la notification. On peut raisonnablement supposer que la réponse dropped est générée par votre application que ne figure plus au premier plan du périphérique de l’utilisateur.
    • X-WNS-DeviceConnectionStatus: disconnected ou X-WNS-DeviceConnectionStatus: tempconnected : ceci indique que le client Windows ne bénéficie plus d’une 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 la demande POST HTTP de la notification.

    Le service cloud de votre application peut exploiter les informations incluses dans ces messages d’état pour cesser toute tentative de communication par le biais de notifications brutes. Le service peut reprendre l’envoi de notifications brutes dès que l’application le contacte, quand celle-ci revient au premier plan.

    Notez qu’il est préférable de ne pas se fier aux informations X-WNS-NotificationStatus pour déterminer si la notification a été correctement remise au client.

    Pour plus d’informations, voir En-têtes des demandes et des réponses des services de notifications Push.

Tâches en arrière-plan déclenchées par des notifications brutes

Important  Un utilisateur doit explicitement autoriser une application à exécuter des tâches en arrière-plan quand l’utilisateur ajoute une application à son écran de verrouillage. Seules sept applications peuvent bénéficier de cette autorisation en même temps. Sans cette autorisation, tous les aspects abordés dans cette section seront ignorés. Pour plus d’informations, voir Vue d’ensemble des écrans de verrouillage.

Votre tâche en arrière-plan doit être inscrite avec un PushNotificationTrigger. Si elle ne l’est pas, la tâche ne sera pas exécutée dès qu’une notification brute sera reçue.

Une tâche en arrière-plan qui est déclenchée par une notification brute permet au service cloud de votre application de contacter cette dernière même quand elle n’est pas exécutée (il peut toutefois déclencher son exécution). Cela se produit sans que l’application ne doive maintenir une connexion permanente. Les notifications brutes sont le seul type de notification capable de déclencher des tâches en arrière-plan. Cependant, s’il est impossible pour les notifications Push par vignette, toast et badge de déclencher des tâches en arrière-plan, les tâches en arrière-plan déclenchées par les notifications brutes peuvent mettre à jour les vignettes et appeler des notifications toast via des appels d’API locaux.

Pour donner un exemple illustrant la manière dont fonctionnent les tâches en arrière-plan déclenchées par des notifications brutes, imaginons une application conçue pour lire des livres électroniques. Pour commencer, un utilisateur achète un livre en ligne, peut-être sur un autre périphérique. En guise de réponse, le service cloud de l’application peut envoyer une notification brute à chacun des périphériques de l’utilisateur, avec une charge utile qui indique que le livre a été acheté et que l’application doit le télécharger. L’application contacte ensuite directement le service cloud de l’application pour lancer un téléchargement en arrière-plan du nouveau livre afin pour que, plus tard, dès que l’utilisateur démarre l’application, le livre soit déjà présent et prêt à être lu.

Pour utiliser une notification brute et déclencher une tâche en arrière-plan, votre application doit effectuer les opérations suivantes :

  1. Demander et obtenir l’autorisation de l’utilisateur d’exécuter des tâches en arrière-plan avec une application. Pour plus d’informations, voir Vue d’ensemble des écrans de verrouillage.
  2. Implémenter la tâche en arrière-plan. Pour plus d’informations, voir Définition de tâches en arrière-plan pour les besoins de votre application.

Votre tâche en arrière-plan est ensuite appelée en réponse à l’événement PushNotificationTrigger chaque fois qu’une notification brute est reçue pour votre application. Votre tâche en arrière-plan interprète alors la charge utile spécifique à l’application de la notification brute et intervient en conséquence.

Pour chaque application, une seule tâche en arrière-plan peut être exécutée à la fois. Si vous déclenchez une tâche en arrière-plan 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 arriver à terme avant que la nouvelle ne soit exécutée.

Autres ressources

Pour examiner les concepts mis en œuvre dans un exemple de code complet dans cette rubrique, voir Exemple de notifications brutes. Pensez également à consulter la rubrique Exemple de notifications Push et périodiques pour obtenir des détails d’ordre général sur l’implémentation de notifications Push.

Rubriques associées

Exemple de notifications brutes
Recommandations et liste de vérification sur les notifications brutes
Démarrage rapide : création et inscription d’une tâche de notification brute en arrière-plan
Démarrage rapide : interception de notifications Push dans des applications en cours d’exécution
RawNotification

 

 

Afficher:
© 2015 Microsoft