Najprv musí aplikácia vedieť, kam správu poslať
Ešte pred samotným odoslaním musí aplikácia získať identifikátor konkrétnej inštalácie aplikácie na zariadení.
Pri Firebase Cloud Messaging sa používa Firebase Installation ID (FID) a systém registračných tokenov. Backend si tento identifikátor uloží, aby neskôr vedel správu zacieliť na konkrétnu inštaláciu. Identifikátor však nemusí zostať navždy rovnaký – môže sa zmeniť napríklad po preinštalovaní aplikácie alebo pri zmene zariadenia. Preto musí aplikácia počítať s jeho aktualizáciou.
Zjednodušene:
Používateľ nainštaluje aplikáciu → aplikácia sa zaregistruje → backend si uloží identifikátor → neskôr vie, kam správu poslať.
Dôležitú úlohu tu má aj samotný používateľ. Technická možnosť poslať push totiž ešte neznamená, že ho používateľ uvidí.
Na iOS musí aplikácia získať povolenie na zobrazovanie notifikácií, zvukov či badge. Používateľ môže toto povolenie odmietnuť alebo ho neskôr zmeniť v nastaveniach. Na Androide je od Androidu 13 pre bežné notifikácie potrebné runtime povolenie POST_NOTIFICATIONS.
Ak teda používateľ notifikácie nepovolil, všetko ostatné môže fungovať správne – a banner sa aj tak nezobrazí.
Čo sa stane po kliknutí na „Send“?
Predstavme si, že marketingový tím pripraví správu a klikne na Send.
Marketingový nástroj alebo administrácia odošle požiadavku na backend. Ten vytvorí správu s textom, cieľovým zariadením alebo segmentom a ďalšími nastaveniami.
Pri Firebase Cloud Messaging môže aplikácia odosielať správy cez vlastný server do FCM backendu, ktorý ich následne smeruje k zariadeniu.
Tu je dôležité rozlišovať medzi dvoma vecami:
„Message accepted“ ≠ „message delivered“.
Ak FCM požiadavku prijme, znamená to, že ju prijal na doručenie. Neznamená to, že už dorazila do telefónu.
Správa potom putuje cez správnu push službu
Ďalšia časť cesty závisí od platformy.
Pri Androide sa využíva Firebase Cloud Messaging (FCM). Pri Apple zariadeniach je kľúčovou službou Apple Push Notification service (APNs). FCM môže pri komunikácii s Apple zariadeniami využívať APNs ako platformovú transportnú vrstvu.
Zjednodušene môže cesta vyzerať napríklad takto:
Marketingový nástroj → backend → FCM → Android zariadenie
alebo:
Marketingový nástroj → backend → FCM → APNs → iPhone
Push notifikácia preto nie je iba funkcia aplikácie. Je to komunikácia medzi viacerými systémami.
A čo keď je telefón offline?
Telefón nemusí byť v momente odoslania dostupný. Používateľ môže byť bez signálu, bez dát alebo môže byť zariadenie vypnuté.
Push systém preto môže správu určitý čas podržať a pokúsiť sa ju doručiť neskôr. Pri FCM je možné nastaviť aj životnosť správy – teda ako dlho má systém skúšať jej doručenie. Po uplynutí tejto doby môže správa expirovať.
Preto je dôležité rozlišovať medzi notifikáciou, ktorá je časovo citlivá, a správou, ktorej nevadí oneskorenie.
Ani online telefón nemusí znamenať okamžité zobrazenie
Doručenie môže ovplyvniť aj priorita správy a stav zariadenia.
FCM napríklad rozlišuje normal a high priority. Normálne správy môžu byť v určitých situáciách doručené neskôr, zatiaľ čo vysoká priorita je určená pre časovo citlivejší používateľsky viditeľný obsah.
Operačný systém zároveň pracuje s vlastnými pravidlami pre batériu, aplikácie bežiace na pozadí a ďalšie obmedzenia.
Push preto nie je garantovaný teleport správy z backendu na displej.
Keď správa dorazí, rozhoduje aj operačný systém
Keď správa dorazí na zariadenie, ešte stále záleží na tom, aký typ správy bol odoslaný a v akom stave je aplikácia.
FCM napríklad rozlišuje notification messages a data messages. Notification message môže systém zobraziť používateľovi, zatiaľ čo data message umožňuje aplikácii spracovať dáta vlastnou logikou.
Na iOS systém zároveň rešpektuje povolenia a nastavenia používateľa – napríklad alerty, zvuky či badge.
Preto medzi:
„server poslal správu“
a
„používateľ ju uvidel“
existuje ešte niekoľko rozhodnutí.
Push notifikácie sú navrhnuté tak, aby fungovali aj vtedy, keď aplikácia nie je práve otvorená. To však neznamená, že aplikácia môže na pozadí vykonať ľubovoľnú operáciu. Operačné systémy majú vlastné pravidlá pre background processing a spôsob spracovania prijatých správ.
Developer preto musí presne definovať, čo sa má po prijatí konkrétneho typu pushu stať.
Môže ísť iba o:
„Zobraz túto správu.“
Alebo o komplexnejší scenár:
„Prijmi dáta → aktualizuj stav → priprav obrazovku → zobraz notifikáciu → po kliknutí otvor konkrétnu časť aplikácie.“
Kliknutím sa cesta ešte nekončí
Používateľ nakoniec na notifikáciu klikne a aplikácia sa otvorí.
Push môže obsahovať údaje, ktoré aplikácii povedia, kam má používateľa nasmerovať – napríklad na konkrétny produkt, objednávku, chat alebo článok.
Preto je pri push notifikáciách dôležitý aj deep linking a správanie po kliknutí.
Dobrý push teda nie je iba:
„Máme novinku!“
Ide o celý reťazec:
relevantná správa → kliknutie → správna obrazovka v aplikácii.
Čo ak zariadenie už nie je platné?
V produkcii sa časom nahromadia neaktuálne registrácie.
Používateľ môže aplikáciu odinštalovať, prejsť na nové zariadenie alebo vymazať jej dáta. Identifikátor registrácie sa preto môže zmeniť alebo prestať byť platný.
Backend by mal neplatné a dlhodobo neaktívne registrácie priebežne odstraňovať. Inak bude zbytočne posielať požiadavky na neexistujúce ciele a skresľovať údaje o doručovaní.
Celá cesta push notifikácie v skratke
Keď si celý proces poskladáme, vyzerá približne takto:
Používateľ nainštaluje aplikáciu
↓
Aplikácia sa zaregistruje v push službe
↓
Backend si uloží identifikátor zariadenia/inštalácie
↓
Používateľ povolí notifikácie
↓
Marketingový nástroj alebo backend vytvorí správu
↓
Backend ju odošle do FCM alebo APNs
↓
Push služba ju nasmeruje k zariadeniu
↓
Operačný systém ju spracuje podľa svojich pravidiel
↓
Používateľ uvidí notifikáciu
↓
Po kliknutí aplikácia spracuje akciu a môže otvoriť konkrétnu obrazovku
A každý z týchto krokov môže byť miestom, kde sa niečo pokazí.
Push notifikácia nie je jedno tlačidlo
Keď používateľ povie:
„Tá notifikácia mi neprišla,“
developer by preto nemal skontrolovať iba text správy.
Treba preveriť napríklad:
- či bola aplikácia správne zaregistrovaná,
- či má aktuálny identifikátor,
- či používateľ povolil notifikácie,
- či backend správu správne vytvoril,
- či ju push služba prijala,
- či bolo zariadenie dostupné,
- aká bola nastavená priorita a životnosť správy,
- čo urobil operačný systém,
- a čo sa stalo po prijatí alebo kliknutí.
FCM zároveň poskytuje nástroje na sledovanie doručovania a diagnostiku, vrátane reportov v konzole a podrobnejších dát dostupných cez Data API a BigQuery.
Preto sa oplatí push notifikácie vnímať ako distribuovaný systém, nie ako tlačidlo „Send“.
Pre používateľa je to jeden banner na displeji.
Pre aplikáciu je to cesta cez servery, identifikátory, API, sieťové spojenia a pravidlá operačného systému.
A keď túto cestu poznáte, oveľa ľahšie pochopíte aj to, prečo push niekedy príde okamžite, inokedy neskôr – a prečo „odoslané“ ešte nemusí znamenať „doručené“.