Offline-First mobil tətbiq hazırlamasında — bu nədir, prinsipləri və iş strategiyası
Offline-First mobil vę veb tətbiqlərinin hazırlanması strategiyasıdır. Bu yanaşmada tətbiq əvvəlcə lokal məlumat anbarına müraciət edir, sonra isə fon rejimində serverlə sinxronlaşır. İnternet olmadıqda belə istifadəçi interfeysi dərhal görür və məlumatlar əlaqə bərpa olunduqda avtomatik sinxronlaşır. Google Developers, 2025 məlumatlarına görə, Offline-First yanaşması qeyri-sabit şəbəkə şəraitində stabil iş sayəsində istifadəçi fəallığını 20-40% artırır.
Başlıca məqamlar
- Offline-First — lokal məlumatların şəbəkə sorğularından üstün olduğu strategiya.
- Lokal yaddaş — cihazdakı keş (Room, SQLite, DataStore) məlumatlara ani girişi təmin edir.
- Fon sinxronizasiyası — dəyişikliklər şəbəkə əlaqəsi bərpa olunduqda serverə göndərilir.
- Konfliktlərin idarə edilməsi — lokal və server məlumatlarını uzlaşdırmaq üçün Last-Write-Wins və ya CRDT yanaşmaları.
- Service Worker — veb tətbiqlərdə və Progressive Web Apps-də Offline-First-in əsas komponenti.
Offline-First nədir?
Offline-First — tətbiqlərin hazırlanmasında memarlıq yanaşmasıdır. Burada lokal məlumat saxlama və emalı əsas, şəbəkə sorğuları isə ikinci dərəcəlidir. Ənənəvi Online-Only yanaşmasından fərqli olaraq, burada tətbiq əvvəlcə lokal keşdən və ya verilənlər bazasından məlumatları oxuyur, dərhal istifadəçiyə göstərir və yalnız sonra fon rejimində serverlə sinxronlaşır. Bu, istifadəçi təcrübəsini tamamilə dəyişir: ekranlar internet sürətindən asılı olmayaraq millisaniyələr ərzində yüklənir.
Offline-First konsepsiyası mobil trafikin artması və qeyri-sabit interneti olan regionlarda tətbiqlərin yayılması ilə populyarlıq qazanır. Google I/O 2025 məlumatlarına görə, mobil tətbiq istifadəçilərinin 60%-dən çoxu gündə ən azı bir dəfə şəbəkə əlaqəsi problemləri ilə qarşılaşır. Offline-First bu problemi həll edir və tətbiqi şəbəkəyə çıxış olmadan tam funksional edir. İstifadəçi məlumatları yarada, redaktə edə və silə bilər — bütün dəyişikliklər lokal olaraq saxlanılır və əlaqə bərpa olunduqda sinxronlaşdırılır.
Offline-First sadə keşləmədən fərqləndirilməlidir. Keşləmədə məlumatlar əvvəlcə serverdən yüklənir, sonra lokal olaraq surət kimi saxlanılır. Offline-First-də lokal yaddaş həqiqət mənbəyidir (source of truth). İstifadəçi lokal məlumatlarla qarşılıqlı əlaqədə olur, server isə replikadır. Şəbəkə olmadıqda tətbiq tam həcmdə işləyir. Şəbəkə olduqda dəyişikliklər fonda sinxronlaşır. Bu yanaşma daha mürəkkəb arxitektura tələb edir, lakin keyfiyyətcə fərqli istifadəçi təcrübəsi verir.
Offline-First vs Online-Only vs Offline-Only
Tətbiqlərdə məlumatlarla iş üçün üç yanaşma mövcuddur. Online-Only — tətbiq internetsiz işləmir, bütün məlumatlar serverdə saxlanılır. Offline-Only — tətbiq tamamilə lokal işləyir, serverlə sinxronizasiya yoxdur. Offline-First — hibrid: lokal məlumatlar həqiqət mənbəyi kimi, server replika kimi ehtiyat və birgə giriş üçün. Hər bir yanaşmanın tətbiq sahəsi var: Online-Only bank əməliyyatları üçün, Offline-Only kalkulyatorlar üçün, Offline-First sosial şəbəkələr, qeydlər, tapşırıqlar və mesajlaşma tətbiqləri üçün uyğundur.
Offline-First strategiyasının prinsipləri
Offline-First arxitekturası dörd əsas prinsip üzərində qurulur. Lokal həqiqət mənbəyi — bütün məlumatlar əvvəlcə lokal verilənlər bazasında saxlanılır, sonra serverə göndərilir. İstifadəçi həmişə lokal yaddaşdakı aktual məlumatları görür və bu, interfeysin ani reaksiyasını təmin edir. Tətbiq məlumatları göstərmək üçün heç vaxt serverdən cavab gözləmir — bu, yüklənmə göstəriciləri olan ənənəvi REST müştərilərindən əsas fərqdir.
Fon sinxronizasiyası — məlumatları lokal saxlamaqdan sonra tətbiq sinxronizasiya tapşırığı təyin edir. Şəbəkə varsa, dəyişikliklər dərhal serverə göndərilir. Şəbəkə yoxdursa, tapşırıq növbədə saxlanılır və əlaqə bərpa olunduqda icra edilir. Android WorkManager və iOS BGProcessingTask bu prinsipin tətbiqi üçün standart alətlərdir. Konfliktlərin həlli — sinxronizasiya zamanı eyni məlumatlar müxtəlif cihazlarda dəyişdirilibsə, konfliktlər yarana bilər. Həll strategiyaları: Last-Write-Wins, Multi-Version Concurrency Control və ya CRDT.
Adaptiv interfeys — tətbiq istifadəçini sinxronizasiya vəziyyəti barədə məlumatlandırmalı, lakin offline rejimində işi bloklamamalıdır. Əlaqə statusu ikonası, sinxronlaşdırılmamış dəyişikliklərin sayı və sinxronizasiyanın bitməsi barədə bildirişlər Offline-First tətbiqləri üçün məcburi UX elementləridir. Veb tətbiqlərdə Service Worker və mobil tətbiqlərdə Network Manager şəbəkə vəziyyətini izləyir və məlumat göndərilməsini idarə edir.
Cache-First vs API-First vs Offline-First
Cache-First — tətbiq əvvəlcə keşi yoxlayır, lakin məlumat yoxdursa, serverə sorğu göndərir. Bu, sinxronizasiya növbəsi və konfliktlərin həlli olmadan Offline-First-in sadələşdirilmiş versiyasıdır. API-First — tətbiq həmişə serverdən məlumat tələb edir, keş yalnız şəbəkə olmadıqda ehtiyat kimi istifadə olunur. Offline-First — ən mürəkkəb, lakin ən etibarlı yanaşmadır, şəbəkəsiz tam funksionallıq və sinxronizasiya zamanı məlumat uyğuluğu təmin edir.
Offline-First tətbiqi üçün alətlər
Müasir platformalar Offline-First tətbiqləri qurmaq üçün alətlər dəsti təklif edir. Android-də lokal yaddaşın əsas aləti Room — SQLite əsaslı kitabxanadır. Room mürəkkəb obyektləri saxlamağa, cədvəllər arasında əlaqələri təyin etməyə və Flow və LiveData vasitəsilə reaktiv sorğuları yerinə yetirməyə imkan verir. Sinxronizasiya üçün NetworkType.CONNECTED məhdudiyyəti ilə WorkManager istifadə olunur.
iOS-da lokal yaddaş üçün Core Data və ya SwiftData (Apple-dan yeni framework) istifadə olunur. Sinxronizasiya üçün — CloudKit və ya fon tapşırıqları ilə URLSession vasitəsilə şəxsi tətbiq. Firebase hər iki platforma üçün hazır Offline-First həlli təklif edir: Firebase Realtime Database və Firestore avtomatik olaraq məlumatları lokal saxlayır və əlaqə yarananda sinxronlaşdırır. Tərtibatçı sinxronizasiya və konflikt həlli kodu yazmalı deyil — Firebase bunu Last-Write-Wins siyasəti ilə standart olaraq edir.
Veb tətbiqlər üçün əsas alət Service Worker-dir. O, HTTP sorğularını kəsir və keşdən cavabları qaytara bilər (Cache API). Google-dan Workbox hazır keşləmə strategiyaları ilə Service Worker tətbiqini sadələşdirir: Cache First, Network First, Stale-While-Revalidate. IndexedDB brauzerdə strukturlaşdırılmış məlumatları saxlamaq üçün istifadə olunur. RxDB və PouchDB kimi kitabxanalar CouchDB vasitəsilə serverə replikasiya ilə tam Offline-First verilənlər bazası təmin edir.
| Platforma | Lokal yaddaş | Sinxronizasiya |
|---|---|---|
| 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 |
Layihədən asılı olaraq alətlərin seçilməsi
Sadə tətbiqlər və seyrək sinxronizasiya üçün Room + WorkManager kifayətdir. Çoxlu istifadəçisi və yüksək uyğuluq tələbləri olan mürəkkəb sistemlər üçün Firestore daxili Offline-First dəstəyi ilə uyğundur. Hibrid veb tətbiqlər üçün — IndexedDB + Workbox. Alətlərin seçimi məlumatların mürəkkəbliyindən, uyğuluq tələblərindən, sinxronizasiya həcmindən və tərtibatçı komandasından asılıdır.
Məlumatların sinxronizasiyası və konfliktlərin idarə edilməsi
Sinxronizasiya Offline-First arxitekturasının ən çətin hissəsidir. İstifadəçi offline rejimində məlumatları dəyişdirir, digər cihaz isə eyni məlumatları online dəyişdirirsə, əlaqə bərpa olunduqda konflikt yaranır. Last-Write-Wins (LWW) — ən sadə strategiya: zamanca son yazı qalib gəlir. Firebase-də standart olaraq istifadə olunur və məlumatların bir versiyasının itirilməsinin kritik olmadığı tətbiqlərin əksəriyyəti üçün uyğundur. Lakin LWW istifadəçi uzun müddət offline olduqda dəyişikliklərin itirilməsinə səbəb ola bilər.
Multi-Version Concurrency Control (MVCC) — hər iki məlumat versiyasının saxlanıldığı və istifadəçiyə düzgünü seçmək təklif edilən daha mürəkkəb yanaşmadır. Bu yanaşma birgə redaktə sistemlərində (Google Docs, Notion) istifadə olunur. MVCC tətbiqi üçün cihaz saatlarının sinxronizasiyası (NTP) və ya səbəb-nəticə əlaqələrini təyin etmək üçün vektor saatları tələb olunur. CRDT (Conflict-Free Replicated Data Types) — məlumat itkisi olmadan birləşdirilə bilən xüsusi struktur məlumatları sayəsində konfliktlərin olmamasını riyazi olaraq təmin edən yanaşmadır. CRDT Figma və SoundCloud-da istifadə olunur.
Mobil tətbiqlər üçün LWW-dən başlamaq və zərurət olduqca daha mürəkkəb strategiyalar əlavə etmək tövsiyyə olunur. Sinxronizasiya alqoritmi adətən belədir: tətbiq hər qeyd üçün son sinxronizasiya vaxtını (timestamp) saxlayır. Əlaqə bərpa olunduqda timestamp ilə dəyişikliklər massivi göndərilir. Server göstərilən timestamp-dən sonra serverdə baş vermiş dəyişikliklər massivini qaytarır. Hər bir konfliktli sahə üçün seçilmiş strategiya tətbiq edilir. Sinxronizasiya bitdikdən sonra timestamp yenilənir.
Əməliyyat növbəsi (Operation Queue)
Offline-First arxitekturasında bütün yazma əməliyyatları (CREATE, UPDATE, DELETE) əvvəlcə əməliyyat növbəsinə daxil olur. Əməliyyat tip, qeyd identifikatoru, məlumatlar və timestamp ehtiva edir. Şəbəkə varsa, əməliyyat dərhal icra olunur. Yoxdursa — lokal növbədə saxlanılır. Şəbəkə bərpa olunduqda WorkManager və ya BackgroundTask növbəni FIFO ardıcıllığı ilə emal edir. Uğur əməliyyatlar növbədən silinir, uğursuzlar — eksponensial gecikmə ilə təkrarlanır. Bu, istifadəçinin heç bir dəyişikliyinin itirilməyəcəyini təmin edir.
Android tətbiqlərində Offline-First
Android platformasında Offline-First tətbiqi üç əsas komponent ətrafında qurulur: lokal yaddaş üçün Room, fon sinxronizasiyası üçün WorkManager və şəbəkə vəziyyətini izləmək üçün ConnectivityManager. Room məlumatlara reaktiv girişi Flow vasitəsilə təmin edir: UI verilənlər bazasındakı dəyişikliklərə abunə olur və hər dəfə avtomatik yenilənir. WorkManager NetworkType.CONNECTED məhdudiyyəti ilə sinxronizasiya tapşırığı planlaşdırır.
Android-də tipik Offline-First ssenarisi: istifadəçi tətbiqdə qeyd yaradır. Məlumatlar repository vasitəsilə Room-da saxlanılır. Repository yenilənmiş məlumatlarla Flow qaytarır və UI dərhal yeni qeydi göstərir. Paralel olaraq repository WorkManager-də sinxronizasiya tapşırığı təyin edir. Şəbəkə varsa, WorkManager serverə POST sorğu göndərir. Server xəta qaytarırsa və ya şəbəkə yoxdursa, tapşırıq sonra təkrarlanır. İstifadəçi yeni qeydlərin yanında sinxronizasiya göstəricisini (oxlu bulud ikonası) görür.
Reaktivlik üçün Repository + Flow nümunəsi istifadə olunur. Repository sinxronizasiya detallarını ViewModel-dən gizlədir: ViewModel Room-dan Flow-a abunə olur və UI-ni yeniləyir. Repository API-ni çağırır və nəticəni Room-da saxlayır. UI məlumatların lokal bazadan və ya serverdən alındığını bilmir — sadəcə Flow-dakı dəyişikliklərə reaksiya verir. Bu, sinxronizasiya strategiyasını UI kodunu dəyişmədən dəyişməyə imkan verir. Room LiveData/Flow annotasiyaları sayəsində Flow-u avtomatik xəbərdar edir.
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()
}
}Jetpack Compose ilə Offline-First
Jetpack Compose-da Offline-First ViewModel-dən Composable funksiyalarına StateFlow vasitəsilə tətbiq edilir. ViewModel repository-dən Flow alır, stateIn() vasitəsilə StateFlow-a çevirir və Compose-a ötürür. Room məlumatları dəyişdikdə, Flow yeni dəyər göndərir, StateFlow yenilənir və Compose yalnız dəyişmiş elementləri yenidən çəkir. Bu, minimal səylə və sinxronizasiyadan sonra siyahıların əl ilə yenilənməsi olmadan reaktiv UI təmin edir.
Offline-First-də tipik səhvlər
Ən geniş yayılmış səhv — tam Offline-First arxitekturası əvəzinə keşləmədən istifadə etməkdir. Tərtibatçılar Room və ya Core Data əlavə edir, lakin yenə də əvvəlcə API-ni çağırır və nəticəni verilənlər bazasına surət kimi yazır. Şəbəkə olmadıqda tətbiq boş ekran göstərir, çünki məlumatlar heç vaxt yüklɔnməyib. Düzgün yanaşma — həmişə məlumatları lokal bazadan oxumaq və API cavablarını yalnız bu bazanı yeniləmək üçün istifadə etməkdir. İlk işə salınmada baza boşdursa, tətbiq serverdən məlumat yükləməli, lokal saxlmalı və sonra göstərməlidir.
İkinci səhv — sinxronizasiya konfliktlərinə məhəl qoymamaqdır. Tərtibatçılar çox vaxt standart Last-Write-Wins-ə etibar edir, istifadəçinin vacib məlumatları itirə biləcəyi ssenariləri nəzərə almır. Tətbiq eyni qeydləri bir neçə cihazdan redaktə etməyə imkan verirsə, istifadəçini xəbərdar edən ən azından əsas konflikt həllini tətbiq etmək vacibdir. Firebase Firestore bu problemi avtomatik həll edir, lakin şəxsi tətbiq diqqətli layihələndirmə tələb edir.
Üçüncü problem — şəbəkə vəziyyətinin nəzərə alınmamasıdır. Tətbiq online-dan offline-a və geri keçidi düzgün idarə etməlidir. İstifadəçi formanı göndərib, əlaqə kəsilibsə, məlumatlar əməliyyat növbəsində saxlanmalı, itirilməməlidir. Android-də ConnectivityManager və iOS-da NWPathMonitor şəbəkə dəyişikliklərini real vaxtda izləməyə imkan verir. Tətbiq başa düşülən UI göstərməlidir: məlumatlar sinxronlaşdırılmayıbsa — "sinxronizasiya gözlənilir" ikonu, şəbəkə yoxdursa — "offline" ikonu. Bu, istifadəçinin gözləntilərini idarə edir və dəstək xidmətinə yalançı müraciətlərin sayını azaldır.
Yaddaş və performans problemləri
Offline-First arxitekturası lokal verilənlər bazası nəzarətsiz böyüdükdə yaddaş problemlərinə səbəb ola bilər. Serverdən yüklənən bütün məlumatlar lokal saxlanılır və təmizləmə siyasəti qurulmayıbsa, baza ölçüsü yüzlər meqabayta çata bilər. Keşləşdirilmiş məlumatlar üçün TTL (time-to-live) qurmaq, sinxronizasiya zamanı köhnə qeydləri silmək və böyük siyahıları yükləmək üçün paginasiyadan istifadə etmək tövsiyyə olunur. Room baza ölçüsünü idarə etmək üçün COUNT və DELETE aqreqat funksiyaları təmin edir.
Tez-tez verilən suallar
Offline-First və Cache-First arasında nə fərq var?
Offline-First — lokal məlumatlar həqiqət mənbəyidir, tətbiq şəbəkəsiz tam işləyir. Cache-First — keş sürətləndirmə üçün istifadə olunur, lakin həqiqət mənbəyi serverdir. Offline-First-də istifadəçi şəbəkəsiz məlumatları yarada və redaktə edə bilər, Cache-First-də isə yalnız əvvəlcə yüklənmiş məlumatlara baxa bilər. Offline-First mürəkkəb sinxronizasiya tələb edir, Cache-First isə yox.
Offline-First-də sinxronizasiya konfliktlərini necə idarə etməli?
Əsas strategiya — Last-Write-Wins (son yazı qalib gəlir). Daha mürəkkəb ssenarilər üçün — istifadəçi üçün versiya seçimi interfeysi ilə MVCC və ya riyazi olaraq konfliktlərin olmamasını təmin edən CRDT (Conflict-Free Replicated Data Types). Strategiyanın seçimi məlumatların kritikliyindən və tətbiqin mürəkkəbliyindən asılıdır.
Hansı məlumatları yalnız lokal saxlamaq olmaz?
Kritik məlumatlar — tətbiq silindikdə və ya cihaz xətası zamanı itirilməməli olan məlumatlar serverdə saxlanmalıdır. Avtorizasiya tokenləri, ödəniş məlumatları, sifariş tarixçəsi serverdə təkrarlanmalıdır. Offline-First "yalnız lokal" demək deyil — "server replikası ilə əsas yaddaş kimi lokal" deməkdir.
Offline-First tətbiqini necə test etməli?
Şəbəkə itkisini emulyasiya etmək üçün Network Call Manager, Throttling və emulyatorda Təyyarə rejimindən istifadə edin. Ssenariləri test edin: şəbəkəsiz məlumat yaratma, bərpa zamanı sinxronizasiya, paralel redaktə zamanı konfliktlər. Android Robolectric-də NetworkBehavior təmin edir, iOS-da şəbəkə xətalarını simulyasiya etmək üçün OHHTTPStubs var. İnteqrasiya testləri əməliyyat növbəsini və konflikt həllini yoxlamalıdır.
Offline-First-dən nə vaxt istifadə etməməli?
Offline-First məlumatların həmişə aktual olmalı olduğu tətbiqlər üçün artıqdır — məsələn, birja kotirovkaları, online xəritələr və ya monitorinq sistemləri. İstifadəçi tətbiqi heç vaxt internetsiz işlətmirsə və məlumat uyğuluğu kritikdirsə, yüklənmə göstəriciləri ilə Online-Only arxitekturasından istifadə etmək daha sadə və etibarlıdır.
Nəticə
- Offline-First — lokal yaddaşın həqiqət mənbəyi, serverin isə sinxronizasiya üçün replika olduğu hazırlama strategiyası.
- Lokal həqiqət mənbəyi — məlumatlar əvvəlcə cihazda (Room, Core Data, IndexedDB) saxlanılır, sonra serverlə sinxronlaşdırılır.
- Fon sinxronizasiyası — WorkManager (Android), BackgroundTask (iOS), Service Worker (Web) şəbəkə yarananda dəyişiklikləri göndərir.
- Konfliktlərin idarə edilməsi — Last-Write-Wins, MVCC və ya CRDT müxtəlif cihazlarda offline rejimində yerinə yetirilən dəyişiklikləri uzlaşdırmaq üçün.
- Əməliyyat növbəsi — istifadəçinin heç bir dəyişikliyinin itirilməyəcəyini təmin edir: əməliyyatlar lokal saxlanılır və əlaqə bərpa olunduqda icra edilir.
- Reaktiv UI — Flow (Android) və ya Combine (iOS) vasitəsilə UI lokal verilənlər bazasına abunə olur və hər dəyişiklikdə avtomatik yenilənir.
- Tipik səhvlər — keşləmə ilə qarışdırma, konfliktlərə məhəl qoymama, şəbəkə vəziyyətini nəzərə almama və lokal verilənlər bazasının nəzarətsiz böyüməsi.
Açar təslim mobil tətbiq hazırlayacağıq
IT Sectr 2017-ci ildən startaplar və bizneslər üçün iOS və Android tətbiqləri yaradır. Sizə məsləhət verəcəyik və ən yaxşı həlli təklif edəcəyik.
Həm də oxuyun