Offline režim v aplikacích: Kdy je nutný a jak řešit synchronizaci

01Rozhodujte podle následku výpadku

Offline režim potřebujete tam, kde přerušení spojení zastaví důležitou práci nebo zničí rozpracované údaje. Nejdřív si u každé činnosti napište, jak dlouho smí čekat a co se stane, pokud člověk pokračuje se starými informacemi. Odpověď často rozdělí jednu aplikaci na několik různých režimů.

Katalog může zobrazit včerejší fotografii výrobku. Návrh objednávky může vzniknout bez spojení. Závazná rezervace posledního kusu ale potřebuje společné rozhodnutí o dostupnosti. Jestli dva odpojení prodejci vidí stejný poslední kus, samotná synchronizace dodatečně nesplní oba sliby zákazníkům.

Sepište také skutečné podmínky provozu: krátké výpadky v kanceláři, celý pracovní den bez sítě, sdílené tablety nebo souběžné úpravy z více zařízení. Doba odpojení a počet lidí, kteří mění stejné údaje, mají pro návrh větší význam než obecný požadavek „ať to funguje i offline“. U jednoduchého interního přehledu může stačit srozumitelná chyba a zachování rozepsaného formuláře.

Konkrétní provozní scénáře ukazuje článek o mobilní aplikaci pro techniky bez signálu.

02Vyberte rozsah: Čtení, zápis, nebo potvrzení

Dokumentace Androidu rozlišuje místní čtení a strategie zápisu. Označení offline-first samo o sobě neslibuje, že aplikace bez sítě dokončí všechny změny. Přeložte ho do konkrétních povolených činností.

Pro každou oblast určete vlastníka údajů. Cena může přicházet z centrálního ceníku, poznámka vznikat v zařízení a schválení zůstávat na serveru. „Poslední uložená verze“ není dostatečné obchodní pravidlo. Uživatel například smí rozepsat slevu offline, ale neměl by zákazníkovi ukázat neověřené schválení vedoucího.

03Navrhněte cestu jedné změny

Pro zápis doporučujeme popsat celou cestu: člověk upraví údaj, aplikace ho trvale uloží místně, zaznamená čekající operaci, po připojení ji odešle a zpracuje odpověď serveru. Pokud nelze uložit změnu ani místně, uživatel se to musí dozvědět ještě před odchodem z obrazovky.

Seznam čekajících operací se často označuje jako outbox. Důležité je, aby samotný záznam a pokyn k jeho pozdějšímu přenosu vznikly společně. Jinak může být návrh vidět v telefonu, aniž by ho cokoli poslalo dál. Místní kopii pro obrazovku přitom nezaměňujte za autoritu pro firemní schválení.

Přílohy mají vlastní průběh. V modelové objednávce dorazí text dříve než fotografie vzorku. Rozhodněte, zda smí kancelář návrh otevřít neúplný a která příloha je nutná pro další krok. Zvlášť evidujte stažení aktualizovaných dat ze serveru; odeslaná vlastní změna ještě neznamená, že zařízení zná změny ostatních.

04Opakovaný přenos nesmí vytvořit druhou operaci

Nejzrádnější situace nastane, když server změnu přijme, ale jeho odpověď se ztratí. Aplikace neví, zda má požadavek opakovat. AWS popisuje použití jednoznačného identifikátoru operace: stejný pokus se stejným ID nesmí znovu vyvolat tentýž účinek. Tomu se říká idempotence.

V zadání proto odlište nový požadavek od opakovaného doručení původního. Nová objednávka dostane novou identitu, opakované odeslání stávající si ponechá původní. Dohodněte také, jak dlouho server historii těchto identit uchovává vzhledem k nejdelší podporované době odpojení.

