Блог

В статье, описывающей управление регистрацией, говорится, что:

Ниже приведены некоторые ключевые преимущества использования установок:

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

Что именно это означает? Я предполагаю, что это не означает, что установки имеют ‘CreateOrUpdate’ в отличие от регистраций, потому что там также существует аналогичный метод — ‘CreateOrUpdateRegistrationAsync’.

Предположим, что я создал две установки с разными идентификаторами установки, но одинаковым дескриптором PNS ( pushChannel свойство) и идентичным тегом foo, присутствующим в обеих установках. Я собираюсь отправить уведомление с помощью SendTemplateNotificationAsync метода с использованием тега ‘foo’, чтобы выбрать цель моего уведомления.

Это будет соответствовать обеим моим установкам, потому что они оба содержат тег ‘foo’ и оба имеют одинаковый дескриптор PNS. Будет ли устройство получать два уведомления, или Azure собирается предотвратить доставку дубликатов в этом случае?

В той же статье, на которую я ссылался, образцы кода проверяют существующие регистрации с помощью дескриптора PNS, который должен быть зарегистрирован:

 // make sure there are no existing registrations for this push handle (used for iOS and Android)    
    string newRegistrationId = null;
    var registrations = await hub.GetRegistrationsByChannelAsync(pushChannel.Uri, 100);
  

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

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

Здесь installation — это термин, используемый для описания расширенной регистрации (в центре уведомлений Azure), чтобы связать PNS устройства с тегами и / или шаблонами. «Идемпотентность» здесь используется в отношении действия такого installation .
Это означает, что вы можете просто вызывать один и тот же код для этого типа регистрации каждый раз, когда ваше приложение запускается или выводится на передний план, не беспокоясь об обработке изменений в PNS или предыдущих состояниях регистрации в Центре уведомлений.
Это хорошо, потому что классическая registration модель может привести к дублированию регистраций для одного и того же устройства и пользователя в центре уведомлений. Installation модель этого не делает.

Вопрос Что произойдет, если у вас есть одно PNS, назначенное нескольким регистрациям с одним и тем же тегом в центре уведомлений, и вы пытаетесь отправить уведомление, ориентируясь на тег?
A. Azure Notification Hub имеет логику дедупликации, которая предотвращает отправку дублирующихся уведомлений.

Вопрос Можете ли вы принудительно использовать несколько уведомлений (для одного и того же тега) каким-либо образом, если у вас есть несколько приложений, но один центр уведомлений?
A. Вы можете, если сможете получить несколько токенов устройства. Однако в случае iOS, поскольку APNS выдает только один действительный токен устройства одновременно, это будет невозможно. Кроме того, приложения iOS имеют свой собственный идентификатор пакета и, следовательно, свой собственный push-сертификат. Кроме того, центры уведомлений не поддерживают несколько сертификатов. Но в случае Android вы можете принудительно выполнить это, если используете registration модель и используете более старые регистрационные идентификаторы GCM, поскольку они часто обновляются и срок их действия истекает не так легко.

Надеюсь, это поможет! Приветствия!