Offline-First a mobilfejlesztésben — mi ez, elvek és munkastratégia
Offline-First — egy mobil és webalkalmazás-fejlesztési stratégia, amelynél az alkalmazás először a helyi adattárolóhoz fordul, majd a háttérben szinkronizál a szerverrel. A felhasználó azonnal látja a felületet, még internet hiányában is, és az adatok automatikusan szinkronizálódnak a kapcsolat helyreállásakor. A Google Developers, 2025 adatai szerint az Offline-First megközelítés 20-40%-kal növeli a felhasználói elköteleződést a stabil működésnek köszönhetően instabil hálózati körülmények között.
Főbb pontok
- Offline-First — stratégia, ahol a helyi adatok elsőbbséget élveznek a hálózati kérésekkel szemben.
- Helyi tároló — győrűtár az eszközön (Room, SQLite, DataStore) azonnali hozzáférést biztosít az adatokhoz.
- Háttérszinkronizálás — a változtatások a szerverre kerülnek a hálózati kapcsolat helyreállásakor.
- Konfliktuskezelés — Last-Write-Wins vagy CRDT megközelítések a helyi és szerveradatokat összehangolására.
- Service Worker — az Offline-First kulcskomponense webalkalmazásokban és Progressive Web Apps-ben.
Mi az Offline-First?
Offline-First — egy architekturális megközelítés az alkalmazásfejlesztésben, ahol a helyi adattárolás és feldolgozás elsődleges, a hálózati kérések pedig másodlagosak. Ellentétben a hagyományos Online-Only megközelítéssel, ahol az alkalmazás kérést küld a szervernek és vár a válaszra, az Offline-First alkalmazás először a helyi győrűtárból vagy adatbázisból olvassa az adatokat, azonnal megjeleníti a felhasználónak, és csak azután szinkronizál a szerverrel a háttérben. Ez teljesen megváltoztatja a felhasználói élményt: a képernyők ezredmásodpercek alatt betöltenek, függetlenül az internet sebességétől.
Az Offline-First koncepció a mobilos forgalom növekedésével és az alkalmazások instabil internetű régiókban történő terjedésével válik népszerűvé. A Google I/O 2025 adatai szerint a mobilalkalmazás-felhasználók több mint 60%-a naponta legalább egyszer szembesül hálózati kapcsolati problémákkal. Az Offline-First megoldja ezt a problémát azáltal, hogy az alkalmazást internet nélkül is teljesen működőképessé teszi. A felhasználó létrehozhat, szerkeszthet és törölhet adatokat — az összes változtatás helyileg tárolódik és a kapcsolat helyreállásakor szinkronizálódik.
Az Offline-First-t meg kell különböztetni az egyszerű győrűtéstől. Győrűtéskor az adatok először a szerverről töltődnek be, majd másolatként helyileg tárolódnak. Az Offline-First esetében a helyi tároló az igazság forrása (source of truth). A felhasználó a helyi adatokkal dolgozik, a szerver pedig replika. Ha a hálózat nem érhető el, az alkalmazás teljes mértékben tovább működik. Ha a hálózat elérhető, a változtatások a háttérben szinkronizálódnak. Ez a megközelítés összetettebb architektúrát igényel, de minőségileg más felhasználói élményt nyújt.
Offline-First vs Online-Only vs Offline-Only
Három megközelítés létezik az adatokkal való munkához az alkalmazásokban. Online-Only — az alkalmazás nem működik internet nélkül, minden adat a szerveren tárolódik. Offline-Only — az alkalmazás teljesen helyileg működik, nincs szinkronizálás a szerverrel. Offline-First — hibrid: a helyi adatok az igazság forrásaként, a szerver replikaként a biztonsági mentéshez és megosztott hozzáféréshez. Minden megközelítésnek megvan a maga alkalmazási területe: az Online-Only banki műveletekhez, az Offline-Only számólgépekhez, az Offline-First pedig közösségi hálózatokhoz, jegyzetekhez, feladatokhoz és üzenetküldőkhöz alkalmas.
Az Offline-First stratégia elvei
Az Offline-First architektúra négy kulcsfontosságú elvre épül. Helyi igazság forrása — minden adat először a helyi adatbázisban tárolódik, és csak azután kerül a szerverre. A felhasználó mindig a helyi tárolóból származó aktuális adatokat látja, ami azonnali felületválaszt biztosít. Az alkalmazás soha nem vár a szerver válaszára az adatok megjelenítéséhez — ez az alapvető különbség a betöltő indikátorokkal ellátott hagyományos REST-kliensekhez képest.
Háttérszinkronizálás — az adatok helyi tárolása után az alkalmazás szinkronizálási feladatot ütemez. Ha a hálózat elérhető, a változtatások azonnal a szerverre kerülnek. Ha a hálózat nem érhető el, a feladat egy sorban tárolódik és a kapcsolat helyreállásakor végrehajtódik. Az Android WorkManager és az iOS BGProcessingTask szabványos eszközök ennek az elvnek a megvalósításához. Konfliktusfeloldás — szinkronizáláskor konfliktusok léphetnek fel, ha ugyanazokat az adatokat különböző eszközökön módosították. Megoldási stratégiák: Last-Write-Wins, Multi-Version Concurrency Control vagy CRDT.
Adaptív felület — az alkalmazásnak tájékoztatnia kell a felhasználót a szinkronizálás állapotáról, de nem blokkolhatja a munkát offline módban. Kapcsolat állapot ikon, a nem szinkronizált változtatások számának jelzője és a szinkronizálás befejeződéséről szóló értesítések kötelező UX-elemek az Offline-First alkalmazásokhoz. A Service Worker webalkalmazásokban és a Network Manager mobilalkalmazásokban figyeli a hálózat állapotát és kezeli az adatküldést.
Cache-First vs API-First vs Offline-First
Cache-First — az alkalmazás először a győrűtárat ellenőrzi, de ha nincs adat, kérést küld a szervernek. Ez az Offline-First egyszerűsített változata szinkronizálási sor és konfliktusfeloldás nélkül. API-First — az alkalmazás mindig a szervertől kér adatokat, a győrűtárat csak hálózathiány esetén használja tartalékként. Offline-First — a legösszetettebb, de legmegbízhatóbb megközelítés, amely teljes funkcionalitást biztosít hálózat nélkül és adatkonzisztenciát a szinkronizáláskor.
Eszközök az Offline-First megvalósításához
A modern platformok eszközkészletet kínálnak Offline-First alkalmazások építéséhez. Androidon a fő helyi tárolási eszköz a Room — egy könyvtár az SQLite fölött, amely típusbiztos API-t biztosít az adatbázissal való munkához. A Room lehetővé teszi összetett objektumok tárolását, táblák közötti kapcsolatok meghatározását és reaktív lekérdezések futtatását Flow és LiveData segítségével. A szinkronizáláshoz a NetworkType.CONNECTED korlátozással ellátott WorkManager-t használják.
iOS-en a helyi tároláshoz Core Data-t vagy SwiftData-t (az Apple új keretrendszerét) használják. Szinkronizáláshoz — CloudKit-et vagy egyedi implementációt URLSession segítségével háttérfeladatokkal. A Firebase mindkét platformhoz kész Offline-First megoldást kínál: a Firebase Realtime Database és a Firestore automatikusan helyileg tárolja az adatokat és szinkronizálja azokat a kapcsolat helyreállásakor. A fejlesztőnek nem kell szinkronizálási és konfliktusfeloldó kódot írnia — a Firebase ezt alapértelmezetten, Last-Write-Wins irányelvvel végzi.
Webalkalmazásokhoz a kulcsfontosságú eszköz a Service Worker, amely elfogja a HTTP-kéréseket, és válaszokat adhat vissza a győrűtárból (Cache API). A Google Workbox-ja leegyszerűsíti a Service Worker megvalósítását kész győrűtési stratégiákkal: Cache First, Network First, Stale-While-Revalidate. Az IndexedDB strukturált adatok böngészőben történő tárolására szolgál. Az olyan könyvtárak, mint az RxDB és a PouchDB, teljes Offline-First adatbázist biztosítanak replikációval a szerver felé a CouchDB-n keresztül.
| Platform | Helyi tárolás | Szinkronizálás |
|---|---|---|
| Android | Room, SQLite, DataStore | WorkManager + SyncAdapter |
| iOS | Core Data, SwiftData, SQLite | CloudKit, URLSession Background |
| Web (PWA) | IndexedDB, Cache API, localStorage | Service Worker + Background Sync API |
| Cross-platform | Firestore, Realm, Couchbase Lite | Firebase Sync, CouchDB Replication |
Eszközök kiválasztása a projekttől függően
Ritka szinkronizálású egyszerű alkalmazásokhoz a Room + WorkManager megfelelő. Összetett, több felhasználós és magas konzisztenciakövetelményekkel rendelkező rendszerekhez — Firestore a beépített Offline-First támogatásával. Hibrid webalkalmazásokhoz — IndexedDB + Workbox. Az eszközök kiválasztása az adatok összetettségétől, a konzisztenciakövetelményektől, a szinkronizálási mennyiségtől és a fejlesztői csapattól függ.
Adatszinkronizálás és konfliktuskezelés
A szinkronizálás — az Offline-First architektúra legösszetettebb része. Amikor a felhasználó offline módban módosít adatokat, és egy másik eszköz online módosítja ugyanazokat az adatokat, a kapcsolat helyreállásakor konfliktus keletkezik. Last-Write-Wins (LWW) — a legegyszerűbb stratégia: az időben utolsó írás nyer. Ezt használja a Firebase alapértelmezésben, és a legtöbb alkalmazáshoz alkalmas, ahol egy adatverzió elvesztése nem kritikus. Az LWW azonban változtatások elvesztéséhez vezethet, ha a felhasználó hosszú ideig offline volt.
Multi-Version Concurrency Control (MVCC) — összetettebb megközelítés, ahol az adatok mindkét verziója tárolódik, és a felhasználó kiválaszthatja a helyeset. Ezt a megközelítést használják a kollaboratív szerkesztőrendszerek (Google Docs, Notion). Az MVCC megvalósításához eszközórák szinkronizálására (NTP) vagy ok-okozati összefüggések meghatározásához vektorórák használatára van szükség. CRDT (Conflict-Free Replicated Data Types) — matematikai megközelítés, amely garantálja a konfliktusok hiányát speciális adatstruktúráknak köszönhetően, amelyek információveszteség nélkül összevonhatók. A CRDT-t a Figma és a SoundCloud használja.
Mobilalkalmazásokhoz ajánlott az LWW-vel kezdeni, és szükség szerint összetettebb stratégiákat hozzáadni. A szinkronizálási algoritmus általában így néz ki: az alkalmazás tárolja az utolsó szinkronizálás időbélyegét minden rekordhoz. A kapcsolat helyreállásakor a változtatások tömbje az időbélyeggel együtt kerül elküldésre. A szerver visszaküldi a megadott időbélyeg után történt változtatások tömbjét. Minden konfliktusos mezőre a kiválasztott stratégia kerül alkalmazásra. A szinkronizálás befejezése után az időbélyeg frissül.
Műveleti sor (Operation Queue)
Az Offline-First architektúrában az összes írási művelet (CREATE, UPDATE, DELETE) először a műveleti sorba kerül. A művelet tartalmazza a típust, a rekord azonosítóját, az adatokat és az időbélyeget. Ha a hálózat elérhető, a művelet azonnal végrehajtódik. Ha nem érhető el — a helyi sorban tárolódik. A hálózat helyreállásakor a WorkManager vagy a BackgroundTask FIFO sorrendben dolgozza fel a sort. A sikeres műveletek eltávolításra kerülnek a sorból, a sikertelenek — exponenciális késleltetéssel megismétlődnek. Ez garantálja, hogy a felhasználó egyetlen változtatása sem vész el.
Offline-First Android-alkalmazásokban
Az Android platformon az Offline-First megvalósítása három kulcsfontosságú összetevő köré épül: a Room a helyi tároláshoz, a WorkManager a háttérszinkronizáláshoz és a ConnectivityManager a hálózat állapotának figyeléséhez. A Room reaktív hozzáférést biztosít az adatokhoz Flow-n keresztül: a UI feliratkozik az adatbázis változásaira és automatikusan frissül bármilyen változáskor. A WorkManager NetworkType.CONNECTED korlátozással ütemezi a szinkronizálási feladatot, hogy az csak internetkapcsolat esetén hajtódjék végre.
Az Offline-First tipikus forgatókönyve Androidon: a felhasználó rekordot hoz létre az alkalmazásban. Az adatok a Repository-n keresztül a Room-ban tárolódnak. A Repository visszaküldi a Flow-t a frissített adatokkal, és a UI azonnal megjeleníti az új rekordot. Ezzel párhuzamosan a Repository szinkronizálási feladatot helyez a WorkManager-be. Ha a hálózat elérhető, a WorkManager POST-kérést küld a szervernek. Ha a szerver hibát ad vissza vagy a hálózat nem érhető el, a feladat később megismétlődik. A felhasználó szinkronizálási jelzőt (felhő ikon nyíllal) lát az új rekordok mellett.
A reaktivitáshoz a Repository + Flow mintát használják. A Repository elrejti a szinkronizálás részleteit a ViewModel elől: a ViewModel feliratkozik a Room Flow-jára és frissíti a UI-t. A Repository meghívja az API-t és elmenti az eredményt a Room-ban. A UI nem tudja, hogy az adatok a helyi adatbázisból vagy a szerverről származnak — csak reagál a Flow változásaira. Ez lehetővé teszi a szinkronizálási stratégia megváltoztatását a UI kódjának módosítása nélkül. A Room automatikusan értesíti a Flow-t a változásokról a LiveData/Flow annotációknak köszönhetően.
kotlin
class NotesRepository(
private val localDb: NoteDao,
private val api: NotesApi,
private val syncManager: SyncManager
) {
val notes: Flow<List<Note>> = localDb.getAllNotes()
suspend fun createNote(text: String) {
val note = Note(text = text, synced = false)
localDb.insert(note)
syncManager.enqueueSync()
}
}Offline-First Jetpack Compose-zal
A Jetpack Compose-ban az Offline-First a ViewModel-ből a Composable függvényekbe irányuló StateFlow-n keresztül valósul meg. A ViewModel Flow-t kap a Repository-ból, stateIn() segítségével StateFlow-vá alakítja és továbbítja a Compose-nak. Amikor a Room módosítja az adatokat, a Flow új értéket bocsát ki, a StateFlow frissül, és a Compose csak a megváltozott elemeket rajzolja újra. Ez reaktív UI-t biztosít minimális erőfeszítéssel és a listák manuális frissítése nélkül a szinkronizálás után.
Gyakori hibák az Offline-First használatakor
A leggyakoribb hiba — a győrűtés használata a teljes Offline-First architektúra helyett. A fejlesztők hozzáadják a Room-ot vagy a Core Data-t, de továbbra is először az API-t hívják, és az eredményt másolatként mentik az adatbázisba. Hálózat hiányában az alkalmazás helyettesítő képet vagy üres képernyőt jelenít meg, mert az adatok soha nem lettek betöltve. Helyes megközelítés — mindig a helyi adatbázisból olvasni az adatokat, és az API-válaszokat csak az adatbázis frissítéséhez használni. Ha az adatbázis üres az első indításkor — az alkalmazásnak be kell töltenie az adatokat a szerverről, helyileg elmentenie, és csak azután megjelenítenie.
Második hiba — a szinkronizálási konfliktusok figyelmen kívül hagyása. A fejlesztők gyakran támaszkodnak az alapértelmezett Last-Write-Wins-re anélkül, hogy figyelembe vennék azokat a forgatókönyveket, ahol a felhasználó fontos adatokat veszíthet. Ha az alkalmazás lehetővé teszi ugyanazon rekordok szerkesztését több eszközről, szükséges legalább alapvető konfliktusfeloldást megvalósítani a felhasználó értesítésével. A Firebase Firestore automatikusan megoldja ezt a problémát, de az egyedi megvalósítás gondos tervezést igényel.
Harmadik probléma — a hálózati állapot figyelmen kívül hagyása. Az alkalmazásnak helyesen kell kezelnie az online-ról offline-ra és vissza történő átmenetet. Ha a felhasználó elküldött egy űrllapot, és a kapcsolat megszakadt, az adatokat a műveleti sorban kell tárolni, nem elveszíteni. Az Android ConnectivityManager-je és az iOS NWPathMonitor-ja valós idejű hálózati változáskövetést tesz lehetővé. Az alkalmazásnak egyértelmű UI-t kell mutatnia: ha az adatok nincsenek szinkronizálva — „szinkronizálás várakozás” ikon, ha nincs hálózat — „offline” ikon. Ez kezeli a felhasználói elvárásokat és csökkenti a hamis támogatási megkeresések számát.
Memória és teljesítményproblémák
Az Offline-First architektúra memóriaproblémákhoz vezethet, ha a helyi adatbázis ellenőrizetlenül növekszik. A szerverről betöltött összes adat helyileg tárolódik, és ha nincs tisztítási irányelv beállítva, az adatbázis mérete elérheti a több száz megabájtot. Ajánlott TTL (time-to-live) beállítása a győrűtött adatokhoz, régi rekordok törlése szinkronizáláskor és lapozó használata nagy listák betöltéséhez. A Room COUNT és DELETE aggregált függvényeket biztosít az adatbázis méretének kezeléséhez.
Gyakran ismételt kérdések
Mi a különbség az Offline-First és a Cache-First között?
Offline-First — a helyi adatok az igazság forrásai, az alkalmazás teljesen működik hálózat nélkül. Cache-First — a győrűtárat gyorsításra használják, de az igazság forrása a szerver. Az Offline-First-ben a felhasználó hálózat nélkül is létrehozhat és szerkeszthet adatokat, a Cache-First-ben — csak a korábban betöltött adatokat tekintheti meg. Az Offline-First összetett szinkronizálást igényel, a Cache-First — nem.
Hogyan kezeljük a szinkronizálási konfliktusokat az Offline-First-ben?
Az alapstratégia — Last-Write-Wins (az utolsó írás nyer). Összetettebb forgatókönyvekhez — MVCC verzióválasztó felülettel vagy CRDT (Conflict-Free Replicated Data Types), amely matematikailag garantálja a konfliktusok hiányát. A stratégia kiválasztása az adatok kritikusságától és a megvalósítás összetettségétől függ.
Milyen adatokat nem szabad csak helyileg tárolni?
A kritikus adatok, amelyek nem veszhetnek el az alkalmazás eltávolításakor vagy az eszköz meghibásodásakor, szerveroldali tárolást igényelnek. Hitelesítési tokenek, fizetési adatok, rendelési előzmények — duplikálni kell a szerveren. Az Offline-First nem azt jelenti, hogy „csak helyileg” — azt jelenti, hogy „helyileg mint elsődleges tároló, szerver replikával”.
Hogyan teszteljük az Offline-First alkalmazást?
Használjon Network Call Manager-t a hálózat elvesztésének emulálásához, Throttling és Repülőmód használatát az emulátorban. Tesztelje a forgatókönyveket: adatok létrehozása hálózat nélkül, szinkronizálás helyreálláskor, konfliktusok párhuzamos szerkesztésnél. Az Android NetworkBehavior-t biztosít a Robolectric-ben, az iOS OHHTTPStubs-t a hálózati hibák szimulálásához. Az integrációs teszteknek ellenőrizniük kell a műveleti sort és a konfliktusfeloldást.
Mikor nem érdemes Offline-First-t használni?
Az Offline-First túlzás azoknál az alkalmazásoknál, ahol az adatoknak mindig naprakésznek kell lenniük — például tőzsdei árfolyamok, online térképek vagy felügyeleti rendszerek. Ha a felhasználó soha nem használja az alkalmazást internet nélkül, és az adatok konzisztenciája kritikus, a betöltő indikátorokkal ellátott Online-Only architektúra egyszerűbb és megbízhatóbb.
Összefoglalás
- Offline-First — fejlesztési stratégia, ahol a helyi tároló az igazság forrása, a szerver pedig replika a szinkronizáláshoz.
- Helyi igazság forrása — az adatok először az eszközön tárolódnak (Room, Core Data, IndexedDB), majd szinkronizálódnak a szerverrel.
- Háttérszinkronizálás — WorkManager (Android), BackgroundTask (iOS), Service Worker (Web) elküldi a változtatásokat a hálózat rendelkezésre állásakor.
- Konfliktuskezelés — Last-Write-Wins, MVCC vagy CRDT a különböző eszközökön offline módban végzett változtatások összehangolására.
- Műveleti sor — garantálja, hogy a felhasználó egyetlen változtatása sem vész el: a műveletek helyileg tárolódnak és a kapcsolat helyreállásakor hajtódnak végre.
- Reaktív UI — Flow (Android) vagy Combine (iOS) segítségével a UI feliratkozik a helyi adatbázisra és automatikusan frissül bármilyen változáskor.
- Gyakori hibák — összetévesztés a győrűtéssel, konfliktusok figyelmen kívül hagyása, hálózati állapot figyelmen kívül hagyása és a helyi adatbázis ellenőrizetlen növekedése.
Kulcsrakész mobilalkalmazást fejlesztünk
Az IT Sectr 2017 óta készít iOS és Android alkalmazásokat induló vállalkozásoknak és vállalkozásoknak. Tanácsot adunk, és a legjobb megoldást javasoljuk.
Olvassa el is