Регистрация для уведомлений нажатия

Для получения уведомлений нажатия приложение должно сначала зарегистрироваться в службе Apple Push Notification (APNs или «служба нажатия»). Регистрация имеет три этапа:

1. Приложение вызывает registerForRemoteNotificationTypes: метод UIApplication (на iOS) или NSApplication (на OS X).

2. Приложение реализует application:didRegisterForRemoteNotificationsWithDeviceToken: метод UIApplicationDelegate (iOS) или NSApplicationDelegate (OS X) для получения уникального маркера устройства, сгенерированного службой нажатия.

3. Приложение реализует application:didFailToRegisterForRemoteNotificationsWithError: метод UIApplicationDelegate (iOS) или NSApplicationDelegate (OS X) для получения ошибки, если регистрация перестала работать.

Приложение передает маркер устройства Вашему провайдеру как необъект, двоичное значение. Провайдер является Вашим сервером, поставляющим динамический контент Вашему приложению.

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

Следовавшая регистрация, но никакие полученные уведомления

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

Устройство или компьютер, возможно, потеряли свое постоянное соединение службе нажатия и не могут повторно соединиться. Попытайтесь выйти из приложения и повторно запустить его, чтобы видеть, завершается ли регистрация в следующий раз. (На iOS 4 и позже устройства, поддерживающие многозадачность, которую необходимо будет вызвать, выходят из приложения из списка recents.), Если регистрация не завершается, iOS или OS X были неспособны восстановить постоянное соединение. Можно диагностировать это, как описано в предыдущих двух разделах.

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

Некоторые полученные уведомления, но не все

При отправке многократных уведомлений тому же устройству или компьютеру в коротком периоде времени служба нажатия отправит только последний.

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

Как описано в Локальном Руководстве по программированию Уведомления Нажатия и, очередь QoS содержит единственное уведомление на приложение для каждого устройства или компьютер. Если служба получает другое уведомление, прежде чем тот в очереди будет отправлен, новое уведомление перезаписывает предыдущий.

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

Любое уведомление нажатия, не поставленное сразу, было поставлено в очередь для будущей повторной поставки, потому что Ваше устройство не было подключено к службе. «Сразу», конечно, потребности взять задержку для Вашего соединения во внимание. Отдаленные случаи были бы вне 60 секунд, поскольку APNs испытает таймаут в той точке.

Наблюдение сообщений о состоянии нажатия

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

$ echo -n "<your CFBundleIdentifier>" | openssl dgst -sha1

$ sudo defaults write /Library/Preferences/com.apple.apsd APSWriteLogs -bool TRUE

$ sudo defaults write /Library/Preferences/com.apple.apsd APSLogLevel -int 7

$ sudo killall apsd

Проблемы, соединяющиеся со службой нажатия

Одна возможность состоит в том, что Ваш сервер неспособен соединиться со службой нажатия. Это может означать, что у Вас нет цепочки сертификата необходимой для TLS/SSL для проверки соединения со службой. В дополнение к идентификационным данным SSL (сертификат и связанный закрытый ключ) создаваемый Задействованным Центром, необходимо также установить Поручать CA (2048) корневой сертификат на провайдере. Это позволяет TLS/SSL проверять полную цепочку свидетельства сервера APNs. Если необходимо получить этот корневой сертификат, можно загрузить его с сайта Энтраста. Также проверьте, что эти идентификационные данные установлены в корректном расположении для Вашего провайдера и что Ваш провайдер имеет разрешение считать их.

Можно протестировать квитирование TLS/SSL с помощью OpenSSL s_client команда, как это:

$ openssl s_client -connect gateway.sandbox.push.apple.com:2195 -cert YourSSLCertAndPrivateKey.pem -debug -showcerts -CAfile server-ca-cert.pem

где server-ca-cert.pem Поручать CA (2048) корневой сертификат.

Убедитесь, что идентификационные данные SSL и имя хоста являются корректными для среды нажатия, которую Вы тестируете. Можно сконфигурировать Приложение ID в Задействованном Центре отдельно песочницы и продуктивной среды, и Вы будете выпущены отдельные идентификационные данные для каждой среды.

Используя песочницу идентификационные данные SSL, чтобы попытаться соединиться с продуктивной средой возвратят ошибку как это:

CRITICAL | 14:48:40.304061 | Exception creating ssl connection to Apple: [Errno 1] _ssl.c:480: error:14094414:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate revoked

Одна общая ошибка OpenSSL verify error:num=20:unable to get local issuer certificate.

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

CAfile параметр s_client указывает доверенные корневые сертификаты для использования для проверки сертификата сервера. Доверяемым корневым сертификатом для серверов нажатия является Поручать CA (2048) корневой сертификат, упомянутый ранее.

Если Вы не можете даже открыть соединение с APNs, возможно Ваш TLS/сертихик¦т SSL APNs истек. Эти сертификаты допустимы в течение одного года, но производство сертификаты APNs может быть возобновлено в любое время.

Другая возможность состоит в том, что Вы соединились слишком много раз с APNs, и дальнейшие соединения были временно блокированы. Как документируется в Локальное Руководство по программированию Уведомления Нажатия и, разработчики, как ожидают, откроют соединение и оставят его открытым. Если соединение будет открыто и неоднократно закрываться, то APNs обработает его как атаку «отказ в обслуживании» и блокирует соединения сроком на время.

