Комментарии 9
Учитывая, что сервер разрывает соединение при отправке ошибочного токена, отправлять 10тыс.+ сообщений как-то странно.
Сервер разрывает соединение не при отправке ошибочного токена, а при ошибке в формате сообщения. И, по опыту, это не такой частый случай. В случае ошибки можно сохранить последнее отправленное сообщение и после исправления продолжить с того же места. А почему нужно отправлять сразу много я написал в статье. Мне пришлось работать с базой 50k+ токенов и если отправлять небольшими порциями, можно ставить крест на этом сервисе.
«Особенность номер 2» называется Enhanced binary interface.
«Особенность номер 3» называется Feedback service
«Особенность номер 7» подводных камней там еще больше… *мрачно*
«Особенность номер 3» называется Feedback service
«Особенность номер 7» подводных камней там еще больше… *мрачно*
Я достаточно активно работаю со всеми пуш провайдерами: apple, google, win, blackberry, даже, прости господи, nokia.
Из всех них, общение с apns дается сложнее всего. По сравнению с другими очень много неудобств:
— Нельзя узнать статус конкретного сообщения.
— 255 байт на все сообщение — это же прошлый век. Я хочу передавать больше данных в приложение
— Разрывы соединений просто разрывают мозг. Нельзя так делать. Это генерирует следующий пункт
— Нельзя после завершения отправки просто взять и закрыть соединение. Нужно еще сколько-то времени подождать. Вдруг APNS сам закроет соединение и нужно будет отправить что-то повторно?
У всех провайдеров есть какие-то ограничения и недостатки. Например у win и nokia нет возможности отправиьт пачку сообщений одним запросом. На каждый девайс отдельно. Blackberry любит говорить просто, что запрос принят на обработку. Статус сообщения получить можно, но геморно и за деньги, но это детали.
А ваш сервис куда-то выложен в паблик? Потыкаться можно?
Из всех них, общение с apns дается сложнее всего. По сравнению с другими очень много неудобств:
— Нельзя узнать статус конкретного сообщения.
— 255 байт на все сообщение — это же прошлый век. Я хочу передавать больше данных в приложение
— Разрывы соединений просто разрывают мозг. Нельзя так делать. Это генерирует следующий пункт
— Нельзя после завершения отправки просто взять и закрыть соединение. Нужно еще сколько-то времени подождать. Вдруг APNS сам закроет соединение и нужно будет отправить что-то повторно?
У всех провайдеров есть какие-то ограничения и недостатки. Например у win и nokia нет возможности отправиьт пачку сообщений одним запросом. На каждый девайс отдельно. Blackberry любит говорить просто, что запрос принят на обработку. Статус сообщения получить можно, но геморно и за деньги, но это детали.
А ваш сервис куда-то выложен в паблик? Потыкаться можно?
Я с пушами рабоатаю уже не один год (Под проектом AppRus). в результате, могу добавить:
1. 50к+ — Отправлять используя AMQP
2. Разрыв соединения — Да, есть, здесь уж ничего не поделаешь, но кто мешает наново заново открыть соединение?
3. Относительно длины 255 байт. Да, с этим они загнали, но вполне это можно решить передачей какого-то «ключа», а уже приложение при обработке пуша сделает то, что нужно.
4. Feedback — здесь очень сильно нужно переделить внимание. Согласно правилам Аппле, Вы обязательно должны опрашивать сервер на наличие «invalid devices», чтобы потом не слать пуши на эти токены. Если этот пункт будет проигнорирован, то аппле имеет полное право заблокировать приложение.
В общем, проблем и сильных подводных камней здесь вообще нету.
P.S. (Пиарюсь :) ):
Можете воспользоваться пакетом github.com/ZhukV/AppleApnPush для отправки пушей (Этот пакет уже проверен веременем + поддерживает отправку со списков: AMQP, Redis)
1. 50к+ — Отправлять используя AMQP
2. Разрыв соединения — Да, есть, здесь уж ничего не поделаешь, но кто мешает наново заново открыть соединение?
3. Относительно длины 255 байт. Да, с этим они загнали, но вполне это можно решить передачей какого-то «ключа», а уже приложение при обработке пуша сделает то, что нужно.
4. Feedback — здесь очень сильно нужно переделить внимание. Согласно правилам Аппле, Вы обязательно должны опрашивать сервер на наличие «invalid devices», чтобы потом не слать пуши на эти токены. Если этот пункт будет проигнорирован, то аппле имеет полное право заблокировать приложение.
В общем, проблем и сильных подводных камней здесь вообще нету.
P.S. (Пиарюсь :) ):
Можете воспользоваться пакетом github.com/ZhukV/AppleApnPush для отправки пушей (Этот пакет уже проверен веременем + поддерживает отправку со списков: AMQP, Redis)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Особенности работы с Apple push notification service