Saha Uygulamalarında Offline-First Tasarım
Offline-first ne demektir?
Offline-first, uygulamanın veriyi önce cihazda yazıp sonra sunucuya göndermesi anlamına gelir. Kullanıcı bağlantı olup olmadığını düşünmez; kayıt anında yerelde tamamlanır, senkronizasyon arka planda yürür. Depoda, bodrum katta, kırsalda veya asansörde çalışan bir uygulama için bu bir özellik değil, temel tasarım kararıdır.
Üç parçalı yapı
- Yerel veritabanı: kaydın gerçek kaynağı, cihaz üzerindedir. Ekran doğrudan yerel veriyi okur.
- Giden işlem kuyruğu: her değişiklik, sırası ve kendi kimliğiyle kuyruğa yazılır. Kuyruk kalıcıdır; uygulama kapansa da kaybolmaz.
- Senkron çalışanı: bağlantı geldiğinde kuyruğu sırayla gönderir, sunucudan gelen değişiklikleri yerelde uygular.
Ekranın doğrudan ağ çağrısı yapması offline-first değildir; bu, "çevrimdışıyken hata gösteren" bir uygulamadır.
Çakışma çözümü kararı ertelenemez
İki cihaz aynı kaydı çevrimdışıyken değiştirdiğinde ne olacağı, proje başında yazılmalıdır. Yaygın üç strateji:
- Alan bazlı birleştirme: farklı alanlar değişmişse ikisi de uygulanır. Stok sayımı ve müşteri notu gibi bağımsız alanlarda iyi çalışır.
- Son yazan kazanır: basit ama veri kaybı riski taşır; yalnızca kritik olmayan alanlarda kullanın.
- Sunucu otoritesi + kullanıcıya sorma: finansal etkisi olan alanlarda (fiyat, iskonto, tahsilat tutarı) doğru yaklaşım budur.
Karar, alan bazında verilmelidir. Tüm tablo için tek bir strateji seçmek, ya veri kaybı ya gereksiz kullanıcı sorusu üretir.
Aynı kaydın iki kez oluşmasını engelleyin
Zayıf bağlantıda istek gönderilir ama yanıt kaybolur; uygulama yeniden dener ve sunucuda iki sipariş oluşur. Çözüm, her işlemin cihazda üretilen benzersiz bir kimlikle gönderilmesi ve sunucunun aynı kimliği ikinci kez gördüğünde yeni kayıt açmak yerine ilk sonucu döndürmesidir. Bu davranışın API tarafındaki karşılığını [API entegrasyonu rehberinde](/blog/entegrasyon-api-rehberi) ayrıntılandırıyoruz.
Cihaz ve mağaza gerçekleri
- Pil: sürekli konum takibi pili hızla tüketir. Konumu olay bazlı (ziyaret başlangıcı/bitişi) toplamak çoğu senaryo için yeterlidir.
- Depolama: yerel veri sınırsız büyüyemez; eski hareketleri arşivleyip cihazdan temizleyen bir politika gerekir.
- İzinler: konum, kamera ve bildirim izinleri için mağaza politikaları gerekçe ister; izin isteme anını kullanıcıya anlamlı gelen bir adıma bağlayın.
- Sürüm zorlama: sunucu API sürümü değiştiğinde eski istemcinin ne yapacağı tanımlı olmalıdır; sessiz hata yerine güncelleme uyarısı gösterin.
Konum verisi ve kişisel veri sorumluluğu
Çalışan konumu kişisel veridir. Toplanacak veri en aza indirilmeli, toplanma amacı ve saklama süresi yazılı olmalı, çalışan bilgilendirilmelidir. "Her ihtimale karşı sürekli konum kaydı" yaklaşımı hem hukuki risk hem gereksiz veri yükü üretir.
Sık sorulan sorular
Native mi, çapraz platform mu?
Cihaz donanımını yoğun kullanan (sürekli barkod okuma, arka planda konum, düşük gecikmeli kamera) senaryolarda native avantajlıdır. Form ve liste ağırlıklı saha uygulamalarında çapraz platform, tek kod tabanıyla iki mağazaya çıkmayı sağlar. Karar, donanım kullanımının yoğunluğuyla verilir.
Yerel veriyi şifrelemek gerekir mi?
Cihazda müşteri, fiyat veya tahsilat verisi tutuluyorsa gerekir. Ayrıca cihaz kaybında uzaktan oturum sonlandırma ve yerel veriyi temizleme yeteneği planlanmalıdır.
Senkronizasyonun tamamlandığı kullanıcıya nasıl gösterilir?
Kayıt bazında durum göstermek en güvenilir yöntemdir: bekliyor, gönderildi, onaylandı. Tek bir genel "senkronize edildi" göstergesi, kısmi başarısızlıkları gizler.