Offline-First Mobil Deneyim: Zayıf Ağlarda Güvenilir Ürün

1. Offline Kapsamını Kritik Kullanıcı Görevine Göre Seçin

Önce görev envanteri çıkarın ve her görevi bağlantı yokken oku, oluştur, düzenle, kuyruğa al veya engelle olarak sınıflandırın. Acil iletişim bilgisi, bilet, saha talimatı veya daha önce açılmış belge yerelde okunabilir olmalıdır. Profil fotoğrafı güncellemesi kuyruğa alınabilir. Güncel stokla satılan son ürün veya finansal transfer ise sunucu doğrulaması olmadan tamamlandı gösterilmemelidir.

Her görev için kabul edilebilir bayatlık süresini yazın. Bir haftalık eğitim içeriği saatlerce güncel kalabilir; vardiya ataması dakikalar içinde değişebilir. Kullanıcıya eski veriyi hiç göstermemek yerine, son güncellenme zamanını ve yenileme durumunu sunmak çoğu durumda daha yararlıdır. Ancak güvenlik, fiyat veya sağlık gibi yüksek riskli bilgilerde bayat veri açık uyarı ve kısıt gerektirir.

Offline kapsamı cihaz depolaması, pil, veri tüketimi ve gizlilikle sınırlıdır. Her şeyi önceden indirmek yerine kullanıcının görevi için gerekli alt kümeyi, ekleri ve süreyi belirleyin. Paylaşılan cihazlarda hassas önbellek için şifreleme, oturum kapatma ve silme davranışını tasarlayın.

2. Yerel Veriyi Okuma Kaynağı, Senkronizasyonu Ayrı Süreç Yapın

Android'ın resmi offline-first mimari rehberi, ağ kullanan bir deponun yerel ve ağ veri kaynaklarına sahip olmasını; üst katmanların okuduğu kurallı kaynağın yerel veri olmasını önerir. Yerel kaynağa önce yazılan değişiklikler arayüzü hemen güncelleyebilir, ağ kuyruğu ise daha sonra sunucuyu bilgilendirir. Rehber ayrıca offline yazmanın çatışma ve hata stratejisi gerektirdiğini vurgular.Android Developers — Build an offline-first app

Bu modelde arayüz ağ yanıtını doğrudan çizmez. Sunucudan gelen veri önce doğrulanır ve yerel depoya işlenir; ekran aynı kaynağı gözlemler. Böylece bağlantı durumu değişirken iki ayrı ekran gerçeği oluşmaz. Yine de yerel kaynağı mutlak doğru sanmayın: kayıtlar `pending`, `synced`, `failed`, `conflicted` veya `stale` gibi durumlar taşımalıdır.

Senkronizasyon işini uygulama yaşam döngüsünden ayırın. İşletim sistemi uygulamayı kapatabilir, pil tasarrufu arka planı erteleyebilir ve aynı kuyruk yeniden çalışabilir. İşlemler tekrarlandığında güvenli olmalı; benzersiz işlem kimliği ve sunucu tarafı idempotency aynı kaydın iki kez oluşmasını önlemeye yardım etmelidir.

3. Senkronizasyon, Tekrar Deneme ve Çatışma Kurallarını Tasarlayın

Kuyruk öğesi ne yapılacağını, hangi varlığa ait olduğunu, yerel sürümü, oluşturulma zamanını ve deneme durumunu taşımalıdır. Ağ gelir gelmez bütün kuyruğu saldırgan biçimde göndermek pil ve sunucu yükü yaratabilir. Üstel geri çekilme, ağ türü, şarj durumu ve iş önceliğine göre zamanlayın. Kullanıcının beklediği kritik gönderim ile analitik gibi ertelenebilir işi aynı öncelikte tutmayın.

Çatışma çözümü için 'son yazan kazanır' basit ama her veri için güvenli değildir. Kişisel notta kabul edilebilirken stok, vardiya veya ortak form alanında veri kaybettirebilir. Alan bazlı birleştirme, sunucu yetkisi, kullanıcıya seçim veya değişmez işlem günlüğü seçeneklerini veri türüne göre belirleyin. Otomatik çözüm varsa kurala ve gözlemlenebilirliğe sahip olmalıdır.

Silme özellikle zordur. Offline cihazda düzenlenen kayıt başka yerde silindiyse yeniden canlandırma mı, çatışma mı oluşacak? Tombstone, sürüm numarası ve saklama süresi kararlarını şemaya ekleyin. Saatlerin yanlış olabileceğini düşünerek yalnız cihaz zamanına güvenmeyin.

• Her yazma işlemi için benzersiz istemci işlem kimliği üretin.
• Kuyruk durumunu ve son hata sınıfını kalıcı saklayın.
• Tekrar denemeyi ağ, pil ve öncelik koşullarına bağlayın.
• Her veri türü için çatışma politikasını belgeleyin.
• Silme ve şema sürümü senaryolarını ayrıca test edin.

4. Varsayımsal Senaryo: Zayıf Ağda Saha Denetim Formu

Bu senaryo varsayımsaldır; gerçek müşteri sonucu değildir. Depolarda denetim yapan ekip için fotoğraf, kontrol maddesi ve imza içeren bir mobil form düşünün. Bazı binalarda bağlantı yoktur. Mevcut prototip her sayfa geçişinde sunucuya kayıt gönderdiği için zaman aşımında form donuyor; kullanıcı yeniden deneyince aynı denetim iki kez açılabiliyor.

Yeni kapsamda atanmış denetimler ve gerekli talimatlar vardiya başında indirilir. Her alan değişikliği cihazdaki taslağa yazılır; fotoğraflar ayrı, devam ettirilebilir kuyruğa girer. Ekran 'cihaza kaydedildi' ile 'merkeze aktarıldı' durumlarını farklı gösterir. Denetim benzersiz kimlik taşır ve sunucu tekrar isteğini aynı işlem olarak tanır.

