Musí to tak být? Ne nutně.
Právě na to se zaměřuje offline-first přístup. Jeho cílem je umožnit používání aplikace i bez stabilního připojení k internetu – alespoň u funkcí, které uživatelé potřebují nejčastěji. Neznamená to, že musí být každá funkce dostupná offline. Jde především o to, aby výpadek připojení automaticky neznemožnil další práci s aplikací.
Jak to funguje v praxi?
Ukládání dat přímo do zařízení
Základem offline-first aplikace je lokální ukládání dat. Místo toho, aby aplikace při každém otevření obrazovky načítala všechny informace ze serveru, ukládá potřebná data také přímo do zařízení.
Může jít například o uložené články, úkoly, poznámky nebo informace, ke kterým uživatel nedávno přistupoval. Data lze ukládat do lokální databáze, souborů nebo jiným způsobem do úložiště zařízení.
Když uživatel otevře aplikaci bez připojení k internetu, může dál pracovat s již uloženými informacemi. Aplikace nemusí čekat na odpověď serveru a dostupný obsah může zobrazit i při slabém připojení.
Je tu ale jeden důležitý rozdíl: lokálně uložená data nemusí být aktuální. Pokud někdo změnil informace na serveru nebo na jiném zařízení, aplikace o tom zatím nemusí vědět. Proto nestačí data pouze ukládat. Musí být také možné je aktualizovat.
Co se stane, když uživatel provede změny offline?
Představme si aplikaci pro správu úkolů. Během cesty metrem uživatel vytvoří nový úkol, nastaví termín a uloží ho.
Pokud aplikace vyžaduje trvalé připojení k internetu, uložení může selhat. Offline-first aplikace však může změnu nejprve uložit lokálně do zařízení. Uživatel nový úkol vidí a může pokračovat v práci.
Aplikace si zároveň zaznamená, že tuto změnu musí ještě odeslat na server.
Zde přichází na řadu offline queue, tedy fronta čekajících operací. Můžeme si ji představit jako seznam úkolů, které musí aplikace provést, jakmile bude znovu dostupné připojení k internetu.
Po obnovení připojení začne aplikace čekající změny odesílat. Pokud některá operace selže, může se o její provedení pokusit znovu.
Ne každou akci je ale možné bezpečně odložit. Například bankovní převod, který vyžaduje potvrzení serverem, nelze považovat za úspěšný jen proto, že uživatel klikl na tlačítko. V takových případech musí aplikace jasně rozlišovat mezi požadavkem, který stále čeká na zpracování, a skutečně potvrzenou transakcí.
Synchronizace: Když musí být všechna data aktuální
Jakmile je internetové připojení znovu dostupné, aplikace musí porovnat lokálně uložená data s údaji na serveru. Tento proces se nazývá synchronizace.
V nejjednodušším případě aplikace odešle změny provedené offline a stáhne nejnovější informace ze serveru. V praxi ale může být synchronizace složitější, zejména pokud uživatelé pracovali na více zařízeních.
Představme si, že ráno změníte název úkolu ve svém telefonu. Později stejný úkol upraví kolega na jiném zařízení. Obě zařízení mohla vycházet ze stejné původní verze, ale následně informace změnila různými způsoby.
Co se stane, když se obě zařízení znovu připojí k internetu?
Konflikty: Když se střetnou dvě změny
Pokud se stejná informace změní na více místech ještě před synchronizací, aplikace musí rozhodnout, jak tyto změny sloučit. Tento proces se nazývá řešení konfliktů (Conflict Resolution).
Jednou z možností je pravidlo Last Write Wins. V takovém případě se upřednostní poslední změna podle stanoveného časového údaje. To ale nemusí být vždy nejlepší řešení. Vhodný přístup závisí na typu dat a na důsledcích, které by přepsání některé změny mohlo mít.
U jednoduchého nákupního seznamu může stačit automatické pravidlo. U společně upravovaného dokumentu nebo důležitých firemních dat může být naopak nutné změny sloučit nebo konflikt zobrazit uživateli, aby o výsledku rozhodl sám.
Proto je důležité myslet na pravidla synchronizace a řešení konfliktů už při plánování aplikace. Pokud se tyto otázky začnou řešit až později, může to vést ke ztrátě dat nebo nepředvídatelnému chování aplikace.
Co když se připojení stále přerušuje?
Ani po obnovení připojení nemusí všechno fungovat hned napoprvé. Síť může být nestabilní, server může dočasně přestat reagovat nebo může požadavek selhat z jiného důvodu.
Offline-first aplikace proto potřebují spolehlivé mechanismy opakování požadavků (Retry Mechanisms). U dočasných chyb se aplikace může pokusit odeslat požadavek znovu. Často přitom postupně prodlužuje čekací dobu mezi jednotlivými pokusy. Tento přístup se označuje jako Exponential Backoff.
Důležité ale je neopakovat automaticky každý požadavek bez rozmyslu. Pokud server akci odmítne, protože uživatel nemá potřebná oprávnění, čekání problém nevyřeší. U operací, které mění data, je navíc nutné zabránit tomu, aby se stejná akce při opakovaném pokusu provedla dvakrát.
Aplikace by také měla uživateli ukázat, co se právě děje. Byla změna uložena pouze do zařízení? Čeká na odeslání? Potvrdil ji už server? Jasné zobrazení stavu je mnohem užitečnější než obecné chybové hlášení.
Offline-first je víc než jen technická funkce
Offline-first přístup může výrazně zlepšit uživatelskou zkušenost, zejména při cestování, práci v terénu nebo v oblastech s nespolehlivým internetovým připojením. Aplikace může reagovat rychleji, uživatelé nemusí znovu zadávat ztracené informace a dočasný výpadek připojení nemusí přerušit jejich práci.
Zároveň však tento přístup vyžaduje pečlivé plánování. Která data mají být dostupná offline? Které změny lze bezpečně uložit a odeslat později? Jak se budou řešit konflikty? Co se stane, když se synchronizace opakovaně nezdaří?
Odpovědi závisí na konkrétní aplikaci. Poznámková aplikace s offline režimem má jiné požadavky než bankovní aplikace nebo nástroj pro spolupráci v reálném čase.
Dobrá offline-first aplikace neslibuje, že nikdy nebude potřebovat připojení k internetu. Zajišťuje ale, aby výpadek připojení uživatele zbytečně nezastavil v práci.
Právě v tom je rozdíl mezi aplikací, která funguje jen za ideálních podmínek, a aplikací navrženou pro skutečný svět.
