1

В настоящее время я работаю над приложением, созданным в VS, с использованием проекта XAMAIN Unified IOS. одним из требований приложения является использование push-уведомлений. Проблема в том, что наше тестовое устройство/приложение регистрируется в первом случае без каких-либо проблем, мы можем видеть события регистрации на лазурных порталах и шину служебного обслуживания. Я также подтвердил первоначальную регистрацию с помощью приложения «Сервис-Bus Explorer» и функции проводника сервера в VS.Azure Notification Hub и Apple APNS Push Notifications unregistering devices

Проблема возникает при отправке тестового push-уведомления. По всем журналам у меня тоже есть доступ, сообщение успешно помещено в ящик APNS-сервера, и я не вижу никаких отказов, возвращаемых как часть запроса PNS. Однако как только это завершено, регистрация устройства будет удалена, и уведомление не поступит на тестовое устройство.

Мое понимание заключается в том, что концентратор приложения azure обрабатывает сами отказы PNS, чтобы убрать регистрацию устройств. Это само по себе не является ужасной идеей, но из-за отсутствия каротажа очень сложно определить основную причину. Я сделал нелепое количество googling для этого, и многие люди предлагают проблему с яблочными сертификатами, которые используются. Я удалил, воссоздал, подал в отставку, подтвердил, как сертификаты APNS, так и профили Provisioning до тех пор, пока не закончится комбинация. Ничто из этого не разрешило проблему.

Чтобы сделать проблему более запутанной, если я использую такую ​​услугу, как «http://pushtry.com» или «http://pushwatch.com», и загрузите сертификат и токен устройства, это позволит мне успешно нажать уведомление на устройство.

Не хватает ли чего-то очевидного? или это хаб абсурдно сложно настроить и отладить для APNS?

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

ответ

0

После многих человеческих часов и удачи, а не любого логического процесса, мы определили, что «Azure Notification Hubs» имеют встроенный валидатор для токена устройства Apple, который передан APNS. Поэтому, хотя есть несколько примеров и ответов, которые предлагают отправить токен устройства без пробелов или символов в центр уведомлений, это на самом деле неправильный подход. Маркер устройства всегда должен быть отправлен в «Azure Notification Hub» в состоянии «как есть», без каких-либо подтверждений из приложения Xamarin.IOS. Хотя это похоже на такую ​​простую вещь, которую можно упустить, в Google есть много противоречивых доказательств, и в документации Azure очень мало говорится о формате подаваемых жетонов устройства. В любом случае, надеюсь, это когда-нибудь поможет кому-то другому.

- Edit -

Устройство Токен формат от Apple: < XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX>

Формат что многие интернет-ресурсы предполагают, что это передается ступице уведомления как: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX без пробелов или '<' и '>'

Однако он должен быть передан в центр уведомлений, поскольку он получен от Apple.

+0

Привет, Я работаю над командой Notifications Hubs. Мы НЕ проверяем дескриптор и передаем его, как есть. Ваша проблема больше ориентирована на использование продукции/разработки.Каждый концентратор может быть объявлен prod или dev, и знает, как связаться с конечной точкой prod или dev в apns. Следующая комбинация должна работать: 1. prod/test unified apns cert, prod proing hub 2. prod/test unified apns cert, профиль профилей Dev, dev hub Можете ли вы подтвердить, что ни работали? –

+0

Концентраторы удаляют регистрацию после того, как apns возвращает недопустимую ошибку токена/истекшего токена, то есть, если токен устройства-разработчика передается конечной точке prod apns, конечная точка отклонит его и приведет к удалению устройства. То же самое и наоборот. –

+0

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