Modèles
Les modèles permettent à une application cliente de spécifier le format exact des notifications que celle-ci souhaite recevoir. Une application peut utiliser des modèles pour en tirer plusieurs avantages, notamment les suivants :
Back-end indépendant de la plateforme.
Notifications personnalisées.
Indépendance de la version du client.
Localisation facile.
Cette section fournit deux exemples détaillés de la manière d’utiliser des modèles pour envoyer des notifications non spécifiques à une plateforme ciblant tous vos appareils sur des plateformes, et pour personnaliser la notification à diffusion générale pour chaque appareil.
Utilisation de modèles multiplateformes
La méthode classique d’envoi de notifications Push est d’envoyer, pour chaque notification à envoyer, une charge utile spécifique aux services de notification de plateforme (WNS, APNS). Par exemple, pour envoyer une alerte aux APNS, la charge utile est un objet JSON au format suivant :
{“aps”: {“alert” : “Hello!” }}
Pour envoyer un message toast similaire sur une application Windows Store, la charge utile est la suivante :
<toast>
<visual>
<binding template=\"ToastText01\">
<text id=\"1\">Hello!</text>
</binding>
</visual>
</toast>
Vous pouvez créer des charges utiles similaires pour les plateformes MPNS (Windows Phone) et GCM (Android).
Cette condition force le serveur principal de l’application à générer différentes charges utiles pour chaque plateforme, et rend en partie le serveur principal responsable de la couche présentation de l’application. Certaines préoccupations concernent les présentations graphiques et la localisation (en particulier pour les applications Windows Store qui incluent des notifications pour divers types de mosaïques).
La fonctionnalité de modèle Notification Hubs permet à une application cliente de créer des inscriptions spéciales, appelées inscriptions de modèles, qui incluent, en plus de l’ensemble de balises, un modèle. Dans les exemples de charge utile précédents, les seules informations non spécifiques à la plateforme sont le message d’alerte réel (Hello! ). Un modèle est un ensemble d’instructions destiné au hub de notification concernant la mise en forme d’un message non spécifique à une plateforme pour l’inscription de cette application cliente spécifique. Dans l’exemple précédent, le message non spécifique à une plateforme est une propriété unique : message = Hello!.
L’image suivante illustre le processus décrit ci-dessus :
Le modèle d’inscription d’une application cliente iOS est le suivant :
{“aps”:{“alert”:”$(message)”}}
Le modèle analogue pour une application cliente Windows Store est :
<toast>
<visual>
<binding template=\"ToastText01\">
<text id=\"1\">$(message)</text>
</binding>
</visual>
</toast>
Notez que le message réel est remplacé par l’expression $(message)
. Cette expression indique au Hub de notification, chaque fois qu’il envoie un message à cette inscription particulière, de générer un message qui suit ce modèle.
Les applications clientes peuvent créer plusieurs inscriptions afin d’utiliser plusieurs modèles ; par exemple, un modèle pour les messages d’alerte et un modèle pour les mises à jour de vignettes. Les applications clientes peuvent également combiner inscriptions natives (inscriptions sans modèle) et inscriptions avec modèle.
Notes
Le Hub de notification envoie une notification pour chaque inscription sans envisager s’ils appartiennent à la même application cliente. Ce comportement permet de convertir les notifications non spécifiques à une plateforme en plusieurs notifications. Par exemple, le même message non spécifique à une plateforme envoyé au hub de notification peut être converti de façon transparente en une alerte toast et une mise à jour de mosaïque, sans que le serveur principal n’en soit nécessairement averti. Notez bien que certaines plateformes (par exemple, iOS) peuvent regrouper plusieurs notifications sur le même appareil si elles sont envoyées sur une durée très courte.
Utilisation de modèles pour la personnalisation
Un autre avantage de l’utilisation des modèles est la possibilité d’utiliser les hubs de notification pour effectuer une personnalisation de notifications en fonction de l’inscription. Par exemple, prenez une application météo qui affiche une mosaïque contenant les conditions climatiques à un emplacement spécifique. Un utilisateur peut choisir entre les degrés Celsius ou Fahrenheit, et une prévision à un jour ou sur les cinq prochains jours. Grâce aux modèles, chaque installation d’application cliente peut s’inscrire au format approprié (Celsius sur 1 jour, Fahrenheit sur 1 jour, Celsius sur 5 jours, Fahrenheit sur 5 jours) et faire appel au serveur principal pour envoyer un message unique contenant toutes les informations nécessaires pour compléter ces modèles (par exemple, une prévision sur cinq jours en degrés Celsius et Fahrenheit).
Le modèle pour la prévision sur un jour avec les températures en degrés Celsius est comme suit :
<tile>
<visual>
<binding template="TileWideSmallImageAndText04">
<image id="1" src="$(day1_image)" alt="alt text"/>
<text id="1">Seattle, WA</text>
<text id="2">$(day1_tempC)</text>
</binding>
</visual>
</tile>
Le message envoyé au hub de notification contient les propriétés suivantes :
Day1_image
Day1_tempC
Day1_tempF
Day2_image
Day2_tempC
…
En utilisant ce modèle, le serveur principal envoie uniquement un message sans avoir à stocker des options de personnalisation spécifiques pour les utilisateurs de l’application. L’image suivante illustre ce scénario :
Guide pratique pour s’inscrire aux modèles
Pour plus d’informations sur l’inscription aux modèles, consultez Gestion des inscriptions.
Langage d’expression de modèle
Les modèles ne peuvent pas contenir de chaînes. Elles sont limitées aux documents XML ou JSON. Vous pouvez également placer des expressions à des endroits particuliers ; par exemple, des attributs de nœud ou des valeurs pour XML, des valeurs de propriété de chaîne pour JSON.
Par exemple, le modèle suivant n’est pas un modèle XML valide :
<tile>
<visual>
<binding $(property)>
<text id="1">Seattle, WA</text>
</binding>
</visual>
</tile>
Comme expliqué dans la section suivante, lors de l’utilisation de la concaténation, les expressions doivent être encapsulées entre crochets. Par exemple :
<tile>
<visual>
<binding template="ToastText01">
<text id="1">{'Hi, ' + $(name)}</text>
</binding>
</visual>
</tile>
Le code analogue dans JSON s’affiche comme suit :
{"aps":{"alert":"{'Hi, ' + $(name)}"}}
Le tableau suivant indique le langage autorisé dans les modèles :
Expression | Description |
---|---|
|
Référence à une propriété d’événement avec le nom donné. Les noms de propriétés ne respectent pas la casse. Cette expression se résout en valeur texte de la propriété ou en une chaîne vide si la propriété n’est pas présente. |
|
Comme ci-dessus, mais le texte est explicitement clippé à n caractères, par exemple |
|
Comme ci-dessus, mais le texte est suivi de trois points lorsqu’il est coupé. La taille totale de la chaîne coupée et du suffixe ne dépasse pas n caractères.
|
|
Similaire à |
#(prop) |
Utilisé dans les modèles JSON (par exemple, pour les modèles iOS et Android). Cette fonction fonctionne exactement comme Par exemple, |
|
Littéral. Les littéraux contiennent du texte arbitraire placé entre guillemets simples ou doubles. |
|
L’opérateur de concaténation joint deux expressions en une seule chaîne. Les expressions peuvent avoir n’importe laquelle des formes précédentes. Lors de l’utilisation de la concaténation, l’expression tout entière doit être placée entre |