Nejdříve musí aplikace vědět, kam zprávu poslat
Ještě před odesláním notifikace potřebuje aplikace identifikátor konkrétní instalace aplikace v zařízení.
U Firebase Cloud Messaging se používá Firebase Installation ID (FID) a systém registračních tokenů. Backend si tento identifikátor uloží, aby mohl později cílit zprávu na konkrétní instalaci aplikace. Identifikátor ale nemusí zůstat navždy stejný. Může se změnit například po přeinstalování aplikace nebo při přechodu na jiné zařízení. Aplikace proto musí umět tyto změny zpracovat.
Zjednodušeně:
Uživatel nainstaluje aplikaci → aplikace se zaregistruje → backend uloží identifikátor → později ví, kam zprávu poslat.
Důležitou roli zde má také samotný uživatel. To, že je technicky možné push notifikaci odeslat, ještě neznamená, že ji uživatel skutečně uvidí.
Na iOS musí aplikace získat povolení k zobrazování notifikací, zvuků nebo badge. Uživatel může toto povolení odmítnout nebo ho později změnit v nastavení systému. V Androidu je od verze Android 13 pro běžné notifikace potřeba runtime oprávnění POST_NOTIFICATIONS.
Pokud tedy uživatel notifikace nepovolil, všechno ostatní může fungovat správně – a banner se přesto nezobrazí.
Co se stane po kliknutí na „Send“?
Představme si, že marketingový tým připraví zprávu a klikne na Send.
Marketingový nástroj nebo administrace odešle požadavek na backend. Ten vytvoří zprávu s jejím obsahem, cílovým zařízením nebo segmentem uživatelů a dalšími nastaveními.
U Firebase Cloud Messaging může aplikace odesílat zprávy přes vlastní server do FCM backendu, který je následně směruje k zařízení.
Důležitý je přitom rozdíl mezi:
„Message accepted“ ≠ „message delivered“.
Pokud FCM požadavek přijme, znamená to, že zprávu přijal k doručení. Neznamená to, že už dorazila do telefonu.
Zpráva potom putuje přes správnou push službu
Další část cesty závisí na platformě.
Na Androidu se používá Firebase Cloud Messaging (FCM). U zařízení Apple je klíčovou službou Apple Push Notification service (APNs). Při komunikaci s Apple zařízeními může FCM využívat APNs jako platformní transportní vrstvu.
Zjednodušeně může cesta vypadat například takto:
Marketingový nástroj → backend → FCM → Android zařízení
nebo:
Marketingový nástroj → backend → FCM → APNs → iPhone
Push notifikace proto není jen funkcí aplikace. Jde o komunikaci mezi několika různými systémy.
Co když je telefon offline?
Telefon nemusí být v okamžiku odeslání dostupný. Uživatel může být bez signálu, bez datového připojení nebo může být zařízení jednoduše vypnuté.
Push systém proto může zprávu po určitou dobu podržet a pokusit se ji doručit později. U FCM lze nastavit také životnost zprávy – tedy jak dlouho se má systém pokoušet o její doručení. Po uplynutí této doby může zpráva expirovat.
Proto je důležité rozlišovat mezi notifikacemi, které jsou časově citlivé, a zprávami, u kterých nevadí určité zpoždění.
Ani online telefon nemusí znamenat okamžité zobrazení
Doručení může ovlivnit také priorita zprávy a stav zařízení.
FCM například rozlišuje normal a high priority. Zprávy s běžnou prioritou mohou být v určitých situacích doručeny později, zatímco vysoká priorita je určena pro časově citlivější obsah, který má být viditelný pro uživatele.
Operační systém zároveň používá vlastní pravidla týkající se baterie, aplikací běžících na pozadí a dalších omezení.
Push proto není garantovaný teleport zprávy z backendu na displej.
Jakmile zpráva dorazí, přichází na řadu operační systém
Když zpráva dorazí do zařízení, další chování závisí na tom, jaký typ zprávy byl odeslán a v jakém stavu se aplikace nachází.
FCM například rozlišuje notification messages a data messages. Notification message může systém zobrazit uživateli, zatímco data message umožňuje aplikaci zpracovat data vlastní logikou.
Na iOS systém zároveň respektuje oprávnění a nastavení uživatele – například upozornění, zvuky nebo badge.
Mezi:
„Server odeslal zprávu“
a
„Uživatel viděl notifikaci“
tak existuje ještě několik dalších rozhodnutí.
Push notifikace jsou navržené tak, aby fungovaly i tehdy, když aplikace není právě otevřená. To ale neznamená, že aplikace může na pozadí provádět libovolné operace. Operační systémy mají vlastní pravidla pro background processing a zpracování přijatých zpráv.
Vývojář proto musí přesně definovat, co se má po přijetí konkrétního typu push notifikace stát.
Může jít jednoduše o:
„Zobraz tuto zprávu.“
Nebo o komplexnější scénář:
„Přijmi data → aktualizuj stav → připrav obrazovku → zobraz notifikaci → po kliknutí otevři konkrétní část aplikace.“
Kliknutím cesta ještě nekončí
Uživatel nakonec na notifikaci klikne a aplikace se otevře.
Push může obsahovat informace, které aplikaci řeknou, kam má uživatele nasměrovat – například na konkrétní produkt, objednávku, chat nebo článek.
Proto jsou důležitou součástí implementace push notifikací také deep linking a chování po kliknutí.
Dobrý push tedy není jen:
„Máme novinku!“
Jde o celý řetězec:
relevantní zpráva → kliknutí → správná obrazovka v aplikaci.
Co když zařízení už není platné?
V produkční aplikaci se postupem času nahromadí neaktuální registrace.
Uživatel může aplikaci odinstalovat, přejít na nové zařízení nebo vymazat data aplikace. Registrační identifikátor se proto může změnit nebo přestat být platný.
Backend by měl neplatné a dlouhodobě neaktivní registrace pravidelně odstraňovat. Jinak bude zbytečně posílat požadavky na neexistující cíle a může zkreslovat údaje o doručování.
Celá cesta push notifikace
Když celý proces poskládáme dohromady, vypadá přibližně takto:
Uživatel nainstaluje aplikaci
↓
Aplikace se zaregistruje u push služby
↓
Backend uloží identifikátor zařízení/instalace
↓
Uživatel povolí notifikace
↓
Marketingový nástroj nebo backend vytvoří zprávu
↓
Backend ji odešle do FCM nebo APNs
↓
Push služba ji nasměruje k zařízení
↓
Operační systém ji zpracuje podle svých pravidel
↓
Uživatel uvidí notifikaci
↓
Po kliknutí aplikace zpracuje akci a může otevřít konkrétní obrazovku
A každý z těchto kroků může být místem, kde se něco pokazí.
Push notifikace není jen jedno tlačítko
Když uživatel řekne:
„Ta notifikace mi nepřišla,“
vývojář by proto neměl kontrolovat pouze samotnou zprávu.
Je potřeba ověřit například:
- zda byla aplikace správně zaregistrována,
- zda má aktuální identifikátor,
- zda uživatel povolil notifikace,
- zda backend zprávu správně vytvořil,
- zda ji push služba přijala,
- zda bylo zařízení dostupné,
- jaká byla nastavená priorita a životnost zprávy,
- co s ní udělal operační systém,
- a co se stalo po přijetí nebo kliknutí.
FCM zároveň nabízí nástroje pro sledování doručování a diagnostiku problémů, včetně reportů v konzoli a podrobnějších dat dostupných přes Data API a BigQuery.
Proto má smysl vnímat push notifikace jako distribuovaný systém, ne jen jako tlačítko „Send“.
Pro uživatele je to jeden banner na displeji.
Pro aplikaci je to cesta přes servery, identifikátory, API, síťová spojení a pravidla operačního systému.
A když této cestě rozumíte, mnohem snadněji pochopíte, proč push notifikace někdy dorazí okamžitě, jindy později – a proč „odesláno“ ještě nemusí znamenat „doručeno“.