Partilhar via

Modelos

  • Artigo

Os modelos permitem que uma aplicação do cliente especifique o formato exato das notificações que pretende receber. Utilizando modelos, uma aplicação pode realizar vários benefícios diferentes, incluindo os seguintes:

  • Um backend agnóstico de plataforma.

  • Notificações personalizadas.

  • Independência da versão do cliente.

  • Fácil localização.

Esta secção fornece dois exemplos aprofundados de como usar modelos para enviar notificações agnósticas da plataforma direcionadas a todos os seus dispositivos através de plataformas, e para personalizar a notificação de transmissão para cada dispositivo.

Usando modelos plataforma cruzada

A forma padrão de enviar notificações push é enviar, para cada notificação que deve ser enviada, uma carga útil específica para os serviços de notificação da plataforma (WNS, APNS). Por exemplo, para enviar um alerta para a APNS, a carga útil é um objeto Json do seguinte formulário:

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

Para enviar uma mensagem de torrada semelhante numa aplicação Windows Store, a carga útil é a seguinte:

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

Pode criar cargas similares para plataformas MPNS (Windows Phone) e GCM (Android).

Esta exigência obriga o backend da app a produzir cargas diferentes para cada plataforma, e efetivamente torna o backend responsável por parte da camada de apresentação da app. Algumas preocupações incluem localização e layouts gráficos (especialmente para aplicações Windows Store que incluem notificações para vários tipos de azulejos).

A funcionalidade de modelo 'Hubs' de Notificação permite a uma aplicação do cliente criar registos especiais, chamados registos de modelos, que incluem, além do conjunto de tags, um modelo. Tendo em conta os exemplos anteriores de carga útil, a única informação independente da plataforma é a mensagem de alerta real (Hello!). Um modelo é um conjunto de instruções para o Centro de Notificação sobre como formatar uma mensagem independente da plataforma para o registo dessa aplicação específica do cliente. No exemplo anterior, a mensagem independente da plataforma é uma única propriedade: mensagem = Olá!.

A seguinte imagem ilustra o processo acima:

Templates

O modelo para um registo de aplicações iOS cliente é o seguinte:

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

O modelo análogo para uma aplicação de cliente Windows Store é:

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

Note que a mensagem real é substituída pela expressão $(message). Esta expressão instrui o Centro de Notificação, sempre que envia uma mensagem a este registo em particular, para construir uma mensagem que siga este modelo.

As aplicações do cliente podem criar vários registos de forma a utilizar vários modelos; por exemplo, um modelo para mensagens de alerta e um modelo para atualizações de azulejos. As aplicações do cliente também podem misturar registos nativos (registos sem modelo) e registos de modelos.

Nota

O Centro de Notificação envia uma notificação para cada registo sem considerar se pertencem à mesma aplicação do cliente. Este comportamento pode ser usado para traduzir notificações independentes da plataforma em mais notificações. Por exemplo, a mesma mensagem independente da plataforma para o Centro de Notificação pode ser traduzida de forma perfeita num alerta de torradas e numa atualização de azulejos, sem que seja necessário que o backend esteja ciente do mesmo. De notar que algumas plataformas (por exemplo, iOS) podem colapsar várias notificações para o mesmo dispositivo se forem enviadas num curto espaço de tempo.

Usando modelos para personalização

Outra vantagem na utilização de modelos é a capacidade de usar Os Centros de Notificação para realizar a personalização por registo de notificações. Por exemplo, considere uma aplicação meteorológica que exibe um azulejo com as condições meteorológicas num local específico. Um utilizador pode escolher entre graus Celsius ou Fahrenheit, e uma previsão de um ou cinco dias. Utilizando modelos, cada instalação de aplicativos de cliente pode registar-se para o formato necessário (1 dia Celsius, 1 dia Fahrenheit, 5 dias Celsius, 5 dias Fahrenheit), e ter o backend enviar uma única mensagem que contém todas as informações necessárias para preencher esses modelos (por exemplo, uma previsão de cinco dias com graus Celsius e Fahrenheit).

O modelo para a previsão de um dia com temperaturas Celsius é o seguinte:

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

A mensagem enviada para o Centro de Notificação contém as seguintes propriedades:

  • Day1_image

  • Day1_tempC

  • Day1_tempF

  • Day2_image

  • Day2_tempC

  • …

Ao utilizar este padrão, o backend apenas envia uma única mensagem sem ter de armazenar opções específicas de personalização para os utilizadores da aplicação. A seguinte imagem ilustra este cenário:

Templates

Como registar-se para modelos

Para obter mais informações sobre como se registar para modelos, consulte Gestão de Registos.

Linguagem de expressão de molde

Os modelos não podem conter cordas. Limitam-se a documentos XML ou JSON. Além disso, só se podem colocar expressões em locais específicos; por exemplo, atributos ou valores de nó para XML, valores de propriedade de cadeia para JSON.

Por exemplo, o seguinte não é um modelo XML válido:

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

Como explicado na secção seguinte, quando se utiliza concatenação, as expressões devem ser embrulhadas em suportes encaracolados. Por exemplo:

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

O código análogo em JSON aparece da seguinte forma:

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

A tabela a seguir mostra o idioma permitido nos modelos:

Expressão Descrição

$(prop)

Referência a uma propriedade do evento com o nome próprio. Os nomes de propriedade não são sensíveis a casos. Esta expressão resolve-se no valor de texto da propriedade ou numa cadeia vazia se a propriedade não estiver presente.

$(prop, n)

Como acima, mas o texto é explicitamente cortado em n caracteres, por exemplo $(title, 20) clips o conteúdo da propriedade do título em 20 caracteres.

.(prop, n)

Como acima, mas o texto é sufixado com três pontos à medida que é cortado. O tamanho total da corda cortada e do sufixo não excede os caracteres n. .(title, 20) com uma propriedade de entrada de "This is the title line" resulta em This is the title.....

%(prop)

Semelhante a $(name) exceto que a saída é codificada por URI.

#(prop)

Usado em modelos JSON (por exemplo, para iOS e modelos de Android).

Esta função funciona exatamente da mesma forma $(prop) que previamente especificada, exceto quando usada em modelos JSON (por exemplo, modelos apple). Neste caso, se esta função não estiver rodeada por "{'}"}" (por exemplo, ‘myJsonProperty’ : ‘#(name)’)e avaliar um número em formato Javascript, por exemplo, regexp: (0|([1-9][0-9]*))(\.[0-9]+)?((e|E)(+|-)?[0-9]+)?então o JSON de saída é um número.

Por exemplo, ‘badge : ‘#(name)’ torna-se ‘badge’ : 40 (e não ‘40‘).

‘text’ or “text”

Um literal. Os literais contêm texto arbitrário incluído em ações simples ou duplas.

expr1 + expr2

O operador de concatenação une duas expressões numa única corda.

As expressões podem ser qualquer uma das formas anteriores.

Ao utilizar a concatenação, toda a expressão deve estar rodeada de {}. Por exemplo, {$(prop) + ‘ - ’ + $(prop2)}.