Offline režim webové aplikace: práce v terénu bez signálu

Webová aplikace může fungovat i tam, kde není signál – ve sklepě, na stavbě, ve skladu nebo na venkově. Podmínkou je navrhnout offline režim jako součást pracovního procesu, ne jako doplněk těsně před spuštěním. Technicky ho tvoří service worker, který uloží aplikaci do zařízení, lokální databáze v prohlížeči pro rozpracované záznamy a odchozí fronta změn, kterou aplikace po obnovení připojení odešle na server.

O úspěchu však rozhodují pravidla: jaká data má člověk v terénu s sebou, co smí udělat bez serveru, jak dlouho mohou neodeslané záznamy zůstat v telefonu a co se stane, když tentýž záznam mezitím změní kancelář. Článek je určen majitelům a manažerům firem, kteří plánují aplikaci pro servisní techniky, obhlídky, inventury nebo revize a zvažují, jak má vypadat offline režim webové aplikace.

Příklad: revize kotlů ve sklepích bez signálu

Ilustrativní příklad, firma je smyšlená. Servisní firma provádí revize plynových kotlů, často v kotelnách a sklepích bez mobilního signálu. Technik dnes zapisuje zjištění na papír, večer je přepisuje do systému a fotky posílá přes soukromý chat.

Cílový stav: ráno na firemní Wi-Fi si aplikace stáhne denní plán, adresy, historii zařízení a formuláře protokolů. Na místě technik vyplní protokol, přiloží fotky a zákazník se podepíše na displeji. Záznam se uloží v telefonu se stavem „Čeká na odeslání“. Když se signál vrátí, aplikace ho odešle, server potvrdí přijetí a stav se změní na „Odesláno“. Pokud kancelář mezitím zakázku zrušila, technik uvidí konflikt k vyřešení, ne tichý přepis své práce.

Co musí offline režim zvládnout a co ne

První rozhodnutí není technické. U každé úlohy určete, zda se dělá zcela offline, jako návrh, který potvrdí server, nebo pouze online. Vše, co potřebuje jeden autoritativní stav – číselné řady faktur, sklad, ceny –, nechte na serveru.

Úloha	Offline	Proč
Zobrazit denní plán a historii zařízení	Ano, z dat stažených předem	Technik potřebuje kontext i bez signálu
Vyplnit protokol, přiložit fotky a podpis	Ano, uloží se lokálně a odešle později	Hlavní důvod zavedení offline režimu
Založit novou zakázku na místě	Ano, jako návrh s dočasným identifikátorem	Číslo zakázky přidělí až server
Vystavit fakturu nebo rezervovat zboží	Ne, pouze připravit podklady	Číselné řady a stav skladu řídí server
Změnit ceník nebo oprávnění	Ne	Tato data mají mít jediný zdroj pravdy

Každé „ano“ v tabulce znamená vývoj a testování navíc. Do offline režimu proto patří jen úlohy, které se bez signálu skutečně dělají.

Technické stavební kameny a jejich limity

Service worker a uložená aplikace

Service worker je skript, který běží v samostatném vlákně. Při instalaci může uložit stránky, styly, skripty a obrázky aplikace do lokální cache a pak zachytávat její požadavky – buď nejprve z cache, nebo nejprve ze sítě s cache jako zálohou. Vhodná strategie podle průvodce MDN pro offline režim a práci na pozadí závisí na konkrétní aplikaci. Pro terénní aplikaci doporučujeme samotné rozhraní aplikace obsluhovat z cache s jasným verzováním a data zakázek držet v lokální databázi, kterou aplikace při každém připojení aktualizuje ze serveru.

Lokální databáze: IndexedDB, ne localStorage

localStorage ukládá pouze textové páry klíč – hodnota a podle dokumentace MDN o kvótách úložiště je omezené na 5 MiB pro jeden původ (origin). Na fotky a frontu změn nestačí. Pro větší strukturovaná data slouží IndexedDB, pro soubory soukromý souborový systém původu (OPFS).

Kvóty a mazání úložiště

Data se standardně ukládají v režimu „best-effort“, tedy bez záruky trvalosti: zůstanou, dokud původ nepřekročí kvótu, v zařízení je místo a uživatel je nesmaže. Když místo dochází, prohlížeč maže data nejdéle nepoužívaných původů – vždy všechna data původu najednou, ne jejich část (MDN).

Kvóty jsou vysoké, ale nejsou zárukou. Prohlížeče založené na Chromiu dovolí původu až 60 % celkové kapacity disku, Firefox v režimu best-effort menší z hodnot 10 % disku nebo 10 GiB a Safari od verze 17 přibližně 60 % disku (MDN). Počítá se však celková kapacita, ne volné místo, a podle blogu WebKit o pravidlech úložiště jde o horní hranici bez záruky. Aplikace proto musí zvládnout chybu QuotaExceededError.

