Share via

Шаблоны

  • Статья

Шаблоны позволяют клиентскому приложению определять точный формат уведомлений, которые оно будет получать. С помощью шаблонов приложение получает несколько преимуществ, включая следующие:

  • Не зависящая от платформы серверная часть.

  • Персонализированные уведомления.

  • Независимость от версии клиента.

  • Простая локализация.

В этом разделе приводится два подробных примера использования шаблонов для отправки платформонезависимых уведомлений, предназначенных для всех устройств на разных платформах, и для персонализации широковещательного уведомления для каждого устройства.

Использование кроссплатформенных шаблонов

Стандартный способ отправки push-уведомлений заключается в отправке полезных данных в службу уведомлений платформы (WNS, APNS) для каждого уведомления. Например, для отправки предупреждения службе APNS полезными данными будет объект JSON следующего вида:

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

Чтобы отправить аналогичное всплывающее сообщение в приложении Windows Store, полезные данные выглядят следующим образом:

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

Аналогичные полезные данные можно создавать для платформ MPNS (Windows Phone) и GCM (Android).

Это требование заставляет серверную часть приложения формировать разные полезные данные для каждой платформы, а также возлагает на нее ответственность за часть уровня представления данных в приложении. К некоторым вопросам относятся локализация и графические макеты (особенно для приложений Магазина Windows, которые содержат уведомления для плиток различных типов).

Шаблон центра уведомлений позволяет клиентскому приложению создавать специальные регистрации (называются шаблонными регистрациями), которые содержат не только набор тегов, но и шаблон. В предыдущих примерах полезных данных единственным фрагментом информации, не зависящим от платформы, является сообщение с оповещением (Hello! ). Шаблон — это набор инструкций для центра уведомлений о форматировании платформонезависимых сообщений для регистрации конкретного клиентского приложения. В предыдущем примере платформонезависимым сообщением является одно свойство: message = Hello!.

На следующем рисунке показана схема работы.

Templates

Шаблон для регистрации клиентского приложения iOS выглядит следующим образом:

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

Аналогичный шаблон для клиентского приложения Windows Store:

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

Обратите внимание, что фактическое сообщение заменяется выражением $(message). Это выражение предписывает Центру уведомлений каждый раз, когда он отправляет сообщение в эту конкретную регистрацию, чтобы создать сообщение, которое следует этому шаблону.

Клиентские приложения могут создавать несколько регистраций для использования нескольких шаблонов; Например, шаблон для сообщений оповещений и шаблон для обновлений плиток. Клиентские приложения также могут использовать комбинацию собственных регистраций (регистраций без шаблона) и регистраций с шаблонами.

Примечание

Центр уведомлений отправляет по одному уведомлению для каждой регистрации, не учитывая, принадлежат ли они одному клиентскому приложению. Это поведение может использоваться для преобразования платформонезависимых уведомлений в серию уведомлений. Например, одно платформонезависимое сообщение для центра уведомлений может быть автоматически преобразовано во всплывающее предупреждение и обновление плитки, не требуя участия серверной части. Обратите внимание, что некоторые платформы (например iOS) могут сворачивать несколько уведомлений для одного устройства, если они отправляются в течение короткого периода времени.

Использование шаблонов для персонализации

Еще одним преимуществом использования шаблонов является возможность использования центров уведомлений для персонализации уведомлений по отдельным регистрациям. Например, рассмотрим погодное приложение, которое отображает плитку с погодными условиями в определенном месте. Пользователь может выбрать между отображением градусов Цельсия или Фаренгейта и прогноз на один или на пять дней. С помощью шаблонов каждая установка клиентского приложения может зарегистрировать необходимый для себя формат (1 день и шкала Цельсия, 1 день и шкала Фаренгейта, 5 дней и шкала Цельсия, 5 дней и шкала Фаренгейта), а его серверная часть будет отправлять одно сообщение со всеми данными, необходимыми для заполнения шаблонов (например, пятидневный прогноз с градусами Цельсия и Фаренгейта).

Шаблон для прогноза погоды на один день и шкалой Цельсия выглядит следующим образом:

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

Сообщение, отправленное в Центр уведомлений, содержит следующие свойства:

  • Day1_image

  • Day1_tempC

  • Day1_tempF

  • Day2_image

  • Day2_tempC

  • …

С помощью этого шаблона серверная часть отправляет только одно сообщение без необходимости хранить персональные параметры для пользователей приложения. На следующем рисунке показана схема работы.

Templates

Регистрация для шаблонов

Дополнительные сведения о регистрации шаблонов см. в разделе "Управление регистрацией".

Язык выражений шаблона

Шаблоны не могут содержать строки. Они ограничены документами XML или JSON. Кроме того, выражения можно размещать только в определенных местах. Например, атрибуты узла или значения для XML и значения строковых свойств для JSON.

Например, ниже представлен недопустимый шаблон XML:

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

Как описано в следующем разделе, при использовании объединения выражения должны быть заключены в фигурные скобки. Вот несколько примеров.

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

Аналогичный код в JSON выглядит следующим образом:

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

В следующей таблице показан синтаксис, используемый в шаблонах:

Выражение Описание

$(prop)

Ссылка на свойство события с заданным именем. В именах свойств регистр не учитывается. Значением этого выражения является текстовое значение свойства или пустая строка, если свойство не существует.

$(prop, n)

Как описано выше, но текст явно обрезается n символов, например $(title, 20) обрезает содержимое свойства заголовка на 20 символов.

.(prop, n)

То же, что выше, но к тексту добавляются три точки, поскольку он является сокращенным. Общий размер сокращенной строки и суффикса не превышает n символов. .(title, 20) с входным свойством "Это строка заголовка" приводит к тому, что это заголовок.....

%(prop)

Аналогично тому, что $(name) выходные данные кодируются в кодировке URI.

#(prop)

Используется в шаблонах JSON (например, для шаблонов iOS и Android).

Эта функция работает точно так же, как $(prop) указано ранее, за исключением случаев использования в шаблонах JSON (например, шаблонов Apple). В этом случае, если эта функция не заключена в "{","}" (например, ‘myJsonProperty’ : ‘#(name)’)и вычисляется как число в формате Javascript, например, regexp: (0|([1-9][0-9]*))(\.[0-9]+)?((e|E)(+|-)?[0-9]+)?выходные данные JSON являются числом).

Например, ‘badge : ‘#(name)’ становится ‘badge’ : 40 (а не ‘40‘).

‘text’ or “text”

Литерал. Литералы содержат произвольный текст, заключенный в одинарные или двойные кавычки.

expr1 + expr2

Оператор объединения, объединяющий два выражения в одну строку.

Выражения могут быть любого из перечисленных выше видов.

При использовании конкатенации все выражение должно быть заключено в {}. Например, {$(prop) + ‘ - ’ + $(prop2)}.