Если никакие попытки подключения не будут сделаны в течение приблизительно одного часа, этот временный блок истечет.

Еще одна возможность состоит в том, что существует доступ блокирующего брандмауэра к портам, используемым APNs. Посмотрите Диапазон IP-адреса, Используемый Службой Нажатия для подробных данных. Попытайтесь выполнить a telnet команда на Вашем сервере, чтобы видеть, может ли сервер достигнуть APNs, как это:

$ telnet 1-courier.push.apple.com 5223

$ telnet gateway.sandbox.push.apple.com 2195

$ telnet gateway.push.apple.com 2195

Обработка уродливых уведомлений

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

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

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

Пользователь, возможно, удалил Ваше приложение из их устройства или компьютера. Необходимо проверить службу обратной связи, по крайней мере, один раз в день на маркеры устройства, которые больше не активны.

Другие возможные проблемы могли бы отправлять полезную нагрузку дольше, чем 2 048 байтов, Ваша полезная нагрузка не могла бы быть отформатирована правильно, или возможно Ваш словарь JSON имеет неправильный синтаксис.

Случайное разъединение, в то время как Ваш провайдер неактивен, является ничем, чтобы касаться; просто восстановите соединение и продолжите. Если один из серверов нажатия снизится, то механизм выравнивания нагрузки прозрачно направит Ваше новое соединение с другим сервером, принимающим Вас подключение именем хоста а не статическим IP-адресом.

Используя улучшенный формат уведомления

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

Можно читать больше об улучшенном формате уведомления в Локальном Руководстве по программированию Уведомления Нажатия и.

Проблемы с Использованием службы обратной связи

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

Можно работать вокруг этого путем отъезда по крайней мере одного поддерживающего нажатие приложения на устройстве или компьютере для продолжения постоянного соединения. Для хранения постоянного соединения к продуктивной среде просто установите любое бесплатное поддерживающее нажатие приложение от App Store, и необходимо тогда быть в состоянии удалить приложение и видеть, что он появляется в службе обратной связи.

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

Продвиньте пропускную способность уведомления и проверку ошибок

Нет никаких прописных букв или пределов объема партии для использования APNs. Пресс-релиз iOS 6.1 утвердил, что APNs отправил более чем 4 триллиона уведомлений нажатия, так как это было установлено. В 2012 WWDC было объявлено, что APNs отправляет 7 миллиардов уведомлений ежедневно.

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

Вот то, как проверить на ошибки при использовании улучшенного формата уведомления. Продолжите писать, пока запись не перестанет работать. Если поток готов к записи снова, снова пошлите уведомление и продолжите идти. Если поток не готов к записи, посмотрите, доступен ли поток для чтения.

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

Как только все было отправлено, сделайте одну последнюю проверку на ошибочный ответ.

Это может требовать времени для выделенного соединения для пробиваний от APNs назад к серверу только из-за нормальной задержки. Возможно отправить более чем 500 уведомлений, прежде чем запись перестанет работать из-за отбрасываемого соединения. Приблизительно 1 700 записей уведомлений могут перестать работать просто, потому что канал полон, поэтому просто повторите в этом случае, как только поток готов к записи снова.

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

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

Ни одно из этого не является действительно определенным для APNs, он применяется к большей части программирования уровня сокета.

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

Диапазон IP-адреса, используемый службой нажатия

Продвиньте провайдеров, устройства на iOS, и компьютеры Mac часто находятся позади брандмауэров. Для отправки уведомлений необходимо будет позволить входящие и исходящие пакеты TCP по порту 2195. Для достижения службы обратной связи необходимо будет позволить входящие и исходящие пакеты TCP по порту 2196. Устройства и компьютеры, соединяющиеся со службой нажатия по Wi-Fi, должны будут позволить входящие и исходящие пакеты TCP по порту 5223.

Диапазон IP-адреса для службы нажатия подвержен изменениям; ожидание состоит в том, что провайдеры соединятся именем хоста, а не IP-адресом. Служба нажатия использует схему выравнивания нагрузки, приводящую к различному IP-адресу для того же имени хоста. Однако весь блок адреса 17.0.0.0/8 присваивается Apple, таким образом, можно указать, что управляет диапазон в брандмауэре.

Сброс Предупреждения Полномочий Уведомлений Нажатия на iOS

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

Если Вы хотите моделировать первоначальное выполнение своего приложения, можно оставить приложение удаленным в течение дня. Можно достигнуть последнего, фактически не ожидая день путем выполнения этих шагов:

1. Удалите свое приложение из устройства.

2. Выключите устройство полностью и возвратите его на.

3. Перейдите к Настройкам> Общий> Дата и Время и назначьте дату вперед день или больше.

4. Выключите устройство полностью снова и возвратите его на.

Просмотр Certificate Signing Request (CSR)

Часть конфигурирования Вашего Приложения ID для уведомлений нажатия создает сертификат, подписывая запрос или CSR. Иногда полезно смотреть на содержание CSR, который можно сделать с OpenSSL req команда:

$ openssl req -noout -text -in server.csr