Safari při zapnuté ochraně před sledováním napříč weby navíc smaže data vytvořená skriptem, pokud uživatel s webem během posledních sedmi dnů používání prohlížeče neinteragoval. Před smazáním při nedostatku místa chrání trvalé (perzistentní) úložiště, o které aplikace požádá přes navigator.storage.persist(). Firefox se uživatele zeptá, Safari a většina prohlížečů na Chromiu rozhodnou automaticky podle historie interakce a WebKit zohledňuje i to, zda je web spuštěný z plochy. Podle výzkumu týmu Chrome, na který odkazuje MDN, prohlížeče data pravidelně navštěvovaných webů mažou velmi zřídka. Telefon však berte jako dočasnou vyrovnávací paměť, ne jako místo, kde mají firemní data zůstat.

Stav připojení a synchronizace na pozadí

Vlastnost navigator.onLine není spolehlivá: připojení k lokální síti se zpravidla počítá jako online, i když síť nemá přístup k internetu. MDN proto doporučuje podle ní funkce nevypínat, pouze naznačit, že uživatel je možná offline. Za odeslaný považujte jen záznam, jehož přijetí potvrdil server.

Background Synchronization API umožňuje odložit odeslání na service worker, dokud není připojení stabilní. MDN ho však označuje jako funkci s omezenou dostupností a funguje pouze v zabezpečeném kontextu (HTTPS). Požadavek lze zaregistrovat jen při otevřené aplikaci, počet opakovaných pokusů je omezený a příliš dlouhou operaci prohlížeč ukončí, přičemž další pokus začne od začátku (MDN). Synchronizace na pozadí je tedy bonus. Základem má být odesílání při otevření aplikace, po obnovení spojení a tlačítkem „Odeslat nyní“, po malých dávkách, které lze bezpečně zopakovat.

Postup zavedení v sedmi krocích

Zmapujte práci v terénu. Zjistěte, kde a jak dlouho lidé nemají signál, jaká zařízení používají (firemní či vlastní, iPhone či Android) a kolik záznamů a fotek denně vznikne.
Určete offline rozsah. U každé úlohy rozhodněte podle tabulky: zcela offline, návrh k potvrzení, nebo pouze online.
Připravte datový model. Každý záznam dostane už v zařízení jedinečný identifikátor (například UUID), verzi a stav synchronizace. Server musí opakované odeslání rozpoznat a nevytvořit duplicitu.
Postavte odchozí frontu. Změna se nejprve zapíše do lokální databáze a fronty, teprve potom se odesílá – v pořadí vzniku, po dávkách a s opakováním. Fotky se nahrávají, až když server přijal samotný záznam.
Ošetřete úložiště. Požádejte o trvalé úložiště, sledujte odhad využití přes navigator.storage.estimate(), fotky před uložením zmenšete na rozlišení, které proces skutečně potřebuje, a po potvrzení serveru lokální kopie smažte.
Ukažte stav synchronizace. U každého záznamu ať je vidět, zda čeká na odeslání, byl odeslán, nebo má konflikt. Před odhlášením musí aplikace varovat a vypršené přihlášení nesmí zastavit práci ani smazat frontu.
Testujte v reálných podmínkách. Vyzkoušejte režim letadlo, Wi-Fi bez internetu, zavření aplikace během odesílání, plné úložiště a nasazení nové verze s neodeslanými daty – na iPhonu i Androidu.

Konflikty: kdo vyhraje, když se záznam změnil na dvou místech

Konflikt vzniká, když technik upravuje záznam offline a někdo jiný ho mezitím změní na serveru. Pravidlo „poslední zápis vyhrává“ se naprogramuje nejsnáz, ale potichu zahodí práci jednoho z nich. Určete proto pravidla předem podle typu dat.

Situace	Doporučené pravidlo	Kompromis
Technik doplní protokol, kancelář opraví kontakt zákazníka	Sloučit po polích, každé pole má svého vlastníka	Vlastnictví polí je třeba přesně určit
Kancelář zakázku zrušila, technik ji mezitím provedl	Nepřepisovat, označit konflikt k rozhodnutí dispečera	Někdo musí konflikty pravidelně řešit
Dva technici upravili tentýž záznam	Přijmout změnu k aktuální verzi, druhou vrátit jako konflikt	Druhý technik musí svou změnu zkontrolovat
Fotky, poznámky a podpisy	Pouze přidávat, nikdy nepřepisovat	Více uložených dat, ale nic se neztratí
Ceníky a číselníky	Server je jediný zdroj, zařízení je pouze čte	Offline může být v zařízení starší verze

Při konfliktu uchovejte obě verze i s autorem a časem. Jinak se spor o to, co technik na místě skutečně zapsal, nedá zpětně vyřešit.

Webová aplikace (PWA), nebo nativní aplikace?

Webová aplikace má jeden kód pro všechna zařízení, šíří se odkazem a novou verzi nasadíte na server bez obchodů s aplikacemi. Přijímáte však pravidla prohlížeče: úložiště v režimu best-effort, pokud prohlížeč neudělí trvalý režim, omezenou synchronizaci na pozadí a service worker, který prohlížeč zastaví, když to uzná za vhodné. Nativní aplikace může ukládat data ve vlastním úložišti mimo prohlížeč, takže se jí tyto kvóty ani pravidla mazání netýkají. Znamená však vývoj pro iOS i Android a distribuci přes obchody s aplikacemi nebo přes správu firemních zařízení.

