Modelli

I modelli consentono alle applicazioni client di specificare il formato esatto delle notifiche da ricevere. Mediante i modelli, le app possono ottenere diversi vantaggi, fra cui i seguenti:

• Back-end agnostico della piattaforma.

• Notifiche personalizzate.

• Indipendenza della versione client.

• Facile localizzazione.

In questa sezione vengono forniti due esempi dettagliati di come utilizzare modelli per inviare notifiche indipendenti dalla piattaforma destinate a i dispositivi di tutte le piattaforme e per personalizzare la notifica di trasmissione per ciascun dispositivo.

Uso di modelli multipiattaforma

Il metodo standard per inviare notifiche push consiste nell'inviare, per ciascuna notifica, uno specifico payload dei servizi di notifica della piattaforma (WNS, servizio APN). Per inviare un avviso al servizio APN, ad esempio, il payload è un oggetto Json nel formato seguente:

{“aps”: {“alert” : “Hello!” }}

Per inviare un messaggio di avviso popup simile in un'applicazione Windows Store, il payload è il seguente:

<toast>
  <visual>
    <binding template=\"ToastText01\">
      <text id=\"1\">Hello!</text>
    </binding>
  </visual>
</toast>

È possibile creare payload simili per MPNS (Windows Phone) e piattaforme GCM (Android).

Tale requisito impone al back-end dell'app la produzione di payload diversi per ciascuna piattaforma e di fatto rende il back-end responsabile di parte del livello di presentazione dell'app. Alcuni dei problemi riguardano la localizzazione e i layout grafici (soprattutto per applicazioni di Windows Store che comprendono notifiche per vari tipi di riquadri).

La funzionalità del modello degli Hub di notifica consente a un'app client di creare registrazioni speciali, denominate registrazioni con modello, comprendenti un modello, oltre al set di tag. Dato gli esempi di payload precedenti, l'unica informazione indipendente dalla piattaforma è il messaggio di avviso effettivo (Hello!). Un modello è un set di istruzioni per l'Hub di notifica circa la modalità di formattazione di un messaggio indipendente dalla piattaforma per la registrazione di una determinata app client. Nell'esempio precedente, il messaggio indipendente dalla piattaforma consiste in una singola proprietà: message = Hello!.

Nell'immagine seguente viene illustrato il processo indicato in precedenza:

Il modello per una registrazione dell'app client iOS è il seguente:

{“aps”:{“alert”:”$(message)”}}

Il modello analogo per un'app client Windows Store è:

<toast>
  <visual>
    <binding template=\"ToastText01\">
      <text id=\"1\">$(message)</text>
    </binding>
  </visual>
</toast>

Si noti che il messaggio effettivo viene sostituito per l'espressione $(message). Questa espressione indica all'hub di notifica, ogni volta che invia un messaggio a questa specifica registrazione, per compilare un messaggio che segue questo modello.

Le applicazioni client possono creare più registrazioni per usare più modelli; ad esempio, un modello per i messaggi di avviso e un modello per gli aggiornamenti del riquadro. Inoltre, le applicazioni client possono unire registrazioni native (registrazioni senza modello) e registrazioni con modello.

Uso di modelli per la personalizzazione

Un altro vantaggio derivante dall'utilizzo di modelli è la possibilità di utilizzare gli Hub di notifica per eseguire la personalizzazione delle notifiche per registrazione. Si consideri ad esempio un'app meteo che visualizza un riquadro sulle condizioni meteorologiche relative a un luogo specifico. Un utente può scegliere tra gradi Celsius o Fahrenheit e una previsione singola o di cinque giorni. Mediante i modelli, ciascuna installazione dell'app client può registrare il formato richiesto (1 giorno in gradi Celsius 1 giorno in gradi Fahrenheit, 5 giorni in gradi Celsius, 5 giorni in gradi Fahrenheit), e far sì che il back-end invii un unico messaggio contenente tutte le informazioni necessarie per compilare i modelli (ad esempio una previsione di cinque giorni con gradi Celsius e Fahrenheit).

Il modello per la previsione di un giorno in gradi Celsius è il seguente:

<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>

Il messaggio inviato all'hub di notifica contiene le proprietà seguenti:

• Day1_image

• Day1_tempC

• Day1_tempF

• Day2_image

• Day2_tempC

• …

Utilizzando questo modello, il back-end invia solo un unico messaggio senza dover memorizzare opzioni di personalizzazione specifiche per gli utenti dell'app. Nell'immagine seguente viene illustrato tale scenario:

Come registrarsi per i modelli

Per altre informazioni su come eseguire la registrazione per i modelli, vedere Gestione registrazioni.

Linguaggio espressione modello

I modelli non possono contenere stringhe. Sono limitati ai documenti XML o JSON. Inoltre, è possibile inserire solo le espressioni in particolari punti: ad esempio, attributi dei nodi o valori per il formato XML, valori delle proprietà di stringa per il formato JSON.

Ad esempio, il modello XML seguente non è valido:

<tile>
  <visual>
    <binding $(property)>
      <text id="1">Seattle, WA</text>
    </binding>  
  </visual>
</tile>

Come illustrato nella sezione seguente, quando si usa la concatenazione, è necessario eseguire il wrapping delle espressioni in parentesi graffe. Ad esempio:

<tile>
  <visual>
    <binding template="ToastText01">
      <text id="1">{'Hi, ' + $(name)}</text>
    </binding>  
  </visual>
</tile>

Il codice analogo in JSON viene visualizzato come segue:

{"aps":{"alert":"{'Hi, ' + $(name)}"}}

Nella tabella seguente viene descritto il linguaggio consentito nei modelli: