Я работаю в команде программируемого чата iOS SDK и надеюсь помочь с некоторыми из ваших вопросов выше.
Ссылки на registerWithToken:, а также инструкция для вызова его с параметром nil, когда токен отсутствует / известен, оба устарели, как вы заметили. Мы получим обновленную документацию и учебное пособие, чтобы отразить это - спасибо!
Сегодня handleNotification:completion: необязательно. Его цель - проанализировать часть userInfo полезной нагрузки и предоставить упомянутые вами обратные вызовы, чтобы помочь вашему пользователю узнать о произошедших событиях. Не вредно пропускать этот шаг сегодня, но в будущем, вероятно, эти обратные вызовы будут использоваться для обеспечения большей обратной связи о доставке уведомлений внутри программируемого чата, поэтому вы можете захотеть вернуться к реализации этого в будущем.
Когда ваши пользователи выходят из системы, рекомендуется вызывать метод deregisterWithNotificationToken:completion:, чтобы обеспечить их конфиденциальность. Если вы не отмените регистрацию токена, связанного с его идентификацией, они продолжат получать уведомления для этого идентификатора, даже если впоследствии они будут использовать токен доступа на этом устройстве с другим идентификатором в будущем. Механизмы для управления привязками уведомлений программно через наш REST API включены в нашу дорожную карту, но у меня нет даты выпуска, чтобы поделиться в это время.
Как упомянуто в документации push-уведомлений Apple, полезно не кэшировать токен устройства и не предполагать, что токены push-устройства никогда не изменятся, так как этот токен может измениться при будущих регистрациях. Точно так же рекомендуется передавать токен, данный Apple, в Programmable Chat всякий раз, когда вы получаете токен устройства от Apple, чтобы убедиться, что у нас есть самый современный токен для доступа к вашему пользовательскому устройству.
Счетчик значков, передаваемый APNS, сообщает количество каналов с непрочитанными сообщениями для данного пользователя. Есть несколько причин, которые приходят на ум, почему вы видите устаревший результат здесь. В своем клиенте вы вызываете setLastConsumedMessageIndex:completion: на TCHMessages (или один из связанных методов в том же классе), чтобы обновить непрочитанный статус на бэкэнде? После того, как это будет сделано, вы увидите, что через короткий промежуток времени появилось обновленное сообщение с обновленным количеством значков. Другая возможность, если у вас есть устаревшие привязки для других идентификаторов, которые все еще находятся на канале, с которым вы тестируете, которые не были отключены / не зарегистрированы. Обратите внимание, что пока приложение находится на переднем плане, вы сами отвечаете за обновление количества значков - iOS этого не сделает. Это единственное место, где вы можете убедиться, что звоните handleNotification:completion:, так как мы позвоним, если получим обновление значка. Вы также можете посмотреть на полезную нагрузку и сделать вызов, чтобы обновить количество значков по мере необходимости непосредственно в принимающем делегате в UIApplication. Один из способов проверить это - настроить новый канал и проверить сообщения с ним, обновляя горизонт потребления, когда это необходимо. Вы можете найти больше информации в документации по горизонту потребления . Ниже вы можете найти пример обновления счетчика значков в отклике на метод делегата Programmable Chat:
- (void)chatClient:(TwilioChatClient *)client notificationUpdatedBadgeCount:(NSUInteger)badgeCount {
[[UIApplication sharedApplication] setApplicationIconBadgeNumber:badgeCount];
}
Использование токенов аутентификации Apple вместо сертификатов - это то, что исследует наша команда по уведомлениям, но у нас нет даты, чтобы сообщить, когда поддержка будет отправлена в это время.
Пожалуйста, дайте мне знать, если я могу помочь в дальнейшем или я пропустил любой из ваших вопросов!
Спасибо,
Randy