Offline režim webovej aplikácie: práca v teréne bez signálu

Webová aplikácia môže fungovať aj tam, kde nie je signál – v pivnici, na stavbe, v sklade či na vidieku. Podmienkou je navrhnúť offline režim ako súčasť pracovného procesu, nie ako doplnok tesne pred spustením. Technicky ho tvorí service worker, ktorý uloží aplikáciu do zariadenia, lokálna databáza v prehliadači pre rozpracované záznamy a odchádzajúca fronta zmien, ktorú aplikácia po návrate pripojenia odošle na server.

O úspechu však rozhodujú pravidlá: aké dáta má človek v teréne so sebou, čo smie urobiť bez servera, ako dlho môžu neodoslané záznamy zostať v telefóne a čo sa stane, keď ten istý záznam medzitým zmení kancelária. Článok je určený majiteľom a manažérom firiem, ktorí plánujú aplikáciu pre servisných technikov, obhliadky, inventúry alebo revízie a zvažujú, ako má vyzerať offline režim webovej aplikácie.

Príklad: revízie kotlov v pivniciach bez signálu

Ilustračný príklad, firma je vymyslená. Servisná firma robí revízie plynových kotlov, často v kotolniach a pivniciach bez mobilného signálu. Technik dnes zapisuje zistenia na papier, večer ich prepisuje do systému a fotky posiela cez súkromný chat.

Cieľový stav: ráno na firemnej Wi-Fi si aplikácia stiahne denný plán, adresy, históriu zariadení a formuláre protokolov. Na mieste technik vyplní protokol, priloží fotky a zákazník sa podpíše na displeji. Záznam sa uloží v telefóne so stavom „Čaká na odoslanie“. Keď sa signál vráti, aplikácia ho odošle, server potvrdí prijatie a stav sa zmení na „Odoslané“. Ak kancelária medzitým zákazku zrušila, technik uvidí konflikt na vyriešenie, nie tichý prepis svojej práce.

Čo musí offline režim zvládnuť a čo nie

Prvé rozhodnutie nie je technické. Pri každej úlohe určite, či sa robí úplne offline, ako návrh, ktorý potvrdí server, alebo iba online. Všetko, čo potrebuje jeden autoritatívny stav – číselné rady faktúr, sklad, ceny –, nechajte na serveri.

Úloha	Offline	Prečo
Zobraziť denný plán a históriu zariadenia	Áno, z dát stiahnutých vopred	Technik potrebuje kontext aj bez signálu
Vyplniť protokol, priložiť fotky a podpis	Áno, uloží sa lokálne a odošle neskôr	Hlavný dôvod zavedenia offline režimu
Založiť novú zákazku na mieste	Áno, ako návrh s dočasným identifikátorom	Číslo zákazky pridelí až server
Vystaviť faktúru alebo rezervovať tovar	Nie, iba pripraviť podklady	Číselné rady a stav skladu riadi server
Zmeniť cenník alebo oprávnenia	Nie	Tieto dáta majú mať jediný zdroj pravdy

Každé „áno“ v tabuľke znamená vývoj a testovanie navyše. Do offline režimu preto patria len úlohy, ktoré sa bez signálu naozaj robia.

Technické stavebné kamene a ich limity

Service worker a uložená aplikácia

Service worker je skript, ktorý beží v samostatnom vlákne. Pri inštalácii môže uložiť stránky, štýly, skripty a obrázky aplikácie do lokálnej cache a potom zachytávať jej požiadavky – buď najprv z cache, alebo najprv zo siete s cache ako zálohou. Vhodná stratégia podľa sprievodcu MDN pre offline režim a prácu na pozadí závisí od konkrétnej aplikácie. Pre terénnu aplikáciu odporúčame samotné rozhranie aplikácie obsluhovať z cache s jasným verzovaním a dáta zákaziek držať v lokálnej databáze, ktorú aplikácia pri každom pripojení aktualizuje zo servera.

Lokálna databáza: IndexedDB, nie localStorage

localStorage ukladá iba textové páry kľúč – hodnota a podľa dokumentácie MDN o kvótach úložiska je obmedzené na 5 MiB pre jeden pôvod (origin). Na fotky a frontu zmien nestačí. Na väčšie štruktúrované dáta slúži IndexedDB, na súbory súkromný súborový systém pôvodu (OPFS).

