„A mělo by to fungovat i bez internetu" je věta, která se v zadání mobilní aplikace objevuje často a zní nevinně. V praxi je to jedno z největších architektonických rozhodnutí celého projektu — ne proto, že by bylo technicky extrémně náročné, ale proto, že mění způsob, jakým se s daty zachází všude v aplikaci, ne jen na jedné obrazovce.
Proč se to nedá přidat dodatečně
Aplikace navržená s předpokladem stálého připojení řeší data jednoduše: požadavek jde na server, server odpoví, obrazovka se zobrazí. Pokud se toto rozhraní doplní offline režimem později, vzniká otázka u každé jedné obrazovky — co se má stát, když připojení zrovna chybí. Odpověď „zobrazit chybu" není offline režim, je to jen jiný způsob, jak říct, že aplikace offline nefunguje.
Skutečný offline režim vyžaduje, aby aplikace od začátku pracovala s lokální kopií dat, která se průběžně synchronizuje se serverem, ne aby server byl jediná pravda, na kterou se vždy čeká. Toto rozhodnutí se promítá do datové vrstvy, do toho, jak se identifikují nové záznamy vytvořené offline, i do toho, jak se aplikace chová vizuálně.
Co musí uživatel vědět v každém okamžiku
Aplikace, která nerozlišuje mezi ověřenými daty a lokální kopií, klame uživatele jemným, ale nebezpečným způsobem. Zobrazuje číslo, které vypadá jako fakt, ale ve skutečnosti je to poslední známá hodnota před hodinou.
Tři věci by měl uživatel vždy vědět, aniž by se musel ptát:
- Jestli je připojení aktivní, jednoduše a viditelně, ne jen v nastaveních.
- Které změny čekají na odeslání. Fronta zápisů, které vznikly offline a ještě se nedostaly na server, musí být viditelná — jinak si uživatel myslí, že jeho práce je hotová, zatímco ve skutečnosti čeká v telefonu.
- Že se něco nepodařilo odeslat. Tichý neúspěch synchronizace je horší než viditelná chyba, protože se objeví až tehdy, když si toho někdo všimne jinde — třeba kolega nevidí zápis, který měl být dávno odeslán.
Jak funguje synchronizace
Když se připojení obnoví, aplikace musí odeslat nahromaděné změny ve správném pořadí a vyřešit případné konflikty. Základní princip:
- Změny se ukládají lokálně s časovým razítkem a jednoznačným identifikátorem, aby se daly později spárovat se serverovým záznamem.
- Fronta se odesílá postupně, ne najednou — u velkého počtu změn nebo nestabilního připojení by hromadné odeslání selhalo celé místo částečně.
- Server potvrdí každý zápis zvlášť, takže aplikace ví přesně, co už se zesynchronizovalo a co ještě čeká.
- Neúspěšné položky zůstávají ve frontě a zkoušejí se znovu, s viditelným stavem pro uživatele.
Konflikty: když dva lidé změní totéž
Toto je scénář, který se v zadání téměř nikdy nezmíní a v provozu nastane téměř jistě. Dva technici v terénu, dva obchodníci, dva skladníci — každý pracuje offline, každý změní stejný záznam jiným způsobem, a když se oba připojí, systém musí rozhodnout, co platí.
| Strategie | Jak funguje | Kdy se hodí |
|---|---|---|
| Poslední zápis vyhrává | novější časové razítko přepíše starší | jednoduchá pole, nízké riziko ztráty dat |
| Sloučení na úrovni polí | změní se jen ta pole, která se reálně liší | záznamy s více nezávislými poli |
| Eskalace na člověka | systém ukáže obě verze a nechá vybrat | důležitá nebo citlivá data |
| První zápis vyhrává, druhý se odmítne | druhý uživatel dostane upozornění a musí změnu zopakovat | když je důležité vědět o ztrátě |
Volba strategie není technická, je to rozhodnutí o tom, co firma při konfliktu upřednostní — jednoduchost, nebo jistotu, že se nic neztratí potichu. U kritických dat, jako je například výkaz, ze kterého se fakturuje, se vyplatí raději eskalovat na člověka než automaticky vybrat vítěze. Podobný princip „raději eskalovat než tiše rozhodnout" jsme rozebírali u automatizace terénního servisu, kde offline výkazy techniků čelí přesně tomuto problému.
Co se vyplatí ujasnit před vývojem
- Která data musí fungovat offline a která mohou vyžadovat připojení — ne všechno v aplikaci potřebuje stejnou úroveň offline podpory.
- Jak dlouho může aplikace zůstat offline, než se to stane problémem — hodiny, dny, týdny, a co se stane s frontou, která se mezitím hodně natáhne.
- Které konflikty je přijatelné řešit automaticky a které musí jít na člověka.
- Jak se testuje offline chování — ne jen „vypnout wifi", ale i nestabilní, přerušované připojení, které je v reálném provozu běžnější než úplný výpadek.
Shrnutí
Offline režim je architektonické rozhodnutí, které je třeba udělat na začátku projektu, ne doplněk přidaný na konci. Aplikace musí vždy jasně ukázat, jestli pracuje s ověřenými nebo lokálními daty, fronta neodeslaných změn musí být viditelná, a strategie řešení konfliktů se musí zvolit podle toho, co firma ztrátou dat reálně riskuje — ne podle toho, co je nejjednodušší naprogramovat.
Rozsah takového řešení závisí na tom, jak moc je aplikace datově náročná a kolik uživatelů může pracovat na stejných záznamech současně offline. Pokud plánujete mobilní aplikaci s offline podporou, projdeme si konkrétní požadavky na nezávazné konzultaci nebo si prohlédněte naše řešení v oblasti vývoje.