Webová aplikace obvykle stačí, pokud jde o formuláře, kontrolní seznamy, fotky a podpisy a zařízení se alespoň jednou denně připojí.
Nativní aplikaci zvažte, pokud lidé pracují bez spojení celé dny, potřebují v zařízení velké objemy dat, například mapy či videa, nebo se data musí odeslat na pozadí bez otevření aplikace.

Rozhodněte se před vývojem. Změna přístupu v polovině projektu znamená předělávat úložiště a synchronizaci, tedy samotné jádro offline režimu.

Časté chyby

Offline režim až po spuštění. Datový model bez lokálních identifikátorů a verzí se dodatečně těžko předělává.
Spoléhání na navigator.onLine. Wi-Fi bez internetu se tváří jako připojení a záznamy zůstanou viset.
Data v localStorage. Pouze text a malá kapacita, pro fotky a frontu se nehodí.
Telefon jako jediná kopie. Neodeslané záznamy leží v zařízení celé dny, přestože prohlížeč může data webu smazat najednou.
Neviditelný stav synchronizace. Technik neví, co se odeslalo, a odhlásí se nebo smaže data prohlížeče.
Nová verze bez migrace. Aktualizace neumí přečíst neodeslanou frontu nebo ji smaže.
Anonymní prohlížení. Data se po ukončení anonymního režimu obvykle smažou, proto ho pro práci v terénu nepoužívejte.

Kontrolní seznam před nasazením

Tabulka úloh (offline, návrh, pouze online) je odsouhlasená terénem i kanceláří.
Každý záznam má lokální jedinečný identifikátor, verzi a stav synchronizace.
Server opakované odeslání rozpozná a nevytvoří duplicitu.
Záznamy a fotky jsou v IndexedDB nebo OPFS, ne v localStorage.
Aplikace žádá o trvalé úložiště, sleduje jeho využití a zvládne plné úložiště.
Úspěch odeslání potvrzuje server, ne stav připojení v prohlížeči.
Synchronizace funguje i bez Background Synchronization API.
Pravidla konfliktů jsou sepsaná, otestovaná a někdo konflikty řeší.
Odhlášení ani vypršené přihlášení nesmaže neodeslaná data bez varování.
V zařízení jsou pouze data potřebná pro aktuální zakázky a telefony mají zámek obrazovky.

Často kladené otázky

Funguje offline webová aplikace i na iPhonu?

Ano. Safari od verze 17 plně podporuje Storage API a webová aplikace přidaná na plochu má stejné kvóty jako v prohlížeči. WebKit při žádosti o trvalé úložiště zohledňuje, zda je web otevřený jako aplikace z plochy (WebKit). Doporučujeme proto aplikaci přidat na plochu a synchronizovat alespoň jednou denně. V EU mohou na iOS od verze 17.4 fungovat i prohlížeče s jiným jádrem, které mají vlastní pravidla úložiště (MDN).

Kolik dat může aplikace v telefonu uložit?

Závisí to na prohlížeči a zařízení. Horní hranice jsou vysoké, ale počítají se z celkové kapacity disku, ne z volného místa, takže skutečným omezením může být zaplněný telefon. Aplikace má sledovat odhad využití, zmenšovat fotky a po potvrzení serveru mazat lokální kopie.

Co se stane, když technik aplikaci zavře před odesláním?

Záznamy uložené v IndexedDB zůstanou v zařízení a aplikace je odešle při dalším otevření. Pokud prohlížeč podporuje Background Synchronization API a požadavek se zaregistroval při otevřené aplikaci, může je odeslat i po zavření. Funkce však není dostupná všude a prohlížeč omezuje počet i trvání pokusů, proto má technik vždy vidět, co ještě čeká na odeslání.

Potřebujeme kvůli offline režimu nativní aplikaci?

U formulářů, fotek a podpisů s denní synchronizací obvykle ne. Nativní aplikaci zvažte při dnech bez spojení, velkých objemech dat v zařízení nebo při potřebě odesílat data na pozadí. Rozhodněte se ještě před vývojem.

Jak začít

Pokud chcete, aby vaši lidé v terénu přestali přepisovat papíry a posílat fotky přes chat, začněte tabulkou úloh a jedním skutečným pracovním dnem v terénu. Podívejte se, jak vyvíjíme webové aplikace na míru, nebo nám napište přes kontakt. Pomůžeme vám určit offline rozsah, navrhnout synchronizaci a pravidla konfliktů a otestovat aplikaci v podmínkách, ve kterých ji budete používat. Pokud mají protokoly putovat dál do ERP nebo CRM, připravíme i API integraci. Další praktické návody najdete na našem blogu.

Zdroje

Kvóty úložiště a kritéria mazání dat – MDN Web Docs (v angličtině)
Offline režim a práce na pozadí v progresivních webových aplikacích – MDN Web Docs (v angličtině)
Background Synchronization API – MDN Web Docs (v angličtině)
Vlastnost navigator.onLine – MDN Web Docs (v angličtině)
Aktualizace pravidel úložiště ve WebKitu – blog WebKit (v angličtině)