Push notifikácie: čo znamená odoslanie, doručenie a prečítanie

Oddeľte prijatie správy od jej prečítania

Obec zverejní oznam o zmene termínu zberu a server odošle push správu. V administrácii sa objaví úspešný výsledok. Časť telefónov je bez signálu, niektorí obyvatelia vypínajú notifikácie a ďalší upozornenie uvidia až po návrate z práce. Ak administrácia označí všetkých ako informovaných, vytvorí predstavu, ktorú systém nedokáže doložiť. Technická odpoveď poskytovateľa a správanie človeka sú rozdielne udalosti.

Firebase výslovne rozlišuje prijatie požiadavky od doručenia do zariadenia. Aj reporty o doručení majú vlastné pokrytie a obmedzenia. V aplikácii preto používame oddelené stavy: naplánované odoslanie, prijaté poskytovateľom, zaznamenané aplikáciou, otvorené a prípadne potvrdené človekom. Posledné tri označíme iba tam, kde na ne máme zodpovedajúcu udalosť. Chýbajúca udalosť neznamená automaticky, že človek oznam nevidel.

Oznam musí existovať aj bez push správy

Trvalý oznam uložíme na serveri s ID, verziou, publikovaním a prípadným časom skončenia platnosti. Push prenesie upozornenie a identifikátor, podľa ktorého aplikácia načíta aktuálny detail. Po otvorení zoznamu aplikácia overí novšie oznamy aj vtedy, keď nijaký push neprišiel. Telefón tak po výpadku nájde obsah a opraví rozdiel medzi uloženými dátami a serverom.

Záznam oznamu a úlohu na jeho rozoslanie možno vytvoriť v spoločnej transakcii pomocou serverového outboxu. Pracovník frontu potom odosiela jednotlivé pokusy a eviduje výsledky poskytovateľa. Toto je návrh našej modelovej architektúry; push služby samy nepredstavujú trvalý front všetkých obchodných udalostí. Pri požiadavke na výslovné potvrdenie vytvoríme osobitný proces v aplikácii. Pri nedostatku dát vrátime neznámy stav namiesto vymysleného potvrdenia.

Životnosť správy odvoďte od obsahu

FCM umožňuje nastaviť TTL; pri hodnote nula zahodí správu, ktorú nevie doručiť okamžite. Collapse key môže nahradiť staršiu čakajúcu správu novšou. Na Apple platformách sa používa apns-expiration, pričom APNs sa snaží rešpektovať expiráciu bez absolútnej garancie. Konkrétne hodnoty preto odvodíme od situácie a aktuálneho času na serveri.

Pozvánka na dnešné podujatie má inú životnosť než informácia o novom dokumente. Ak oznam stratí platnosť, aplikácia po otvorení ukáže aktuálny stav aj v prípade oneskoreného upozornenia. Spájanie správ je vhodné pre signál, že sa zmenil zoznam, pretože aplikácia stiahne všetky zmeny. Pre jednotlivé podania, ktoré používateľ potrebuje samostatne sledovať, uchováme vlastnú históriu a rozmyslíme, či možno upozornenia zlúčiť bez straty významu.

{
  "message": {
    "token": "<registration-token>",
    "data": {
      "type": "notices-changed",
      "noticeId": "notice-84",
      "version": "3"
    },
    "android": {
      "ttl": "3600s",
      "collapse_key": "notices"
    },
    "apns": {
      "headers": {
        "apns-push-type": "background",
        "apns-priority": "5",
        "apns-expiration": "<future-unix-seconds>"
      },
      "payload": {
        "aps": { "content-available": 1 }
      }
    }
  }
}

Tiché aktualizácie majú obmedzenia operačného systému

Tichý background push na iOS nevytvorí viditeľné upozornenie. Apple môže jeho doručenie odložiť alebo obmedziť a jeho doručenie negarantuje. Ukážkový payload preto slúži ako podnet na obnovu dát, nie ako spôsob spoľahlivého rozosielania viditeľných oznámení. Pre upozornenie človeka navrhneme odlišný alert payload a zodpovedajúce nastavenia platformy.

Aktualizáciu rozdelíme na malé kroky, ktoré možno zopakovať. Po prebudení aplikácia overí poslednú uloženú verziu a podľa potreby načíta zmeny. Nemusí stiahnuť celé fotografie, archív a ďalšie podklady v jednom behu. Rovnaký postup používa po otvorení aplikácie. Pri návrhu si tiež určíme, čo má používateľ vidieť pred dokončením obnovy: uložený obsah s časom aktualizácie alebo krátky stav načítavania pri detaile, ktorý v pamäti ešte nie je.

