Offline režim v aplikáciách: Kedy je potrebný a ako riešiť synchronizáciu
Obchodník pripraví objednávku bez internetu. Kolega zatiaľ zmení cenu a rezervuje posledný kus. Po pripojení nestačí oba záznamy preniesť. Aplikácia musí určiť, čo platí, čo čaká na potvrdenie a čo má vyriešiť človek. Práve týmito pravidlami sa začína dobrý offline režim.
01Rozhodujte podľa následku výpadku
Prácu bez pripojenia potrebujete tam, kde výpadok zastaví dôležitú činnosť alebo ohrozí rozpracované údaje. Pri každom úkone si najskôr zapíšte, ako dlho môže počkať a čo sa stane, ak človek pokračuje so starými informáciami. Často zistíte, že jednotlivé časti aplikácie potrebujú odlišné pravidlá.
Katalóg môže ukazovať včerajšiu fotografiu výrobku. Obchodník si môže bez siete pripraviť objednávku. Záväzná rezervácia posledného kusu však potrebuje spoločné rozhodnutie o dostupnosti. Ak dvaja odpojení predajcovia vidia ten istý posledný kus, neskoršia synchronizácia nedokáže splniť oba sľuby zákazníkom.
Zaznamenajte aj podmienky používania: krátke výpadky v kancelárii, celý deň bez internetu, zdieľané tablety či súbežné zmeny z viacerých zariadení. Dĺžka odpojenia a počet ľudí upravujúcich rovnaké údaje sú pre návrh dôležitejšie než všeobecná požiadavka „nech to funguje offline“. Pri jednoduchom internom prehľade môže stačiť zrozumiteľné hlásenie a zachovanie rozpísaného formulára.
Konkrétne prevádzkové scenáre ukazuje článok o mobilnej aplikácii pre technikov bez signálu.
02Vyberte rozsah: Čítanie, zápis alebo potvrdenie
Dokumentácia Androidu odlišuje miestne čítanie od stratégií zápisu. Označenie offline-first preto neznamená, že aplikácia bez siete dokončí každú zmenu. V zadaní ho nahraďte konkrétnymi povolenými činnosťami.
| Režim | Čo používateľ zvládne | Čo musí vedieť |
|---|---|---|
| Čítanie miestnej kópie | Otvorí predtým stiahnutý obsah | Aký je starý a čo sa nestiahlo |
| Miestne rozpracovanie | Uloží návrh alebo poznámku | Kde je uložená a či dorazila na server |
| Odložené spracovanie | Pripraví požiadavku na odoslanie | Že ju server môže po pripojení odmietnuť |
| Online potvrdenie | Získa záväzný spoločný výsledok | Bez spojenia sa tento krok nedokončí |
Pre každú oblasť určite vlastníka údajov. Cena môže pochádzať z centrálneho cenníka, poznámka vznikať v zariadení a schválenie zostať na serveri. „Naposledy uložená verzia“ nie je dostatočné obchodné pravidlo. Používateľ si môže pripraviť zľavu offline, nemal by však zákazníkovi ukazovať neoverené schválenie vedúceho.
03Navrhnite cestu jednej zmeny
Pri zápise odporúčame opísať celý postup: človek upraví údaj, aplikácia ho trvalo uloží do zariadenia, zaznamená čakajúcu operáciu, po pripojení ju odošle a spracuje odpoveď servera. Ak sa zmena nedá uložiť ani miestne, používateľ to musí zistiť skôr, než odíde z obrazovky.
Zoznam čakajúcich operácií sa často nazýva outbox. Podstatné je, aby záznam aj pokyn na jeho neskorší prenos vznikli spoločne. Inak môže byť návrh v telefóne viditeľný, no nič sa nepostará o jeho odoslanie. Miestnu kópiu pre obrazovku zároveň nezamieňajte s autoritou, ktorá povoľuje firemné rozhodnutia.
Prílohy majú vlastný priebeh. V modelovej objednávke sa text prenesie skôr než fotografia vzorky. Dohodnite sa, či kancelária môže otvoriť neúplný návrh a ktorá príloha je podmienkou ďalšieho kroku. Samostatne sledujte sťahovanie nových údajov zo servera. Odoslaná vlastná zmena ešte neznamená, že zariadenie pozná úpravy ostatných.
04Opakovaný prenos nesmie vytvoriť druhú operáciu
Nepríjemná situácia nastane, keď server zmenu prijme, ale jeho odpoveď sa stratí. Aplikácia nevie, či má požiadavku zopakovať. AWS opisuje jednoznačný identifikátor operácie: opakovaný pokus s rovnakým ID nemá znova vyvolať ten istý účinok. Táto vlastnosť sa nazýva idempotencia.
V zadaní preto odlíšte novú požiadavku od opätovného doručenia pôvodnej. Nová objednávka dostane novú identitu, opakované odoslanie existujúcej si ponechá pôvodnú. Dohodnite aj to, ako dlho server uchováva históriu týchto identít vzhľadom na najdlhšie podporované odpojenie.
Pri dočasnom výpadku predlžujte čas medzi pokusmi. Chybu oprávnenia ani neplatný údaj neposielajte znova donekonečna. Položka má prejsť na nápravu s konkrétnym dôvodom. Závislé operácie musia dodržať poradie: pridanie položky nemôže predbehnúť vznik objednávky, ku ktorej patrí. Tieto podmienky zahrňte aj do návrhu integračného API.
05Rozpory riešte podľa významu údajov
Dvaja obchodníci si otvoria rovnaký návrh. Jeden zmení dodaciu adresu, druhý počet kusov. Po pripojení najskôr potrebujete zistiť, z ktorej verzie obaja vychádzali. Bez tejto informácie ľahko prepíšete úpravu, ktorú druhé zariadenie ešte nevidelo.
- Nezávislé poznámky: Pridávajte ich ako samostatné záznamy s autorom.
- Rôzne polia: Zlučujte ich len vtedy, ak nevznikne obchodne neplatná kombinácia.
- Rovnaké pole: Pri dôležitom údaji ukážte obe hodnoty určenému riešiteľovi.
- Vymazanie a neskoršia úprava: Určite, či sa zmena odmietne, obnoví návrh alebo odovzdá na kontrolu.
Pravidlo „posledná zmena vyhráva“ môže stačiť pre nenáročnú osobnú predvoľbu. Pri cene, zásobe či schválení spravidla potrebujete vedieť, prečo je daná hodnota platná. Samotný čas v telefóne nezaručuje správne poradie obchodných udalostí. Výsledok riešenia uložte, aby ďalšia synchronizácia neotvárala rovnaký rozpor znova.
06Počítajte s obmedzeniami zariadenia a prehliadača
Pri webovej aplikácii nepočítajte so zatvoreným prehliadačom ako so spoľahlivo bežiacou prenosovou službou. Background Synchronization API nemá všeobecnú podporu. Navrhnite aj odoslanie pri ďalšom otvorení aplikácie a viditeľný zoznam čakajúcich zmien.
Aj priestor na údaje má hranice. MDN vysvetľuje kvóty a odstraňovanie uložených webových dát. Pri rozhodovaní o webovej aplikácii si overte konkrétne zariadenie, režim prehliadača a objem príloh. Ikona nainštalovanej aplikácie vám požadované správanie nepotvrdí.
Ukladajte potrebný výber údajov, nie automaticky celý zákaznícky archív. OWASP vyžaduje ochranu citlivých údajov uložených v mobilnej aplikácii. V návrhu určite aj dobu dostupnosti offline, oddelenie používateľov a postup pri odobratí prístupu. Odpojené zariadenie nemôže okamžite prijať vzdialený pokyn na vymazanie. Vlastník procesu musí s týmto obmedzením počítať.
Ochranu údajov uložených v telefóne a prístupu k API rozoberá náš sprievodca bezpečnosťou mobilnej aplikácie.
07Rozpočet aj prevzatie postavte na scenároch
Cenu nezvyšuje iba miestna databáza. Prácu pridáva správa verzií, úprava uložených dát po aktualizácii aplikácie, riešenie odmietnutých požiadaviek a diagnostika konkrétneho zariadenia. Zistite, kto dokáže odhaliť dôvod čakajúcej zmeny bez toho, aby používateľ posielal celý zákaznícky záznam e-mailom.
Do prvej verzie vyberte jednu hodnotnú činnosť a jasnú hranicu, napríklad prípravu objednávky s online potvrdením. Overte ju pri stratenej odpovedi, opakovanom odoslaní, súbežnej úprave, plnom úložisku a aktualizácii s čakajúcimi zmenami. Po obnovení siete porovnajte obchodný výsledok, nielen zelenú ikonu pripojenia.
V prevádzke sledujte vek najstaršej čakajúcej operácie, počet nevyriešených rozporov a príčiny odmietnutia. Určite človeka, ktorý zasiahne. Offline režim má zmysel, keď ľudia môžu pokračovať v práci a firma následne dostane zrozumiteľný výsledok, ktorý dokáže skontrolovať.
08Časté otázky
Je offline režim to isté ako cache?
Nie. Cache uchováva kópie na rýchlejšie alebo neskoršie čítanie. Zápis bez siete navyše potrebuje uchovanie zmien, prenos, odpovede servera a pravidlá riešenia rozporov.
Dá sa offline potvrdiť posledné voľné miesto?
Bez ďalšieho mechanizmu nie bezpečne pre viac nezávislých zariadení. Môžete uložiť žiadosť alebo vopred rozdeliť obmedzenú kapacitu, ale rezervačné pravidlo musí zodpovedať celému procesu.
Potrebujeme vlastné synchronizačné riešenie?
Nie vždy. Hotový nástroj alebo databázovú službu overte na vašich rozporoch, oprávneniach a pravidlách mazania. Automatický prenos sám nezaručuje správny obchodný výsledok.
Čo ak sa zariadenie pred prenosom stratí?
Neodoslané údaje môžu byť nedostupné alebo stratené. Miestne úložisko nie je vzdialená záloha. Určite kontrolu čakajúcich zmien a postup obnovenia práce.
09Vymedzte offline režim pred vývojom
Pošlite nám hlavnú činnosť aplikácie, najdlhšie očakávané odpojenie a príklad údaja, ktorý upravuje viac ľudí. Preberieme návrh offline režimu, pravidlá potvrdzovania aj scenáre, podľa ktorých budete riešenie preberať.