Kvóty a vymazanie úložiska

Dáta sa štandardne ukladajú v režime „best-effort“, teda bez záruky trvalosti: zostanú, kým pôvod neprekročí kvótu, v zariadení je miesto a používateľ ich nevymaže. Keď miesto dochádza, prehliadač maže dáta najdlhšie nepoužívaných pôvodov – vždy všetky dáta pôvodu naraz, nie ich časť (MDN).

Kvóty sú vysoké, no nie sú zárukou. Prehliadače založené na Chromiu dovolia pôvodu až 60 % celkovej kapacity disku, Firefox v režime best-effort menšiu z hodnôt 10 % disku alebo 10 GiB a Safari od verzie 17 približne 60 % disku (MDN). Počíta sa však celková kapacita, nie voľné miesto, a podľa blogu WebKit o pravidlách úložiska ide o hornú hranicu bez garancie. Aplikácia preto musí zvládnuť chybu QuotaExceededError.

Safari pri zapnutej ochrane pred sledovaním naprieč webmi navyše vymaže dáta vytvorené skriptom, ak s webom používateľ počas posledných siedmich dní používania prehliadača neinteragoval. Pred vymazaním pri nedostatku miesta chráni perzistentné úložisko, o ktoré aplikácia požiada cez navigator.storage.persist(). Firefox sa používateľa opýta, Safari a väčšina prehliadačov na Chromiu rozhodnú automaticky podľa histórie interakcie a WebKit zohľadňuje aj to, či je web spustený z plochy. Podľa výskumu tímu Chrome, na ktorý odkazuje MDN, prehliadače dáta pravidelne navštevovaných webov mažú veľmi zriedka. Telefón však berte ako dočasnú vyrovnávaciu pamäť, nie ako miesto, kde majú firemné dáta zostať.

Stav pripojenia a synchronizácia na pozadí

Vlastnosť navigator.onLine nie je spoľahlivá: pripojenie k lokálnej sieti sa spravidla počíta ako online, aj keď sieť nemá prístup na internet. MDN preto odporúča podľa nej funkcie nevypínať, iba naznačiť, že používateľ je možno offline. Za odoslaný považujte len záznam, ktorého prijatie potvrdil server.

Background Synchronization API umožňuje odložiť odoslanie na service worker, kým nie je pripojenie stabilné. MDN ho však označuje ako funkciu s obmedzenou dostupnosťou a funguje iba v zabezpečenom kontexte (HTTPS). Požiadavku možno zaregistrovať len pri otvorenej aplikácii, prehliadač môže pokus zopakovať len obmedzený počet ráz a príliš dlhú operáciu ukončí, pričom ďalší pokus začne od začiatku (MDN). Synchronizácia na pozadí je teda bonus. Základom má byť odosielanie pri otvorení aplikácie, po obnovení spojenia a tlačidlom „Odoslať teraz“, po malých dávkach, ktoré sa dajú bezpečne zopakovať.

Postup zavedenia v siedmich krokoch

Zmapujte prácu v teréne. Zistite, kde a ako dlho ľudia nemajú signál, aké zariadenia používajú (firemné či vlastné, iPhone či Android) a koľko záznamov a fotiek denne vznikne.
Určite offline rozsah. Pre každú úlohu rozhodnite podľa tabuľky: úplne offline, návrh na potvrdenie alebo iba online.
Pripravte dátový model. Každý záznam dostane už v zariadení jedinečný identifikátor (napríklad UUID), verziu a stav synchronizácie. Server musí opakované odoslanie rozpoznať a nevytvoriť duplicitu.
Postavte odchádzajúcu frontu. Zmena sa najprv zapíše do lokálnej databázy a fronty, až potom sa odosiela – v poradí vzniku, po dávkach a s opakovaním. Fotky sa nahrávajú, až keď server prijal samotný záznam.
Ošetrite úložisko. Požiadajte o perzistentné úložisko, sledujte odhad využitia cez navigator.storage.estimate(), fotky pred uložením zmenšite na rozlíšenie, ktoré proces naozaj potrebuje, a po potvrdení servera lokálne kópie zmažte.
Ukážte stav synchronizácie. Pri každom zázname nech je vidieť, či čaká na odoslanie, bol odoslaný alebo má konflikt. Pred odhlásením musí aplikácia varovať a vypršané prihlásenie nesmie zastaviť prácu ani zmazať frontu.
Testujte v reálnych podmienkach. Vyskúšajte režim lietadlo, Wi-Fi bez internetu, zatvorenie aplikácie počas odosielania, plné úložisko a nasadenie novej verzie s neodoslanými dátami – na iPhone aj Androide.

