Особливості Push повідомлень

розсилки
Пуш повідомлення є чудовим механізмом, доступним для всіх розробників мобільних (і не тільки) додатків. За допомогою таких повідомлень можна розповідати користувачам про настання важливих подій, даючи можливість максимально оперативно відреагувати, навіть якщо програма не запущена. Крім того, подібний підхід дозволяє привернути додаткову увагу до продукту. У цій статті ми розповімо, які особливості ми виявили в процесі реалізації такого роду функціональності у великих проектах, а також надамо набір рекомендацій.

Насамперед варто відзначити, що сучасні сервіси працюють на безлічі платформ, тому відразу варто закладатись на використання:

  • Apple Push Notifications Service - APNS
  • Google Cloud Messaging - GCM
  • HTML5 WebSocket та Comet для реалізації повідомлень у браузері

Приймаючи рішення про використання APNS і GCM, варто враховувати принципові технічні особливості їх використання: відсутність гарантій доставки повідомлень, відсутність зручних систем логування та статистики надісланих та отриманих повідомлень, обмеження на розмір повідомлень.

Досвід показує, що незважаючи на відсутність гарантій, зазначені сервіси дуже стабільні, мають високу продуктивність і доставляють повідомлення практично моментально (за кілька секунд). Тому в більшості випадків використання APNS і GCM - це саме те, що вам потрібно. Якщо ж йдеться про повідомлення, які повинні доставлятися зі 100% ймовірністю та з гарантованою швидкістю доставки, то швидше за все варто потурбуватися про побудову своєї інфраструктури доставки повідомлень.

Процес інтеграції з сервісами доставки повідомлень досить простий і добре описаний: документація по APNS тадокументація з GCM. Далі ми розповімо про основні спостереження та дамо деякі рекомендації.

acceptchecksnow.com

  • Для тестового (sandbox) середовища потрібно згенерувати окремі сертифікати. Теорети користувачів також можуть відрізнятися для кожної програми, сертифіката і середовища. Не плутайте сертифікати розсилки токенів і не змішуйте між собою токени з різних програм та різних середовищ.
  • Зазвичай сповіщення надсилаються в асинхронному режимі, не чекаючи відповіді від сервера APNS. У разі помилки в повідомленні сервер просто розриває з'єднання. Це зроблено для того, щоб максимально прискорити доставку повідомлень. Але в тому випадку, коли вам необхідно зрозуміти причину помилки, може бути корисним особливий формат повідомлення з увімкненим прапором “error response”. У цьому випадку кожне повідомлення можна позначити унікальним ідентифікатором та отримати код помилки, який відповідає цьому повідомленню.

    • Процес доставки повідомлень на сервері

    Якщо передбачається, що сервіс розсилатиме досить велику кількість повідомлень на різні пристрої (iOS, Android) а також у браузери, так чи інакше виникає питання можливості розпаралелювання процесу розсилки. З досвіду можна виділити три етапи підготовки та розсилки повідомлень кожен з яких паралельно краще чи гірше залежно від логіки сервісу.

    Огляд готових рішень для роботи з push-повідомленнями

    Будь-яке з готових рішень, про які йтиметься, спрощує лише взаємодію із зовнішнім сервісом. З цього випливає, що процес внесення push-повідомлень у будь-який проект є досить трудомістким, тому що перший і другий етап роботи з повідомленнями завжди доведеться реалізовувати самостійно.

    Будь-яке досить серйозне рішенняроботи з повідомленнями має обгортати сам сервіс, позбавляючи розробника необхідності розбиратися в тонкощах взаємодії з ним, а також, що більш важливо, надавати можливості побудови розподіленої розсилки. Тому, якщо якесь абстрактне рішення, не відповідає цим двом критеріям, то його всерйоз розглядати не варто.

    На даний момент є досить багато готових сервісів для розсилки повідомлення на iOS пристрої, і практично немає рішень для сервісу GCM. Однак, ця проблема компенсується тим, що роботи з GCM набагато простіше для розробника, тому що сама взаємодія з сервісом зводиться до звичайних запитів POST у випадку з GCM, в той час як сервіс APNS заснований на перманентному сокеті.

    Найцікавішим рішенням для PHP зараз є бібліотека apns-php. Бібліотека надає можливості роботи з повідомленнями в об'єктно-орієнтованому стилі, а також містить шаблон для багатопотокового демона. Для організації черги повідомлень при багатопотоковій розсилці використовується механізм shared memory.

    Для python є pyapns. На відміну від apns-php, pyapns є сервісом, який запускається як сервер під управлінням twisted і вся взаємодія з ним ведеться через мережу. Передбачається, що безліч розсилаючих сервісів знаходиться за проксі-балансувальником, що дозволяє будувати систему розсилки, що горизонтально масштабується. У pyapns вже включені клієнти для роботи з ним з python та ruby. Враховуючи роботу pyapns як окремого сервісу, можливе написання клієнта для будь-якої мови, у тому числі PHP.

    На жаль, не можна сказати, що для сервісу GCM доступна така ж кількість готових рішень для розсилки. В основному зустрічаються примітивні обгортки для різних мов, які до деякоїступеня приховують роботи із сервісом. Однак, як уже говорилося вище, сам процес взаємодії з GCM простіше ніж з APNS, тому написання власної паралельної розсилки не повинно скласти великої праці.

    Для розробки push-повідомлень під web завжди є два сценарії: або користуватися стороннім сервісом (http://www.webdistortion.com/2012/02/02/real-time-push/), або повністю реалізовувати все самостійно. За самостійної реалізації основними компонентами системи будуть:

    • Сокет-сервер. Для реалізації добре підходить Node.js, проте якщо існує практика написання сокет-сервера на основній мові проекту (наприклад python), то краще використовувати цю можливість, і не додавати в стек додаткові технології.
    • Черга повідомлень pubsub (publish subscribe). Для цього завдання добре підходить Redis.
    • Клієнтський модуль для роботи з websocket Javascript.