Управление регистрацией

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

Что такое регистрация устройств

Регистрация — это вложенная сущность концентратора уведомлений и связывает дескриптор PNS устройства (дескриптор службы уведомлений платформы, например ChannelURI, токен устройства, GCM registrationId) с тегами и, возможно, шаблоном. Теги используются для направления уведомлений правильному набору маркеров устройств. Дополнительные сведения см. в статье Маршрутизация и выражения тегов. Шаблоны используются для преобразований в рамках регистрации. Дополнительные сведения см. в статье Шаблоны.

Важно отметить, что регистрации являются временными. Аналогично дескрипторам PNS, которые они содержат, срок действия регистрации истекает. Вы можете задать время, необходимое для регистрации в Центре уведомлений, не более 90 дней. Это ограничение означает, что они должны периодически обновляться, а также что они не должны быть единственным хранилищем важных сведений. Это автоматическое истечение срока действия также упрощает очистку при удалении мобильного приложения.

Регистрация должна содержать последний дескриптор PNS для каждого устройства или канала. Так как дескриптора PNS можно получить только в клиентском приложении на устройстве, один из способов управления регистрацией находится непосредственно в этом клиентском приложении. С другой стороны, рекомендации по безопасности и бизнес-логика, связанные с тегами, могут потребовать управления регистрацией в серверной части приложения. В следующем разделе описываются эти два подхода.

Управление регистрацией с устройства

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

Сначала устройство извлекает маркер PNS из службы PNS, а затем напрямую регистрируется в центре уведомлений. После успешной регистрации серверная часть приложения может отправить уведомление для этой регистрации. Дополнительные сведения об отправке уведомлений см. в статье Маршрутизация и выражения тегов.

Обратите внимание, что в этом случае для доступа к своим центрам уведомлений с устройства будут использоваться только права прослушивания. Дополнительные сведения см. в статье Безопасность.

Следующий код регистрирует устройство с помощью ссылок API Центров уведомлений:

await hub.RegisterNativeAsync(channelUri, tags);

[hub registerNativeWithDeviceToken:deviceToken tags:nil completion:^(NSError* error) {
    if (error != nil) {
        NSLog(@"Error registering for notifications: %@", error);
    }
}];

hub.register(regid, tags);

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

Для регистрации с устройства можно также использовать REST API. Дополнительные сведения см. в разделе "Использование интерфейса REST Центров уведомлений".

В следующих руководствах по сценариям приведены пошаговые инструкции по регистрации из клиента:

• начало работы с центрами уведомлений

• Критические новости

Шаблоны

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

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

Важно!

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

Следующий код регистрирует устройство с помощью ссылок API Центров уведомлений:

await hub.RegisterTemplateAsync(channelUri, template, templateName, tags);

[hub registerTemplateWithDeviceToken:deviceToken name:templateName jsonBodyTemplate: template expiryTemplate:nil tags:nil completion:^(NSError* error) {
    if (error != nil) {
        NSLog(@"Error registering for notifications: %@", error);
    }
}];

hub.registerTemplate(regId, templateName, template, tags);

Обратите внимание, что каждый вызов регистрации предоставляет в дополнение к дескриптору PNS и необязательному набору тегов, шаблону для текста уведомления и имени шаблона. Кроме того, каждая платформа может иметь дополнительные свойства, которые являются частью шаблона. В случае Windows Store (с использованием WNS) и Windows Phone 8 (с помощью MPNS) дополнительный набор заголовков может быть частью шаблона. Для имени точки доступа (APN) в свойстве окончания срока действия можно задать фиксированное значение или связать его с выражением шаблона.

Инструкции по изменению этих полей шаблона см. в справочниках по API или REST API центров уведомлений.

Вспомогательные плитки для приложений из Магазина Windows

Для клиентских приложений из Магазина Windows отправка уведомлений во вспомогательные плитки выполняется аналогично отправке уведомлений в основные плитки. Поддерживаются как собственные, так и шаблонные регистрации. Единственное отличие заключается в том, что вторичные плитки имеют другой ChannelUri, который пакет SDK в клиентском приложении обрабатывает прозрачно.

На высоком уровне все сведения, приведенные в предыдущих разделах, работают со вторичными плитками, вызывая соответствующие методы объектов, предоставляемых свойством словаря Microsoft.WindowsAzure.Messaging.NotificationHub.SecondaryTiles. Вот несколько примеров.

await hub.SecondaryTiles["myTileId"].RegisterNativeAsync(new string[] {"Yankees"});
await hub.SecondaryTiles["myTileId"].RegisterTemplateAsync(buildToastTemplate(), "toastTemplate", new string[] {"RedSox"});

Словарь SecondaryTiles использует тот же идентификатор TileId, который используется для создания объекта SecondaryTiles в приложении магазина Windows.

Как и в случае с основным ChannelUri, идентификаторы ChannelUri вспомогательных плиток можно изменить в любой момент. Чтобы сохранить регистрацию клиентских приложений в центре уведомлений, устройство должно обновить их с помощью текущего ChannelUris вторичных плиток.

Примечание

Вторичные плитки можно удалить, если приложение неактивно. Соответствующие регистрации не будут приводить к отправке уведомлений и будут автоматически удалены центрами уведомлений.

Недостатки регистрации с устройства

Регистрация с устройства является самым простым методом, но имеет некоторые недостатки.

Первый недостатком является то, что клиентское приложение может обновлять свои теги, только когда оно активно. Например, если у пользователя есть два устройства, которые регистрируют теги, связанные с спортивными командами, когда первое устройство регистрируется для дополнительного тега (например, Seahawks), второе устройство не будет получать уведомления о Seahawks, пока приложение на втором устройстве не будет выполнено во второй раз. В целом, если на теги влияют сразу несколько устройств, рекомендуется управлять тегами из серверной части.

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

Управление регистрацией из серверной части приложения

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

Преимущества управления регистрацией из серверной части — это возможность изменять теги на регистрацию, даже если соответствующее приложение на устройстве неактивно, а также проверка подлинности клиентского приложения перед добавлением тега в регистрацию.

Из серверной части приложения с регистрациями можно выполнять основные операции CRUDS. Пример:

var hub = NotificationHubClient.CreateClientFromConnectionString("{connectionString}", "hubName");
            
// create a registration description object of the correct type, e.g.
var reg = new WindowsRegistrationDescription(channelUri, tags);

// Create
await hub.CreateRegistrationAsync(reg);

// Get by id
var r = await hub.GetRegistrationAsync<RegistrationDescription>("id");

// update
r.Tags.Add("myTag");

// update on hub
await hub.UpdateRegistrationAsync(r);

// delete
await hub.DeleteRegistrationAsync(r);

Вы также можете использовать узлы или REST API.

Важно!

Серверная часть должна обеспечивать параллельность обновлений регистраций. Служебная шина предоставляет управление оптимистичным параллелизмом для управления регистрациями. На уровне HTTP это реализуется с использованием ETag для операций управления регистрацией. Эта функция автоматически используется в пакетах Microsoft SDK, которые выдают исключение, если обновление отклоняется по причинам параллелизма. Серверная часть приложения отвечает за обработку этих исключений и перезапуск обновления в случае необходимости.

Дополнительные ресурсы

В следующих руководствах по сценариям приведены пошаговые инструкции по регистрации из серверной части приложения:

• Использование тегов для отправки уведомлений пользователям, прошедшим проверку подлинности

• Использование шаблонов для отправки кроссплатформенных уведомлений пользователям, прошедшим проверку подлинности