Konflikty: kto vyhrá, keď sa záznam zmenil na dvoch miestach

Konflikt vzniká, keď technik upravuje záznam offline a niekto iný ho medzitým zmení na serveri. Pravidlo „posledný zápis vyhráva“ sa naprogramuje najľahšie, ale potichu zahodí prácu jedného z nich. Určte preto pravidlá vopred podľa typu dát.

Situácia	Odporúčané pravidlo	Kompromis
Technik doplní protokol, kancelária opraví kontakt zákazníka	Zlúčiť po poliach, každé pole má svojho vlastníka	Vlastníctvo polí treba presne určiť
Kancelária zákazku zrušila, technik ju medzitým vykonal	Neprepisovať, označiť konflikt na rozhodnutie dispečera	Niekto musí konflikty pravidelne riešiť
Dvaja technici upravili ten istý záznam	Prijať zmenu k aktuálnej verzii, druhú vrátiť ako konflikt	Druhý technik musí svoju zmenu skontrolovať
Fotky, poznámky a podpisy	Iba pridávať, nikdy neprepisovať	Viac uložených dát, ale nič sa nestratí
Cenníky a číselníky	Server je jediný zdroj, zariadenie ich iba číta	Offline môže byť v zariadení staršia verzia

Pri konflikte uchovajte obe verzie aj s autorom a časom. Inak sa spor o to, čo technik na mieste naozaj zapísal, nedá spätne vyriešiť.

Webová aplikácia (PWA) alebo natívna aplikácia?

Webová aplikácia má jeden kód pre všetky zariadenia, šíri sa odkazom a novú verziu nasadíte na server bez obchodov s aplikáciami. Prijímate však pravidlá prehliadača: úložisko v režime best-effort, ak prehliadač neudelí perzistentný režim, obmedzenú synchronizáciu na pozadí a service worker, ktorý prehliadač zastaví, keď to uzná za vhodné. Natívna aplikácia môže ukladať dáta vo vlastnom úložisku mimo prehliadača, takže sa jej tieto kvóty ani pravidlá mazania netýkajú. Znamená však vývoj pre iOS aj Android a distribúciu cez obchody s aplikáciami alebo cez správu firemných zariadení.

Webová aplikácia zvyčajne stačí, ak ide o formuláre, kontrolné zoznamy, fotky a podpisy a zariadenia sa aspoň raz denne pripoja.
Natívnu aplikáciu zvážte, ak ľudia pracujú bez spojenia celé dni, potrebujú v zariadení veľké objemy dát, napríklad mapy či videá, alebo sa dáta musia odoslať na pozadí bez otvorenia aplikácie.

Rozhodnite sa pred vývojom. Zmena prístupu v polovici projektu znamená prerábať úložisko a synchronizáciu, teda samotné jadro offline režimu.

Časté chyby

Offline režim až po spustení. Dátový model bez lokálnych identifikátorov a verzií sa dodatočne ťažko prerába.
Spoliehanie sa na navigator.onLine. Wi-Fi bez internetu sa tvári ako pripojenie a záznamy zostanú visieť.
Dáta v localStorage. Iba text a malá kapacita, na fotky a frontu sa nehodí.
Telefón ako jediná kópia. Neodoslané záznamy ležia v zariadení celé dni, hoci prehliadač môže dáta webu vymazať naraz.
Neviditeľný stav synchronizácie. Technik nevie, čo sa odoslalo, a odhlási sa alebo vymaže dáta prehliadača.
Nová verzia bez migrácie. Aktualizácia nevie prečítať neodoslanú frontu alebo ju zmaže.
Súkromné prehliadanie. Dáta sa po ukončení anonymného režimu zvyčajne vymažú, preto ho na prácu v teréne nepoužívajte.

Kontrolný zoznam pred nasadením

Tabuľka úloh (offline, návrh, iba online) je odsúhlasená terénom aj kanceláriou.
Každý záznam má lokálny jedinečný identifikátor, verziu a stav synchronizácie.
Server opakované odoslanie rozpozná a nevytvorí duplicitu.
Záznamy a fotky sú v IndexedDB alebo OPFS, nie v localStorage.
Aplikácia žiada o perzistentné úložisko, sleduje jeho využitie a zvládne plné úložisko.
Úspech odoslania potvrdzuje server, nie stav pripojenia v prehliadači.
Synchronizácia funguje aj bez Background Synchronization API.
Pravidlá konfliktov sú zapísané, otestované a niekto konflikty rieši.
Odhlásenie ani vypršané prihlásenie nezmaže neodoslané dáta bez varovania.
V zariadení sú iba dáta potrebné na aktuálne zákazky a telefóny majú zámok obrazovky.

Často kladené otázky

Funguje offline webová aplikácia aj na iPhone?

Áno. Safari od verzie 17 plne podporuje Storage API a webová aplikácia pridaná na plochu má rovnaké kvóty ako v prehliadači. WebKit pri žiadosti o perzistentné úložisko zohľadňuje, či je web otvorený ako aplikácia z plochy (WebKit). Odporúčame preto aplikáciu pridať na plochu a synchronizovať aspoň raz denne. V EÚ môžu na iOS od verzie 17.4 fungovať aj prehliadače s iným jadrom, ktoré majú vlastné pravidlá úložiska (MDN).

Koľko dát môže aplikácia v telefóne uložiť?

Závisí to od prehliadača a zariadenia. Horné hranice sú vysoké, no počítajú sa z celkovej kapacity disku, nie z voľného miesta, takže skutočným obmedzením môže byť zaplnený telefón. Aplikácia má sledovať odhad využitia, zmenšovať fotky a po potvrdení servera mazať lokálne kópie.

Čo sa stane, keď technik aplikáciu zatvorí pred odoslaním?

Záznamy uložené v IndexedDB zostanú v zariadení a aplikácia ich odošle pri ďalšom otvorení. Ak prehliadač podporuje Background Synchronization API a požiadavka sa zaregistrovala pri otvorenej aplikácii, môže ich odoslať aj po zatvorení. Funkcia však nie je dostupná všade a prehliadač obmedzuje počet aj trvanie pokusov, preto má technik vždy vidieť, čo ešte čaká na odoslanie.

Potrebujeme kvôli offline režimu natívnu aplikáciu?

Pri formulároch, fotkách a podpisoch s dennou synchronizáciou zvyčajne nie. Natívnu aplikáciu zvážte pri dňoch bez spojenia, veľkých objemoch dát v zariadení alebo pri potrebe odosielať dáta na pozadí. Rozhodnite sa ešte pred vývojom.

Ako začať

Ak chcete, aby vaši ľudia v teréne prestali prepisovať papiere a posielať fotky cez chat, začnite tabuľkou úloh a jedným skutočným pracovným dňom v teréne. Pozrite si, ako vyvíjame webové aplikácie na mieru, alebo nám napíšte cez kontakt. Pomôžeme vám určiť offline rozsah, navrhnúť synchronizáciu a pravidlá konfliktov a otestovať aplikáciu v podmienkach, v ktorých ju budete používať. Ak majú protokoly putovať ďalej do ERP alebo CRM, pripravíme aj API integráciu. Ďalšie praktické návody nájdete na našom blogu.

Zdroje

Kvóty úložiska a kritériá vymazania dát – MDN Web Docs (v angličtine)
Offline režim a práca na pozadí v progresívnych webových aplikáciách – MDN Web Docs (v angličtine)
Background Synchronization API – MDN Web Docs (v angličtine)
Vlastnosť navigator.onLine – MDN Web Docs (v angličtine)
Aktualizácia pravidiel úložiska vo WebKite – blog WebKit (v angličtine)