Mobil geliştirmede Offline-First — nedir, ilkeleri ve çalışma stratejisi
Offline-First, uygulamanın önce yerel veri deposuna eriştiği ve ardından arka planda sunucu ile senkronize olduğu bir mobil ve web uygulama geliştirme stratejisidir. Kullanıcı, internet bağlantısı olmasa bile arayüzü anında görür ve bağlantı kurulduğunda veriler otomatik olarak senkronize olur. Google Developers, 2025'e göre, Offline-First yaklaşımı, kararsız ağ koşullarında kararlı çalışma sayesinde kullanıcı etkileşimini %20-40 oranında artırır.
Önemli Noktalar
- Offline-First — yerel verilerin ağ isteklerine göre öncelikli olduğu bir strateji.
- Yerel Depolama — cihazdaki önbellek (Room, SQLite, DataStore) verilere anında erişim sağlar.
- Arka Plan Senkronizasyonu — ağ bağlantısı geri geldiğinde değişiklikler sunucuya gönderilir.
- Çatışma Çözümü — yerel ve sunucu verilerini uzlaştırmak için Last-Write-Wins veya CRDT yaklaşımları.
- Service Worker — web uygulamaları ve Progressive Web Apps'ta Offline-First'in ana bileşeni.
Offline-First Nedir?
Offline-First, yerel veri depolama ve işlemenin birincil, ağ isteklerinin ise ikincil olduğu bir uygulama geliştirme mimari yaklaşımıdır. Uygulamanın sunucuya istek gönderip yanıt beklediği geleneksel Online-Only yaklaşımının aksine, Offline-First uygulaması önce yerel önbellekten veya veritabanından veri okur, anında kullanıcıya gösterir ve ancak daha sonra arka planda sunucu ile senkronize olur. Bu, kullanıcı deneyimini tamamen değiştirir: ekranlar internet hızından bağımsız olarak milisaniyeler içinde yüklenir.
Offline-First kavramı, mobil trafiğin artması ve istikrarsız internetli bölgelerde uygulamaların yaygınlaşmasıyla popülerlik kazanmaktadır. Google I/O 2025'e göre, mobil uygulama kullanıcılarının %60'ından fazlası günde en az bir kez ağ bağlantısı sorunlarıyla karşılaşmaktadır. Offline-First, uygulamayı internet erişimi olmadan tamamen işlevsel hale getirerek bu sorunu çözer. Kullanıcı veri oluşturabilir, düzenleyebilir ve silebilir — tüm değişiklikler yerel olarak kaydedilir ve bağlantı geri geldiğinde senkronize olur.
Offline-First, basit önbelleklemeden ayırt edilmelidir. Önbelleklemede, veriler önce sunucudan yüklenir ve ardından kopya olarak yerel olarak kaydedilir. Offline-First'te, yerel depolama gerçeğin kaynağıdır. Kullanıcı yerel verilerle etkileşime girer ve sunucu bir kopyadır. Ağ kullanılamıyorsa, uygulama tam olarak çalışmaya devam eder. Ağ mevcutsa, değişiklikler arka planda senkronize olur. Bu yaklaşım daha karmaşık bir mimari gerektirir ancak niteliksel olarak farklı bir kullanıcı deneyimi sağlar.
Offline-First vs Online-Only vs Offline-Only
Uygulamalarda verilerle çalışmak için üç yaklaşım vardır. Online-Only — uygulama internet olmadan çalışmaz, tüm veriler sunucuda depolanır. Offline-Only — uygulama tamamen yerel olarak çalışır, sunucu senkronizasyonu yoktur. Offline-First — bir hibrit: gerçeğin kaynağı olarak yerel veriler, yedekleme ve paylaşım için sunucu bir kopya olarak. Her yaklaşımın uygulama alanı vardır: Online-Only bankacılık işlemleri için uygundur, Offline-Only hesap makineleri için, Offline-First sosyal ağlar, notlar, görevler ve mesajlaşma için uygundur.
Offline-First Stratejisinin İlkeleri
Offline-First mimarisi dört temel ilke üzerine kurulmuştur. Yerel Gerçeğin Kaynağı — tüm veriler önce yerel veritabanına kaydedilir ve ancak sonra sunucuya gönderilir. Kullanıcı her zaman yerel depolamadan güncel verileri görür ve anında arayüz yanıtı sağlar. Uygulama, verileri görüntülemek için asla sunucu yanıtını beklemez — bu, yükleme göstergeleri olan geleneksel REST istemcilerinden temel bir farktır.
Arka Plan Senkronizasyonu — verileri yerel olarak kaydettikten sonra, uygulama bir senkronizasyon görevini sıraya koyar. Ağ mevcutsa, değişiklikler hemen sunucuya gönderilir. Ağ kullanılamıyorsa, görev bir kuyrukta saklanır ve bağlantı geri geldiğinde yürütülür. Android WorkManager ve iOS BGProcessingTask bu ilkeyi uygulamak için standart araçlardır. Çatışma Çözümü — aynı veriler farklı cihazlarda değiştirilmişse senkronizasyon sırasında çatışmalar ortaya çıkabilir. Çözüm stratejileri arasında Last-Write-Wins, Çok Sürümlü Eşzamanlılık Kontrolü veya CRDT bulunur.
Uyarlanabilir Arayüz — uygulama, kullanıcıya senkronizasyon durumu hakkında bilgi vermeli ancak çevrimdışı modda çalışmayı engellememelidir. Bağlantı durumu simgesi, senkronize edilmemiş değişikliklerin göstergesi ve senkronizasyon tamamlama bildirimleri, Offline-First uygulamaları için zorunlu UX öğeleridir. Web uygulamalarında Service Worker ve mobil uygulamalarda Network Manager ağ durumunu izler ve veri gönderimini yönetir.
Cache-First vs API-First vs Offline-First
Cache-First — uygulama önce önbelleği kontrol eder, ancak veri yoksa sunucuya istek gönderir. Bu, senkronizasyon kuyruğu ve çatışma çözümü olmayan Offline-First'in basitleştirilmiş bir versiyonudur. API-First — uygulama her zaman sunucudan veri ister, önbellek yalnızca ağ olmadığında yedek olarak kullanılır. Offline-First, en karmaşık ancak en güvenilir yaklaşımdır ve ağ olmadan tam işlevsellik ve senkronizasyon sırasında veri tutarlılığı sağlar.
Offline-First Uygulama Araçları
Modern platformlar, Offline-First uygulamaları oluşturmak için bir dizi araç sunar. Android'de ana yerel depolama aracı Room'dur — SQLite üzerinde, veritabanıyla çalışmak için tür güvenliği sağlayan bir API sunan bir kütüphane. Room, karmaşık nesneleri depolamaya, tablolar arasında ilişkiler tanımlamaya ve Flow ve LiveData aracılığıyla reaktif sorgular yürütmeye olanak tanır. Senkronizasyon için NetworkType.CONNECTED kısıtlamalarıyla WorkManager kullanılır.
iOS'te, yerel depolama için Core Data veya SwiftData (Apple'ın yeni framework'ü) kullanılır. Senkronizasyon için — CloudKit veya arka plan görevleriyle URLSession aracılığıyla özel uygulama. Firebase, her iki platform için hazır bir Offline-First çözümü sunar: Firebase Realtime Database ve Firestore, verileri otomatik olarak yerel olarak kaydeder ve bağlantı göründüğünde senkronize eder. Geliştiricinin senkronizasyon ve çatışma çözümü kodu yazması gerekmez — Firebase, varsayılan olarak Last-Write-Wins politikasıyla bunu yapar.
Web uygulamaları için ana araç, HTTP isteklerini yakalayan ve önbellekten (Cache API) yanıtlar döndürebilen Service Worker'dır. Google'ın Workbox'ı, hazır önbellekleme stratejileriyle (Cache First, Network First, Stale-While-Revalidate) Service Worker uygulamasını basitleştirir. IndexedDB, tarayıcıda yapılandırılmış verileri depolamak için kullanılır. RxDB ve PouchDB gibi kütüphaneler, CouchDB aracılığıyla sunucu çoğaltması olan tam teşekküllü bir Offline-First veritabanı sağlar.
| Platform | Yerel Depolama | Senkronizasyon |
|---|---|---|
| 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 |
| Platformlar Arası | Firestore, Realm, Couchbase Lite | Firebase Sync, CouchDB Replication |
Projeye Göre Araç Seçimi
Senkronizasyonu seyrek olan basit uygulamalar için Room + WorkManager uygundur. Çok sayıda kullanıcısı ve yüksek tutarlılık gereksinimleri olan karmaşık sistemler için — yerleşik Offline-First desteğiyle Firestore. Hibrit web uygulamaları için — IndexedDB + Workbox. Araçların seçimi, veri karmaşıklığına, tutarlılık gereksinimlerine, senkronizasyon hacmine ve geliştirme ekibine bağlıdır.
Veri Senkronizasyonu ve Çatışma Çözümü
Senkronizasyon, Offline-First mimarisinin en karmaşık kısmıdır. Bir kullanıcı çevrimdışı modda verileri değiştirdiğinde ve başka bir cihaz aynı verilerde çevrimiçi değişiklik yaptığında, bağlantı geri geldiğinde bir çatışma ortaya çıkar. Last-Write-Wins (LWW) en basit stratejidir: son yazma kazanır. Firebase'de varsayılan olarak kullanılır ve bir veri sürümünü kaybetmenin kritik olmadığı çoğu uygulama için uygundur. Ancak LWW, kullanıcı uzun süre çevrimdışı kaldıysa veri kaybına yol açabilir.
Çok Sürümlü Eşzamanlılık Kontrolü (MVCC), verilerin her iki sürümünün de depolandığı ve kullanıcıdan doğru olanı seçmesinin istendiği daha karmaşık bir yaklaşımdır. Bu yaklaşım, işbirlikçi düzenleme sistemlerinde (Google Docs, Notion) kullanılır. MVCC'yi uygulamak için, cihaz saatlerini (NTP) senkronize etmek veya neden-sonuç ilişkilerini belirlemek için vektör saatlerini kullanmak gerekir. CRDT (Çatışmasız Çoğaltılmış Veri Türleri), bilgi kaybı olmadan birleştirilebilen özel veri yapıları aracılığıyla çatışmaların olmadığını matematiksel olarak garanti eden bir yaklaşımdır. CRDT, Figma ve SoundCloud'da kullanılır.
Mobil uygulamalar için LWW ile başlamanız ve gerektiğinde daha karmaşık stratejiler eklemeniz önerilir. Senkronizasyon algoritması tipik olarak şu şekilde çalışır: uygulama her kayıt için son senkronizasyonun zaman damgasını saklar. Bağlantı geri geldiğinde, zaman damgalarıyla birlikte bir değişiklik dizisi gönderilir. Sunucu, belirtilen zaman damgasından sonra sunucuda meydana gelen değişikliklerin bir dizisini döndürür. Çatışan her alan için seçilen strateji uygulanır. Senkronizasyon tamamlandıktan sonra zaman damgası güncellenir.
İşlem Kuyruğu
Offline-First mimarisinde, tüm yazma işlemleri (CREATE, UPDATE, DELETE) önce bir işlem kuyruğuna girer. Bir işlem, türü, kayıt tanımlayıcısını, verileri ve zaman damgasını içerir. Ağ mevcutsa, işlem hemen yürütülür. Kullanılamıyorsa — yerel kuyrukta saklanır. Ağ geri geldiğinde, WorkManager veya BackgroundTask kuyruğu FIFO sırasıyla işler. Başarılı işlemler kuyruktan kaldırılır, başarısız olanlar üstel geri bildirimle yeniden denenir. Bu, kullanıcının hiçbir değişikliğinin kaybolmamasını garanti eder.
Android Uygulamalarında Offline-First
Android platformunda Offline-First uygulaması üç temel bileşen etrafında inşa edilmiştir: yerel depolama için Room, arka plan senkronizasyonu için WorkManager ve ağ durumu izleme için ConnectivityManager. Room, Flow aracılığıyla reaktif veri erişimi sağlar: UI, veritabanındaki değişikliklere abone olur ve herhangi bir değişiklikte otomatik olarak güncellenir. WorkManager, görevin yalnızca internet mevcut olduğunda çalışması için NetworkType.CONNECTED kısıtlamasıyla bir senkronizasyon görevi planlar.
Android'de tipik bir Offline-First senaryosu: bir kullanıcı uygulamada bir kayıt oluşturur. Veriler bir depo aracılığıyla Room'a kaydedilir. Depo, güncellenmiş verilerle bir Flow döndürür ve UI anında yeni kaydı görüntüler. Paralel olarak, depo WorkManager'da bir senkronizasyon görevi sıralar. Ağ mevcutsa, WorkManager sunucuya bir POST isteği gönderir. Sunucu bir hata döndürürse veya ağ kullanılamıyorsa, görev daha sonra yeniden denenir. Kullanıcı, yeni kayıtların yanında bir senkronizasyon göstergesi (oklu bulut simgesi) görür.
Tepkisellik için Depo + Flow deseni kullanılır. Depo, senkronizasyon ayrıntılarını ViewModel'den gizler: ViewModel, Room'dan bir Flow'a abone olur ve UI'yi günceller. Depo, API'yi çağırır ve sonucu Room'a kaydeder. UI, verilerin yerel veritabanından mı yoksa sunucudan mı alındığını bilmez — sadece Flow'taki değişikliklere tepki verir. Bu, UI kodunu değiştirmeden senkronizasyon stratejisini değiştirmeye olanak tanır. Room, LiveData/Flow ek açıklamaları sayesinde değişiklikleri otomatik olarak Flow'a bildirir.
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 ile Offline-First
Jetpack Compose'da Offline-First, ViewModel'den Composable işlevlere StateFlow aracılığıyla uygulanır. ViewModel, depodan bir Flow alır, stateIn() aracılığıyla bir StateFlow'a dönüştürür ve Compose'a iletir. Room verileri değiştirdiğinde, Flow yeni bir değer yayar, StateFlow güncellenir ve Compose yalnızca değişen öğeleri yeniden oluşturur. Bu, minimum çabayla ve senkronizasyondan sonra manuel liste güncellemesi olmadan reaktif bir UI sağlar.
Offline-First'te Sık Yapılan Hatalar
En yaygın hata, tam bir Offline-First mimarisi yerine önbellekleme kullanmaktır. Geliştiriciler Room veya Core Data ekler ancak yine de önce API'yi çağırır ve sonucu kopya olarak veritabanına kaydeder. Ağ olmadığında, uygulama bir yer tutucu veya boş ekran gösterir çünkü veriler hiçbir zaman yüklenmemiştir. Doğru yaklaşım, her zaman yerel veritabanından veri okumak ve API yanıtlarını yalnızca bu veritabanını güncellemek için kullanmaktır. İlk başlatmada veritabanı boşsa, uygulama sunucudan veri yüklemeli, yerel olarak kaydetmeli ve ardından görüntülemelidir.
İkinci hata, senkronizasyon çatışmalarını görmezden gelmektir. Geliştiriciler genellikle, kullanıcının önemli verileri kaybedebileceği senaryoları dikkate almadan varsayılan Last-Write-Wins'e güvenir. Uygulama, aynı kayıtların birden çok cihazdan düzenlenmesine izin veriyorsa, kullanıcı bildirimiyle en azından temel çatışma çözümü uygulamak gereklidir. Firebase Firestore bu sorunu otomatik olarak çözer, ancak özel uygulama dikkatli tasarım gerektirir.
Üçüncü sorun, ağ durumunu hesaba katmamaktır. Uygulama, çevrimiçiden çevrimdışına ve geriye geçişleri doğru şekilde yönetmelidir. Bir kullanıcı bir form gönderirse ve bağlantı koparsa, veriler işlem kuyruğuna kaydedilmeli, kaybolmamalıdır. Android'de ConnectivityManager ve iOS'te NWPathMonitor, ağ değişikliklerini gerçek zamanlı olarak izlemeye olanak tanır. Uygulama net bir UI göstermelidir: veriler senkronize edilmediyse “senkronizasyon bekleniyor” simgesi, ağ yoksa “evrimdışı” simgesi. Bu, kullanıcı beklentilerini yönetir ve yanlış destek taleplerinin sayısını azaltır.
Bellek ve Performans Sorunları
Offline-First mimarisi, yerel veritabanı kontrolsüz bir şekilde büyürse bellek sorunlarına yol açabilir. Sunucudan yüklenen tüm veriler yerel olarak kaydedilir ve bir temizleme politikası yapılandırılmazsa, veritabanı boyutu yüzlerce megabayta ulaşabilir. Önbelleğe alınan veriler için TTL (yaşam süresi) ayarlanması, senkronizasyon sırasında eski kayıtların silinmesi ve büyük listeleri yüklemek için sayfalamanın kullanılması önerilir. Room, veritabanı boyutunu yönetmek için COUNT ve DELETE toplama işlevleri sağlar.
Sıkça Sorulan Sorular
Offline-First ve Cache-First arasındaki fark nedir?
Offline-First — yerel veriler gerçeğin kaynağıdır, uygulama ağ olmadan tamamen çalışır. Cache-First — önbellek hız için kullanılır, ancak gerçeğin kaynağı sunucudur. Offline-First'te kullanıcı ağ olmadan veri oluşturabilir ve düzenleyebilir; Cache-First'te yalnızca önceden yüklenmiş verileri görüntüleyebilir. Offline-First karmaşık senkronizasyon gerektirir, Cache-First gerektirmez.
Offline-First'te senkronizasyon çatışmaları nasıl yönetilir?
Temel strateji Last-Write-Wins'dir (son yazma kazanır). Daha karmaşık senaryolar için — kullanıcı için sürüm seçim arayüzüyle MVCC veya matematiksel olarak çatışmaların olmadığını garanti eden CRDT (Çatışmasız Çoğaltılmış Veri Türleri). Strateji seçimi, verilerin kritikliğine ve uygulama karmaşıklığına bağlıdır.
Hangi veriler yalnızca yerel olarak depolanmamalıdır?
Uygulama silindiğinde veya cihaz arızalandığında kaybolmaması gereken kritik veriler sunucu depolaması gerektirir. Yetkilendirme token'ları, ödeme verileri, sipariş geçmişi — sunucuda çoğaltılmalıdır. Offline-First “yalnızca yerel” anlamına gelmez — “sunucu kopyası ile birincil depolama olarak yerel” anlamına gelir.
Offline-First uygulaması nasıl test edilir?
Emülatörde ağ kaybını, bant genişliği sınırlamasını ve Uçuş Modu'nu simüle etmek için bir Network Call Manager kullanın. Senaryoları test edin: ağ olmadan veri oluşturma, geri yüklemede senkronizasyon, paralel düzenleme sırasında çatışmalar. Android, Robolectric'te NetworkBehavior sağlar, iOS'te ağ hatalarını simüle etmek için OHHTTPStubs vardır. Entegrasyon testleri, işlem kuyruğunu ve çatışma çözümünü doğrulamalıdır.
Offline-First ne zaman kullanılmamalıdır?
Offline-First, verilerin her zaman güncel olması gereken uygulamalar için aşırıdır — örneğin, hisse senedi fiyatları, çevrimiçi haritalar veya izleme sistemleri. Kullanıcı uygulamayı asla internetsiz kullanmıyorsa ve veri tutarlılığı kritikse, yükleme göstergeleriyle Online-Only mimarisi kullanmak daha basit ve daha güvenilirdir.
Özet
- Offline-First — yerel depolamanın gerçeğin kaynağı olduğu ve sunucunun senkronizasyon için bir kopya olduğu bir geliştirme stratejisi.
- Yerel Gerçeğin Kaynağı — veriler önce cihaza kaydedilir (Room, Core Data, IndexedDB), ardından sunucu ile senkronize olur.
- Arka Plan Senkronizasyonu — WorkManager (Android), BackgroundTask (iOS), Service Worker (Web) ağ mevcut olduğunda değişiklikleri gönderir.
- Çatışma Çözümü — çevrimdışı modda farklı cihazlarda yapılan değişiklikleri uzlaştırmak için Last-Write-Wins, MVCC veya CRDT.
- İşlem Kuyruğu — kullanıcının hiçbir değişikliğinin kaybolmamasını garanti eder: işlemler yerel olarak kaydedilir ve bağlantı geri geldiğinde yürütülür.
- Tepkisel UI — Flow (Android) veya Combine (iOS) aracılığıyla UI, yerel veritabanına abone olur ve herhangi bir değişiklikte otomatik olarak güncellenir.
- Sık Yapılan Hatalar — önbellekle karıştırma, çatışmaları görmezden gelme, ağ durumunu hesaba katmama ve yerel veritabanının kontrolsüz büyümesi.
Anahtar teslim bir mobil uygulama geliştireceğiz
IT Sectr, 2017'den beri girişimler ve işletmeler için iOS ve Android uygulamaları oluşturmaktadır. Size danışmanlık yapacak ve en iyi çözümü önereceğiz.
Ayrıca okuyun