Při dočasné chybě prodlužujte odstup mezi pokusy. Chybu oprávnění nebo neplatný údaj nepřeposílejte donekonečna. Položka má přejít k nápravě s konkrétním důvodem. Závislé operace musí respektovat pořadí: přidání položky nemůže předběhnout vytvoření objednávky, ke které patří. Tyto podmínky zahrňte také do návrhu integračního API.

05Konflikty řešte podle významu údajů

Dva obchodníci otevřou stejný návrh. Jeden změní dodací adresu, druhý počet kusů. Při návratu do sítě nejdřív potřebujete zjistit, z jaké verze oba vycházeli. Bez této informace snadno přepíšete změnu, kterou druhé zařízení ještě nevidělo.

• Nezávislé poznámky: Přidávejte je jako samostatné záznamy s autorem.
• Různá pole: Slučujte je jen tehdy, pokud tím nevznikne obchodně neplatná kombinace.
• Stejné pole: U důležitých údajů ukažte obě hodnoty určenému řešiteli.
• Smazání a pozdější úprava: Určete, zda se změna odmítne, obnoví návrh, nebo předá ke kontrole.

Pravidlo „poslední vyhrává“ může stačit pro nenáročnou osobní předvolbu. U ceny, zásoby nebo schválení obvykle potřebujete důvod, proč je právě daná změna platná. Samotný čas na telefonu není spolehlivé pořadí obchodních událostí. Zaznamenejte výsledek řešení, aby další synchronizace nevracela stejný konflikt znovu.

06Počítejte s omezeními zařízení a prohlížeče

U webových aplikací nepovažujte zavřený prohlížeč za spolehlivě běžící přenosovou službu. Background Synchronization API nemá všeobecnou podporu. Navrhněte proto i odeslání při dalším otevření aplikace a viditelný seznam čekajících změn.

Také místo pro data má hranice. MDN popisuje kvóty a odstraňování uložených webových dat. Při rozhodování o webové aplikaci prověřte konkrétní zařízení, režim prohlížeče a objem příloh. Pouhá ikona instalované aplikace vám požadované chování nepotvrdí.

Ukládejte potřebný výběr dat, ne automaticky celý zákaznický archiv. OWASP požaduje ochranu citlivých údajů uložených v mobilní aplikaci. V návrhu k tomu přidejte dobu dostupnosti offline, oddělení uživatelů a postup při odebrání přístupu. Odpojené zařízení nemůže okamžitě přijmout vzdálený pokyn k vymazání. Tuto hranici musí znát vlastník procesu.

Ochranu údajů uložených v telefonu a přístupu k API rozebírá náš průvodce bezpečností mobilní aplikace.

07Rozpočet i převzetí postavte na scénářích

Cenu nezvyšuje jen místní databáze. Práci přidává správa verzí, migrace uložených dat po aktualizaci aplikace, řešení odmítnutých požadavků a diagnostika na konkrétním zařízení. Zeptejte se dodavatele, kdo dokáže zjistit, proč změna čeká, aniž by uživatel posílal celý zákaznický záznam v e-mailu.

Pro první verzi vyberte jednu hodnotnou činnost a jasnou hranici, například rozpracování objednávky s online potvrzením. Ověřte ji při ztracené odpovědi, opakovaném odeslání, souběžné úpravě, plném úložišti a aktualizaci aplikace s čekajícími změnami. Po obnovení spojení porovnejte obchodní výsledek, nejen zelenou ikonu připojení.

V provozu sledujte stáří nejstarší čekající operace, počet nevyřešených konfliktů a příčiny odmítnutí. Určete člověka, který zasáhne. Offline režim dává smysl, když lidé dokážou pokračovat a firma následně získá srozumitelný, kontrolovatelný výsledek.

08Časté otázky

09Vymezte offline režim před vývojem

Pošlete nám hlavní činnost aplikace, nejdelší očekávané odpojení a příklad údaje, který upravuje více lidí. Probereme návrh offline režimu, pravidla potvrzování a scénáře, podle kterých půjde řešení převzít.