Pull to refresh
Comments 9
Учитывая, что сервер разрывает соединение при отправке ошибочного токена, отправлять 10тыс.+ сообщений как-то странно.
Сервер разрывает соединение не при отправке ошибочного токена, а при ошибке в формате сообщения. И, по опыту, это не такой частый случай. В случае ошибки можно сохранить последнее отправленное сообщение и после исправления продолжить с того же места. А почему нужно отправлять сразу много я написал в статье. Мне пришлось работать с базой 50k+ токенов и если отправлять небольшими порциями, можно ставить крест на этом сервисе.
«Особенность номер 2» называется Enhanced binary interface.
«Особенность номер 3» называется Feedback service
«Особенность номер 7» подводных камней там еще больше… *мрачно*
Спасибо, но перед началом работы я изучил все существующие гемы. К сожалению, ни один не подошел. Кстати, тот что вы советуете реализован не лучшим образом и в нем есть как минимум 2 ошибки, о которых я писал.
Я достаточно активно работаю со всеми пуш провайдерами: apple, google, win, blackberry, даже, прости господи, nokia.
Из всех них, общение с 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)
Only those users with full accounts are able to leave comments. Log in, please.