İki denetçi aynı görevi düzenlerse son yazan sessizce kazanmaz. Sunucu alan sürümlerini karşılaştırır; farklı kontrol maddeleri birleşir, aynı madde çatışırsa sorumlu kişiye iki değer ve zaman bağlamı gösterilir. Pilot; kayıp taslak, çift kayıt, aktarım gecikmesi, pil ve kullanıcıların durum göstergesini anlayıp anlamamasıyla değerlendirilir. Başarı oranı varsayılmaz, sahada ölçülür.

5. Bağlantı Durumunu Teknik Jargon Yerine Eylemle Anlatın

Sürekli 'offline' bandı göstermek yeterli değildir. Kullanıcı için önemli olan hangi işi yapabileceği ve verisinin nerede olduğudur. 'Taslak bu cihazda kayıtlı', '3 fotoğraf gönderilmeyi bekliyor', 'Bu fiyatı doğrulamak için bağlantı gerekli' gibi durumlar eylem ve sonucu anlatır. Renk tek sinyal olmasın; simge, metin ve erişilebilir duyuruyu birlikte kullanın.

İyimser arayüz ancak geri alınabilir ve anlaşılır işlemlerde kullanılmalıdır. Kullanıcı öğeyi favoriye eklediğinde arayüz hemen güncellenebilir; para transferi sunucu onayı olmadan tamamlandı denmemelidir. Başarısız kuyruk öğesini sonsuza kadar gizlice denemek yerine sorun, son deneme ve kullanıcının seçenekleri sunulmalıdır.

Manuel yenileme otomatik senkronizasyonun yerine geçmez, fakat kontrol hissi verir. Aynı anda birden fazla yenileme üretmesini engelleyin. Liste sırası, form odağı ve yazılan metin ağ gidip gelirken sıfırlanmamalıdır.

6. Sekiz Haftalık Uygulama ve Ağ Bozma Testi

Cloud Firestore'un resmi belgesi, etkin çevrim dışı kalıcılıkta kullanılan verilerin önbelleğe alınabildiğini, bağlantı dönünce yerel değişikliklerin eşitlendiğini ve aynı belgeye birden çok değişiklikte son yazanın kazandığını belirtir. Bu hazır davranış bazı ürünler için yeterli olabilir; kritik ortak düzenlemede iş kuralınızla uyuşup uyuşmadığını açıkça test edin. Platformlara göre varsayılanların ve destek kapsamının değişebileceğini güncel belgeden doğrulayın.Firebase Documentation — Access data offline with Cloud Firestore

İlk iki haftada görevleri ve bayatlık sınırlarını sınıflandırın. Üçüncü hafta yerel şema, kuyruk ve durum modelini tasarlayın. Dördüncü ve beşinci haftalarda tek kritik akışı uçtan uca uygulayın. Altıncı hafta çatışma ve silme kurallarını kurun. Son iki haftada ağ gecikmesi, paket kaybı, uygulama kapanması, cihaz yeniden başlatma, düşük depolama ve sürüm yükseltmesini gerçek cihazlarda deneyin.

Test yalnız uçak modu değildir. İstek gönderildikten sonra bağlantıyı kesin, cevap gelirken uygulamayı kapatın, aynı hesabı iki cihazda düzenleyin, kuyruğu bin öğeyle doldurun ve sunucuyu kısmi hata verecek biçimde simüle edin. Gözlemlemede kuyruk yaşı, başarısız deneme, çatışma ve yinelenen işlem oranı yer alsın.

• Kritik görevleri oku, yaz, kuyruğa al veya engelle olarak sınıflandırdık.
• Her veri türünün bayatlık ve saklama sınırı belli.
• Yerel durum arayüzün kurallı okuma kaynağı.
• Kuyruk işlemleri tekrar çalıştırıldığında güvenli.
• Çatışma ve silme politikaları veri türüne göre yazılı.
• Kullanıcı yerel kayıt ile sunucu aktarımını ayırt edebiliyor.
• Kesinti, kapanma ve çoklu cihaz senaryolarını test ettik.

7. Sınırlar ve Başarısızlık Modları: Offline-First Bedelsiz Değildir

Yerel veritabanı, kuyruk, sürümleme ve çatışma çözümü ürün ile test yüzeyini büyütür. Basit içerik uygulamasında tam offline yazma gereksiz olabilir. Yüksek riskli gerçek zamanlı işlemlerde eski veriyle devam etmek kullanıcıya zarar verebilir. En dar değerli kapsamla başlayın; her özelliği sırf teknik tutarlılık için çevrim dışına taşımayın.

Güvenlik riski de artar. Hassas veri cihazda daha uzun kalır, kayıp veya ortak cihazda erişilebilir olabilir. İşletim sistemi korumaları, uygulama içi şifreleme gereksinimi, anahtar yönetimi, ekran görüntüsü politikası ve uzaktan oturum kapatma tehdit modeline göre değerlendirilmelidir. Önbellek temizliği ile zorunlu kayıt saklamayı birbirine karıştırmayın.

Son olarak senkronizasyon hiçbir zaman görünmez ve kusursuz değildir. Sunucu şeması değişir, hesap yetkisi geri alınır, depolama dolar veya kuyruk bozulur. Kurtarma, dışa aktarma, destek tanısı ve kullanıcıya açıklama tasarımın parçasıdır. Offline-first'in hedefi her koşulda başarı sözü vermek değil; belirsiz ağ koşullarında veri kaybını ve yanlış güveni azaltmaktır.