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.

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 :