Çevrimdışı Çalışan Mobil Uygulama Ne Kadar Zor? Mimari ve Kararlar

Bir mobil uygulama teklifinde "çevrimdışı da çalışsın" cümlesi tek satır gibi görünür ama genellikle projenin en pahalı kararlarından biridir. Zorluk arayüzde değil; kullanıcı internetsizken kaydettiği veri sunucuya nasıl ve ne zaman ulaşacak, aynı kayıt iki cihazda aynı anda değiştirilirse ne olacak sorularında saklıdır. Bu yazıda çevrimdışı çalışmanın seviyelerini, hangi uygulamada gerçekten gerektiğini ve mimarinin süreye ve maliyete etkisini sırayla anlatıyoruz.

Çevrimdışı çalışma tam olarak ne demek?

"Çevrimdışı çalışıyor" cümlesi üç farklı seviyeyi kastedebilir ve her biri bambaşka bir mühendislik yükü taşır. Kapsamı netleştirmeden verilen bir "evet, olur" cevabı, geliştirme ortasında sürprize dönüşür.

Hangi uygulamalar gerçekten çevrimdışı çalışmalı?

Her uygulamanın üçüncü seviyeye ihtiyacı yok; çoğu zaman ilk seviye bile yeterlidir. Aşağıdaki işaretlerden birkaçı varsa çevrimdışı çalışma gerçek bir gereksinimdir, süs değil.

• Saha ekibi bağlantısız bölgede çalışıyor. Depo, bodrum, tünel, kırsal alan veya yurt dışı saha ziyaretinde veri girişi kesilmemeli.
• İş sürekliliği kritik. Sağlık, güvenlik veya lojistik gibi alanlarda bağlantı kesintisi işi durdurmamalı.
• Kullanım seansı uzun ve tek oturumda tamamlanıyor. Envanter sayımı gibi saatler süren bir iş, ortasında bağlantı kesilirse baştan başlamamalı.
• Hedef pazarda mobil veri kalitesi düşük. Kırsal bölge veya gelişmekte olan pazarlarda 4G kapsaması süreklilik göstermeyebilir.

Buna karşılık, sürekli internete bağlı bir ofiste kullanılan bir yönetim paneli veya günlük kullanım süresi birkaç dakikayla sınırlı bir tüketici uygulaması için tam çevrimdışı mimari, karşılığını vermeyen bir bakım yüküdür.

Asıl zorluk: senkronizasyon ve çakışma çözümü

Çevrimdışı yazmayı desteklemenin kolay kısmı veriyi cihazda saklamaktır; zor kısmı, aynı kaydın iki farklı cihazda bağlantısızken değiştirilmesi ihtimalidir. İki saha çalışanı aynı müşteri kartını çevrimdışıyken güncellerse, hangi değişikliğin kazanacağına dair bir kural olmadan veri sessizce kaybolur.

1. Sunucu her zaman kazanır: basit ama çevrimdışı yapılan değişiklik kaybolabilir; düşük riskli, sık değişmeyen veriler için uygundur.
2. Son yazan kazanır (last-write-wins): zaman damgasına göre karar verilir; uygulaması kolaydır ama sessiz veri kaybı riski taşır.
3. Alan bazlı birleştirme: aynı kaydın farklı alanları ayrı ayrı senkronize edilir, yalnızca gerçekten çakışan alan işaretlenir.
4. Manuel çözüm ekranı: çakışma tespit edilince kullanıcıya iki sürüm gösterilip seçim yaptırılır; en güvenli ama en fazla arayüz işi gerektiren yöntem.

Teknoloji seçenekleri

Mimari kararın büyük kısmı, hangi yerel depolama ve senkronizasyon katmanının seçildiğinde şekillenir. React Native tabanlı projelerde pratikte öne çıkan seçenekler şunlar.

Kısmi çevrimdışı: tüm uygulamayı değil, tek akışı kapsamak

Çoğu projede en ekonomik yol, uygulamanın tamamını değil yalnızca kritik akışı çevrimdışı yapmaktır. Örneğin bir saha servisi uygulamasında raporlama ekranı her zaman bağlantı gerektirebilir; yalnızca iş emri tamamlama formunun çevrimdışı çalışması yeterlidir. Kapsamı tek bir akışla sınırlamak hem senkronizasyon mantığının test yüzeyini küçültür hem de geliştirme süresini kısaltır.

• Formu ve gerekli referans verisini önceden indirin. Kullanıcının bağlantısı kesilmeden önce ihtiyaç duyacağı müşteri, ürün veya stok listesi cihazda hazır olmalı.
• Yalnızca o akışın yazma işlemlerini kuyruğa alın. Uygulamanın geri kalanı normal çevrimiçi davranışını sürdürebilir.
• Kullanıcıya hangi ekranın çevrimdışı çalıştığını açıkça gösterin. Aksi halde kullanıcı hangi işlemin bekletildiğini bilemez ve aynı formu tekrar gönderebilir.

Süre ve maliyete etkisi

Mobil uygulama geliştirme hizmetimizde orta ölçekli bir uygulamanın tipik takvimi 8–14 hafta; tam çevrimdışı senkronizasyon eklemek bu sürece genellikle 3–6 hafta daha ekler. Ek süre kod yazmaktan çok test etmekten kaynaklanır: uygulamanın bağlantı kesilirken, kesikken ve yeniden bağlanırken doğru davrandığını her ekranda ayrı ayrı doğrulamak gerekir.

• Senkronizasyon motoru kurulumu: kuyruk, yeniden deneme ve durum takibi.
• Çakışma çözümü mantığı ve gerekiyorsa arayüzü.
• Bağlantı durumu göstergeleri: kullanıcı hangi verinin senkronize olduğunu, hangisinin beklemede olduğunu görebilmeli.
• Genişletilmiş test matrisi: zayıf bağlantı, ani kopma ve uzun süreli çevrimdışılık senaryoları.

Senkronizasyon katmanı yayınla bitmiş sayılmaz. Yeni bir alan eklendiğinde hem sunucu hem yerel şema güncellenmeli, ikisi arasındaki sürüm uyumsuzluğu ayrıca yönetilmelidir. Bu, çevrimdışı desteği olan bir uygulamanın bakım maliyetinin çevrimiçi bir eşdeğerine göre görünür şekilde yüksek kalmasının asıl sebebidir.

Karar vermeden önce sorulacak 5 soru

1. Kullanıcı gerçekten bağlantısız bir ortamda mı çalışıyor, yoksa yalnızca yavaş bir bağlantıda mı? İkisi farklı çözümler gerektirir.
2. Çevrimdışıyken hangi işlemler yapılabilmeli — yalnızca görüntüleme mi, veri girişi de mi?
3. Aynı kaydı aynı anda kaç kullanıcı değiştirebilir? Tek kullanıcılı kayıtlarda çakışma riski düşüktür.
4. Çakışma olursa hangi kural kabul edilebilir? Bu ticari bir karardır, teknik değil.
5. Bu özellik olmadan ilk sürüm yeterince değerli mi? Değilse v1'e değil, v2'ye ertelenebilir.

Çevrimdışı çalışma, doğru senaryoda ürünü rakiplerinden ayıran bir özelliğe dönüşür; yanlış senaryoda ise aylarca sürüm gecikmesine yol açan bir karmaşıklık katmanı olur. Kararı vermeden önce mobil uygulama yaptırma rehberimizde anlattığımız bütçeyi patlatan kararlar listesine de göz atmanızı öneririz. Kendi kullanım senaryonuz için doğru seviyeyi birlikte belirlemek isterseniz kısa bir görüşme talep edin.