Token identifikuje inštaláciu, nie trvalý kontakt na človeka

Registrácie zariadení sa môžu meniť a poskytovateľ môže oznámiť, že daná registrácia už nie je platná. Server preto eviduje aktuálny údaj od aplikácie a čas poslednej aktualizácie. Užitočný model zahŕňa vlastné ID inštalácie, platformu, prostredie, väzbu na účet a nastavené odbery. Jeden človek môže používať viac zariadení a na jednom zariadení sa môžu vystriedať rôzni používatelia.

Pri odhlásení odstránime väzbu osobných odberov, nie nevyhnutne anonymný odber verejných oznamov. Pri prihlásení ju obnovíme až podľa overenej identity. Aplikácia nesmie rozhodovať o prístupe k osobnému detailu iba podľa toho, že dostala push. Server kontroluje oprávnenie pri načítaní. Do textu na zamknutej obrazovke nevkladáme citlivý obsah, ktorý používateľ nechce sprístupniť ďalšiemu človeku v blízkosti telefónu.

Rozlišujte chyby, ktoré treba zopakovať

Poskytovateľ môže odmietnuť chybný payload, nesprávne prostredie, neplatné poverenia alebo registráciu. Tieto výsledky vyžadujú rozdielny zásah. Chybu formátu neposielame znova bez zmeny; pri výpadku poskytovateľa použijeme dohodnuté opakovanie s odstupom. Pri potvrdenej neplatnej registrácii prestaneme daný cieľ používať. Samotná všeobecná chyba požiadavky nestačí na vymazanie registrácie.

Každý pokus spojíme s ID oznamu, ID inštalácie a interným ID odoslania. Pri opakovaní sa môže upozornenie objaviť viackrát, preto klient pri ukladaní udalosti porovná ID a verziu. Logy majú obsahovať výsledok a čas, nie kópiu všetkých osobných údajov alebo celé registračné tokeny. Rozsah uchovania dohodneme podľa prevádzkového účelu a prístup k diagnostike obmedzíme na osoby, ktoré riešia konkrétne problémy.

Meranie potrebuje jasný menovateľ

Počet prijatých požiadaviek, zariadení s aktívnym odberom a otvorení detailu môže viesť k trom rôznym percentám. Pri každom grafe preto uvedieme, ktoré udalosti porovnávame a v akom časovom okne. Firebase upozorňuje, že jeho metriky nepokrývajú všetky scenáre. Vlastná telemetria z aplikácie tiež chýba pri offline zariadeniach alebo sa prenesie neskôr.

Ak udalosť pošleme až pri ďalšom spustení, odlíšime čas vzniku od času doručenia do analytiky. Otvorenie z push odkazu rozlíšime od otvorenia zo zoznamu, inak výsledok pripíšeme nesprávnemu kanálu. Pred sledovaním ďalších udalostí si zodpovieme, aké rozhodnutie z údajov urobíme. Na diagnostiku oneskorení môže stačiť malý súbor prevádzkových udalostí bez detailného sledovania všetkých pohybov človeka.

Overte nedoručenie, expiráciu aj zmenu používateľa

Testy na jednom odomknutom telefóne s Wi-Fi overia iba ľahký priebeh. Testovací plán musí zahŕňať reálne iOS a Android zariadenia, rôzne nastavenia upozornení a oddelené produkčné a testovacie registrácie. Kritérium úspechu je správanie konkrétnej funkcie, nie iba úspešný HTTP výsledok. Nasledujúce prípady opisujú navrhnuté kontroly, bez tvrdenia o meraniach nasadených aplikácií.

• Telefón sa pripojí po skončení podujatia: aplikácia ukáže aktuálny detail a oneskorená správa nevytvorí platnú pozvánku.
• Používateľ vypne notifikácie: oznam zostane dostupný v zozname bez falošného záznamu o prečítaní.
• Tichý push nepríde: otvorenie aplikácie načíta chýbajúce zmeny rovnakým synchronizačným postupom.
• Server zopakuje ten istý pokus: lokálna história obsahuje jednu položku pre rovnaké ID a verziu.
• Používateľ sa odhlási a prihlási iný účet: osobné odbery a detail sa riadia novou identitou.
• Poskytovateľ odmietne registráciu alebo poverenie: systém rozlíši zrušenie cieľa od chyby serverového nastavenia.

Od témy ku konkrétnemu riešeniu.

Súvisiaca realizácia: Obec Smolenice