„A malo by to fungovať aj bez internetu" je veta, ktorá sa v zadaní mobilnej aplikácie objaví často a znie nevinne. V praxi je to jedno z najväčších architektonických rozhodnutí celého projektu — nie preto, že by bolo technicky extrémne náročné, ale preto, že mení spôsob, akým sa s dátami zaobchádza všade v aplikácii, nie len v jednej obrazovke.
Prečo sa to nedá pridať dodatočne
Aplikácia navrhnutá s predpokladom stáleho pripojenia rieši dáta jednoducho: požiadavka ide na server, server odpovie, obrazovka sa zobrazí. Ak sa toto rozhranie doplní offline režimom neskôr, vzniká otázka pri každej jednej obrazovke — čo sa má stať, keď spojenie chýba práve teraz. Odpoveď „zobraziť chybu" nie je offline režim, je to len iný spôsob, ako povedať, že aplikácia offline nefunguje.
Skutočný offline režim vyžaduje, aby aplikácia od začiatku pracovala s lokálnou kópiou dát, ktorá sa priebežne synchronizuje so serverom, nie aby server bola jediná pravda, na ktorú sa vždy čaká. Toto rozhodnutie sa premieta do dátovej vrstvy, do toho, ako sa identifikujú nové záznamy vytvorené offline, aj do toho, ako sa aplikácia správa vizuálne.
Čo musí vedieť používateľ v každom momente
Aplikácia, ktorá nerozlišuje medzi overenými dátami a lokálnou kópiou, klame používateľa jemným, ale nebezpečným spôsobom. Zobrazuje číslo, ktoré vyzerá ako fakt, no v skutočnosti je to posledná známa hodnota spred hodiny.
Tri veci by mal používateľ vždy vedieť, aj bez toho, aby sa musel pýtať:
- Či je pripojenie aktívne, jednoducho a viditeľne, nie len v nastaveniach.
- Ktoré zmeny čakajú na odoslanie. Fronta zápisov, ktoré vznikli offline a ešte sa nedostali na server, musí byť viditeľná — inak si používateľ myslí, že jeho práca je hotová, kým v skutočnosti čaká v telefóne.
- Že sa niečo nepodarilo odoslať. Tichý neúspech synchronizácie je horší než viditeľná chyba, lebo sa objaví až vtedy, keď si to niekto všimne inde — napríklad kolega nevidí zápis, ktorý mal byť dávno odoslaný.
Ako funguje synchronizácia
Keď sa spojenie obnoví, aplikácia musí odoslať nahromadené zmeny v správnom poradí a vyriešiť prípadné konflikty. Základný princíp:
- Zmeny sa ukladajú lokálne s časovou pečiatkou a jednoznačným identifikátorom, aby sa dali neskôr spárovať so serverovým záznamom.
- Fronta sa odosiela postupne, nie naraz — pri veľkom počte zmien alebo nestabilnom pripojení by hromadné odoslanie zlyhalo celé namiesto čiastočne.
- Server potvrdí každý zápis zvlášť, takže aplikácia vie presne, čo sa už zosynchronizovalo a čo ešte čaká.
- Neúspešné položky zostávajú vo fronte a skúšajú sa znova, s viditeľným stavom pre používateľa.
Konflikty: keď dvaja ľudia zmenia to isté
Toto je scenár, ktorý sa v zadaní takmer nikdy nespomenie a v prevádzke nastane takmer isto. Dvaja technici v teréne, dvaja obchodníci, dvaja skladníci — každý pracuje offline, každý zmení ten istý záznam iným spôsobom, a keď sa obaja pripoja, systém musí rozhodnúť, čo platí.
| Stratégia | Ako funguje | Kedy sa hodí |
|---|---|---|
| Posledný zápis vyhráva | novšia časová pečiatka prepíše staršiu | jednoduché polia, nízke riziko straty dát |
| Zlúčenie na úrovni polí | zmenia sa len tie polia, ktoré sa reálne líšia | záznamy s viacerými nezávislými poľami |
| Eskalácia na človeka | systém ukáže obe verzie a nechá vybrať | dôležité alebo citlivé dáta |
| Prvý zápis vyhráva, druhý sa odmietne | druhý používateľ dostane upozornenie a musí zmenu zopakovať | keď je dôležité vedieť o strate |
Voľba stratégie nie je technická, je to rozhodnutie o tom, čo firma pri konflikte uprednostní — jednoduchosť, alebo istotu, že sa nič nestratí ticho. Pre kritické dáta, ako je napríklad výkaz, z ktorého sa fakturuje, sa oplatí radšej eskalovať na človeka než automaticky vybrať víťaza. Podobný princíp „radšej eskalovať než ticho rozhodnúť" sme rozoberali pri automatizácii terénneho servisu, kde offline výkazy technikov čelia presne tomuto problému.
Čo sa oplatí ujasniť pred vývojom
- Ktoré dáta musia fungovať offline a ktoré môžu vyžadovať pripojenie — nie všetko v aplikácii potrebuje rovnakú úroveň offline podpory.
- Ako dlho môže aplikácia zostať offline, kým sa to stane problémom — hodiny, dni, týždne, a čo sa stane s frontou, ktorá sa medzitým veľmi natiahne.
- Ktoré konflikty sú prijateľné riešiť automaticky a ktoré musia ísť na človeka.
- Ako sa testuje offline správanie — nie len „vypnúť wifi", ale aj nestabilné, prerušované pripojenie, ktoré je v reálnej prevádzke bežnejšie než úplný výpadok.
Zhrnutie
Offline režim je architektonické rozhodnutie, ktoré treba urobiť na začiatku projektu, nie doplnok pridaný na konci. Aplikácia musí vždy jasne ukázať, či pracuje s overenými alebo lokálnymi dátami, fronta neodoslaných zmien musí byť viditeľná, a stratégia riešenia konfliktov sa musí zvoliť podľa toho, čo firma stratou dát reálne riskuje — nie podľa toho, čo je najjednoduchšie naprogramovať.
Rozsah takéhoto riešenia závisí od toho, ako veľmi je aplikácia dátovo náročná a koľko používateľov môže pracovať na tých istých záznamoch súčasne offline. Ak plánujete mobilnú aplikáciu s offline podporou, prejdeme si konkrétne požiadavky na nezáväznej konzultácii alebo si pozrite naše riešenia v oblasti vývoja.