Çevrimdışı-öncelikli bir saha veri toplama mobil uygulaması planlamayı, tasarlamayı ve geliştirmeyi öğrenin: depolama, senkronizasyon, çakışmalar, güvenlik ve test etme dahil.
Araçları seçmeye veya ekranları tasarlamaya başlamadan önce, sahada işin nasıl yürüdüğünü ve ekibiniz için “çevrimdışı”nın ne anlama gelmesi gerektiğini netleştirin. Bu bölüm, gerçek rutinleri test edilebilir ve desteklenebilir gereksinimlere dönüştürmekle ilgili.
Rolleri adlandırarak başlayın: denetçiler, anketörler, teknisyenler, denetçiler, saha çalışanları veya yükleniciler. Her rolün farklı kısıtları olabilir (koruyucu ekipman, tek elle kullanım, uzun seyahat günleri, paylaşılan cihazlar).
Kullanıcıların nerede çalıştığını belgeleyin: kapalı tesisler, bodrumlar, uzak yollar, çiftlikler, inşaat sahaları veya sınır ötesi alanlar. Kesintili bağlantı, şarj fırsatları ve kullanıcıların “senkronizasyon için bekleyip bekleyemeyeceği” gibi pratik gerçekleri not edin (çoğu bekleyemez).
Uygulamanızın bir işe, varlığa, konuma veya müşteriye bağlaması gereken kayıtları listeleyin. Her alan ve dosya türü için spesifik olun, örneğin:
Ayrıca “tamamlandı”nın ne anlama geldiğini tanımlayın: bir kayıt taslak olarak saklanabilir mi, gönderilebilir mi, sonradan onaylanabilir mi?
Maksimum çevrimdışı gün sayısı, cihaz başına beklenen kayıt sayısı ve maksimum ek boyutları gibi operasyonel hedefleri tanımlayın. Bu sayılar yerel depolama ihtiyaçlarını, performans kısıtlarını ve senkronizasyon davranışını doğrudan etkiler.
Paylaşılan cihazlar, bir günde birden fazla iş ve kullanıcıların çevrimdışıyken geçmiş kayıtları arayıp aramayacağı gibi kenar durumları da dahil edin.
İçerilen herhangi bir Kişisel Tanımlayıcı Bilgi (PII), onay gereksinimleri, saklama kuralları ve denetim izlerini belirleyin. Onaylar gerekiyorsa (amirin incelemesi, QA kontrolleri), hangi eylemlerin çevrimdışıyken engellenmesi gerektiğini ve hangilerinin daha sonra kuyruklanabileceğini tanımlayın.
Çevrimdışı-öncelikli tasarım, acımasızca net bir kapsamla başlar. Çevrimdışıya izin verdiğiniz her özellik, yerel depolamayı, senkronizasyon karmaşıklığını ve çakışma riskini artırır—bu yüzden bağlantı koptuğunda mutlaka çalışması gerekenleri tanımlayın.
Çoğu saha veri toplama takımı için uygulamanın ağ olmadan desteklemesi gereken temel eylemler şunlardır:
Okunabilir (salt okunur) ile tam düzenlenebilir olanı açıkça ayırın. Çevrimdışı düzenlemelere izin vermek genellikle mobil çevrimdışı senkronizasyon ve sonrasında çakışma çözümü gerektirir.
Çevrimdışı karmaşıklığı azaltmanın pratik bir yolu, en küçük çevrimdışı döngüyü önce sunmaktır:
Eğer bir “iyi olur” özelliği ağır referans veri önbellekleme veya karmaşık birleştirmeler gerektiriyorsa, çekirdek iş akışı güvenilir olana kadar erteleyin.
Bazı işlemler çevrimdışıyken (veya referans veriler eskiyken) engellenmelidir. Örnekler:
“Araçta taslağa izin ver, gönderim için senkronizasyon gerektir” gibi net kurallar kullanın.
Bağlantıyı gizlemeyin—bunu açıkça gösterin:
Bu kapsam tanımı, veri modeli, arka plan senkronizasyonu ve cihaz güvenliği gibi sonraki her karar için bir sözleşme haline gelir.
Çevrimdışı uygulamanızın mimarisi, “bağlantı yok” durumunu istisna değil norma çevirmeli. Amaç, veri girişini cihazda hızlı ve güvenli tutmak ve bağlantı geri geldiğinde senkronizasyonu öngörülebilir hale getirmektir.
iOS, Android veya her ikisi için mi geliştireceğinize karar verin.
Kullanıcılarınızın çoğu tek bir platformdaysa (kurumsal dağıtımlarda sık), native geliştirme performans ayarlamayı, arka plan davranışını ve OS'e özgü depolama/güvenlik özelliklerini basitleştirebilir. Hem iOS hem Android'e aynı anda ihtiyaç varsa, React Native veya Flutter gibi çapraz platform çerçeveler UI işini azaltabilir—ancak arka plan senkronizasyonu, izinler (GPS/kamera) ve dosya depolama için platform farkındalığı hâlâ gerekir.
Hızlı ilerlemek ve yönlendirilmiş bir yol isterseniz, web, backend ve mobilde küçük bir teknoloji setinde standartlaşmak yardımcı olabilir. Örneğin, Koder.ai gibi platformlar web, sunucu ve mobil uygulamalar oluşturmak için chat-odaklı iş akışları etrafında tasarlanmıştır (genellikle webde React, backend'de Go + PostgreSQL ve mobilde Flutter). Platformu uçtan uca benimsemeseniz bile bu standartlaşma yaklaşımı çevrimdışı-öncelikli geliştirmeyi ölçeklendirmeyi kolaylaştırır.
Çevrimdışı-öncelikli uygulamalar cihazdaki veritabanına bağlıdır. Tipik seçenekler:
Her ne seçerseniz seçin, güvenilir migration, eski cihazlarda sorgu performansı ve şifreleme desteğine öncelik verin.
REST ve GraphQL ikisi de çevrimdışı senkronizasyon için çalışabilir, ancak birini seçip zaman içinde değişime uygun olarak tasarlayın.
Açık bir versiyonlama stratejisi ekleyin (örn. /v1 endpoint'leri veya şema versiyonları) böylece eski uygulama sürümleri rollout sırasında güvenle senkronize olmaya devam edebilir.
Fotoğraflar, imzalar, ses ve belgeler için ayrı bir planınız olsun:
UI → yerel veritabanı → sync worker → API şeklinde temiz bir ayırma, ağın öngörülemez olduğu durumlarda bile çevrimdışı yakalamayı güvenilir tutar.
Çevrimdışı uygulamanız yerel veri modeline bağlıdır. Amaç basit: saha personeli kayıt oluşturabilmeli, taslak olarak kaydedebilmeli, sonradan düzenleyebilmeli ve hatta öğe silebilmeli—ağ beklemek zorunda kalmadan. Bu, yerel veritabanınızın "iş halinde" veriyi değil, sadece son onaylanmış veriyi temsil etmesini gerektirir.
Pratik bir yaklaşım, her kaydı bir sync state ile saklamaktır (örnek: draft, pending_upload, synced, pending_delete). Bu, “yerelde silindi ama yeniden başlatmadan sonra görünmeye devam ediyor” gibi karmaşık kenar durumlarını önler.
Düzenlemeler için ya (a) en son yerel versiyon + bekleyen değişiklikler listesi ya da (b) sunucudaki alanları senkronizasyon sırasında geçersiz kılacak tam bir yerel kayıt saklamayı düşünün. (a) daha karmaşıktır ama ileride çakışma yönetimine yardımcı olur.
Teknik olmayan ekipler için bile, birkaç tutarlı alan her şeyi daha kolay debug ve uzlaştırılabilir kılar:
Çevrimdışı ID oluşturuyorsanız, çakışmaları önlemek için UUID kullanın.
Saha uygulamaları genellikle kataloglara bağımlıdır: varlık listeleri, site hiyerarşileri, seçim listeleri, tehlike kodları vb. Bunları da yerel saklayın ve bir referans veri seti versiyonunu (veya “last_updated_at”) takip edin. Yalnızca değişeni yenileyecek şekilde kısmi güncellemeler tasarlayın; her seferinde her şeyi yeniden indirmek zorunda kalmayın.
Çevrimdışı kullanıcılar anında sonuç bekler. “site göre”, “duruma göre”, “son güncellenen” ve aranabilir tanımlayıcılar (varlık etiketi, iş emri numarası) için indeks ekleyin. Bu, yerel veritabanı haftalar içinde büyüse bile UI'nın duyarlı kalmasını sağlar.
Saha ekipleri formları ofis kullanıcıları gibi doldurmaz. Yağmur altında duruyor olabilirler, sahalar arası hareket ediyor ve sık sık bölünüyorlar. Göreviniz, bağlantı kopsa bile veri girişinin kesintisiz hissettirmesini sağlamak.
Her tuş vuruşunu değerli kabul eden bir form motoru ile başlayın. Taslakları otomatik kaydedin (sadece gönderimde değil) ve kaydetmeyi görünmez hale getirin: kullanıcıyı engelleyen yükleme göstergeleri veya “lütfen bekleyin” diyalogları olmasın.
Ağ gerektiren doğrulamaları yerel olarak yapın ki kullanıcı görevi ağ olmadan bitirebilsin. Kuralları basit ve hızlı tutun (zorunlu alanlar, aralıklar, temel formatlar). Sunucu doğrulaması gereken kontroller (ör. bir ID'nin doğrulanması) varsa bunları “senkronizasyon sırasında kontrol edilecek” diye etiketleyin ve kullanıcının devam etmesine izin verin.
Ağır ekranlardan kaçının. Uzun iş akışlarını daha küçük adımlara bölün (örn. “1 / 4”). Bu, çökme riskini azaltır, devam etmeyi kolaylaştırır ve eski cihazlarda performansı iyileştirir.
Gerçek denetimler genellikle “başka bir öğe ekle” desenleri içerir: birden çok varlık, okuma veya kusur. Tekrarlanabilir bölümleri destekleyin:
Koşullu sorular çevrimdışı deterministik olmalı. Koşulları sadece cihazda zaten bulunan değerlere (önceki cevaplar, kullanıcı rolü, seçili site türü) dayandırın, sunucu araması gerektirmesin.
Uygulamanın ilgili olduğunda bağlamı otomatik toplamasını sağlayın:
Bu sinyalleri kullanıcı tarafından girilen değerlerle birlikte saklayın ki kayıt daha sonra denetlenip güvenilirliği doğrulanabilsin.
Her eki kendi küçük işi gibi ele alın. Yüklemeleri forma senkronize etmeyi ayrı bir iş olarak kuyruğa alın, yeniden deneme/sürdürme destekleyin ve dosya başına durum gösterin: pending, uploading, failed, uploaded. Eklerin arka planda yüklenirken kullanıcıların çalışmaya devam etmesine izin verin ve form gönderimini anlık yükleme tamamlanmasına bağlamayın.
Saha ekipleri genellikle sadece form kullanmaz. Aynı zamanda referans bilgilerine—varlık listeleri, müşteri siteleri, ekipman katalogları, seçim listeleri, güvenlik kontrol listeleri—ve sinyal koptuğunda çalışan bir haritaya ihtiyaç duyarlar. Bunları öncelikli çevrimdışı özellikler olarak ele alın.
İş akışını mümkün kılan en küçük referans veri setini belirleyin (örn. atanan iş emirleri, varlık ID'leri, konumlar, izin verilen değerler). Ardından bölge, proje, ekip veya tarih aralığına göre kısmi indirme destekleyin, böylece cihaz her şeyi saklamak zorunda kalmasın.
Pratik bir yaklaşım: “Çevrimdışı kullanım için indir” ekranı sunun ve burada:
gibi bilgileri gösterin.
Teknisyenlerin navigasyon ve bağlam ihtiyaçları varsa, seçili alanlar için karo önyükleme (ör. iş sahasının çevresindeki bounding box veya bir rota koridoru) ile çevrimdışı haritalar uygulayın. Sessiz depolama hatalarını önlemek için toplam boyut ve alan başına sınırlar uygulayın.
Kontroller ekleyin:
Çevrimdışı erişim hızlı arama olmadan sinir bozucu olur. Ana alanları yerelde indeksleyin (ID'ler, adlar, etiketler, adresler) ve gerçek görevlerle uyumlu filtreleri destekleyin (proje, durum, bana atanmış). “Bu haftaki sahalarım” gibi kaydedilmiş sorgular, işlem adımlarını azaltır ve çevrimdışını daha kullanışlı kılar.
Referans veri ve harita alanları için her zaman “tazelik” bilgisi gösterin: son senkronizasyon zamanı, veri seti versiyonu ve güncelleme beklenip beklenmediği. Bir şey bayat ise, açık bir bant gösterin ve kullanıcıya bilinen sınırlamalarla devam etme seçeneği verin—aynı zamanda bir yenilemeyi bir sonraki bağlantıda kuyruğa alın.
Senkronizasyon saha ile ofis arasındaki köprüdür. Güvenilir bir strateji, bağlantının öngörülemez olduğunu, pilin sınırlı olduğunu ve kullanıcıların yükleme ortasında uygulamayı kapatabileceğini varsayar.
Farklı ekiplerin farklı zamanlama ihtiyaçları vardır. Yaygın tetikleyiciler:
Çoğu uygulama bunları birleştirir: varsayılan olarak arka plan senkronu, güven duymak için manüel seçenek.
Her oluşturma/güncelleme/silme işlemini bir olay olarak outbox kuyruğuna yazın. Senkron motoru outbox'u okur, değişiklikleri sunucuya gönderir ve her olayı onaylı olarak işaretler.
Bu, senkronu dayanıklı kılar: kullanıcılar çalışmaya devam edebilir ve hangi öğelerin hâlâ yüklenmesi gerektiğini her zaman bilirsiniz.
Mobil ağlar paket düşürebilir ve kullanıcılar “Senkrone et”e iki kez dokunabilir. İstekleri tekrar etmek çoğaltma yaratmayacak şekilde tasarlayın.
Pratik taktikler:
Bir gün çevrimdışı kaldıktan sonra yüklemeler büyük olabilir. Zaman aşımı ve throttling'i önlemek için:
Görünür ilerleme hedefleyin (“120 öğeden 23'ü yüklendi”) ki saha personeli uygulamaya güvenip bir sonraki adımı bilsin.
Çevrimdışı çalışma aynı kaydın iki farklı versiyonunun eş zamanlı var olabileceği anlamına gelir: cihazdaki teknisyenin yaptığı değişiklik ve sunucuda bir başkasının yaptığı değişiklik. Buna plan yapmazsanız gizemli üzerine yazmalar, eksik değerler ve yeniden üretilemeyen destek talepleri ile karşılaşırsınız.
Aynı kaydın iki yerde düzenlendiği durumda uygulamanızın ne yapması gerektiğini tanımlayın.
Bu kuralları yazılı hale getirin ve uygulama genelinde tutarlı kullanın. “Duruma bağlı” olmak sorun değil, yeter ki kayıt türüne göre öngörülebilir olsun.
Yüksek değerli veriler için (denetimler, uyumluluk kontrolü, imzalar) otomatik birleştirme yapmayın. Bir çakışma UI'sı şu iki soruyu yanıtlamalı:
Kullanıcılara: benimkini tut, sunucuyu tut veya (destekliyorsanız) alan alan birleştirmeyi seçme imkanı verin. Teknik zaman damgaları kullanmaktan kaçının; yalnızca gerçekten yardımcı oluyorlarsa gösterin.
En iyi çakışma, oluşmayan çakışmadır. Yaygın önleme taktikleri: hafif kayıt kilitleme, iş atamaları (sadece bir kişi işi sahiplenir) veya düzenleme pencereleri (gönderim sonrası kayıt salt okunur olur).
Ayrıca sunucu ile aynı kurallarla yerel doğrulamalar yapın (zorunlu alanlar, aralıklar). Bu, “çevrimdışı kabul edildi, sonra reddedildi” sürprizlerini azaltır.
Senkronu bir iş süreci gibi ele alın: her kayıt için zaman damgaları, hata kodları ve yeniden deneme sayıları içeren yerel bir senkron logu saklayın. Bir kullanıcı “güncellemem kayboldu” dediğinde, bunun yükleme sırasında başarısız olup olmadığını, çakışma yaşanıp yaşanmadığını veya sunucu doğrulamasınca reddedilip reddedilmediğini izleyebilirsiniz.
Saha veri toplama genellikle müşteri bilgileri, konumlar, fotoğraflar ve denetim notları içerir. Bu veriler çevrimdışı kullanım için yerelde saklandığında, telefon güvenlik sınırınızın bir parçası haline gelir.
Hassas veya düzenlemeye tabi bilgi topluyorsanız, yerel veritabanını ve ekler için kullanılan dosya depolamayı şifreleyin. iOS ve Android'de anahtarları platform destekli keystore'larda (Keychain / Keystore) saklayın—gizli anahtarları kod içinde sabitlemeyin veya tercihlerin içinde düz metin halinde saklamayın.
Pratik bir yöntem: yerel veritabanını şifreleyin, büyük ekleri ayrı şifreleyin ve kullanıcı çıkış yaptığında veya politika gerektirdiğinde anahtarları döndürün.
Güçlü kimlik doğrulama ve kısa ömürlü erişim token'ları kullanın. Giriş sonrası “çevrimdışı”nın ne anlama geldiğini planlayın:
Bu, bir cihaz kaybolduğunda maruziyeti sınırlar ve önbelleğe alınmış verilere süresiz erişimi engeller.
Çevrimdışı uygulamalar halka açık yerlerde kullanılır—depolar, sahalar, lobiler—bu yüzden ekran düzeyi korumalar önemlidir.
Çevrimdışı veri senkronizasyondan önce düzenlenebilir. Kurcalamayı azaltmak için doğrulama için tasarlayın:
Bu adımlar tüm riski ortadan kaldırmaz ama çevrimdışı depolamayı güvenli tutarken uygulamayı katlanılmaz kılmaz.
Saha kullanıcıları “teknik”ten çok uygulamanın durumlarını bildirip bildirmediği ve çalışmaya devam etmelerine izin verip vermediği ile ilgilenir. Çevrimdışı-öncelikli tasarım mühendislik kadar UX problemidir: insanlar durumu güvenilir bulmazsa kendi geçici çözümlerini üretirler (kağıt notlar, tekrar gönderimler, ekran görüntüleri).
Bağlantı ve senkron durumunu kullanıcıların doğal olarak baktığı yerlere, fakat gürültü yaratmadan gösterin.
Basit bir durum göstergesi kullanın (örn. Offline / Syncing / Up to date) ve her zaman "Son senkron" zaman damgasını gösterin. Bir sorun olduğunda, kullanıcı kapatana veya sorun çözülene kadar görünür kalan bir hata bandı gösterin.
İyi offline göstergeleri kullanıcılara şu soruları yanıtlamada yardımcı olur:
En iyi senkronizasyon bile bazen yavaşlar. Gerçek saha iş akışlarına uyan kontroller sağlayın:
Arka plan senkronizasyonu destekliyorsanız, bir kuyruk sayacı gösterin (örn. “3 öğe bekliyor”) ki kullanıcı tahmin etmek zorunda kalmasın.
“Senkrone başarısız” gibi belirsiz hatalardan kaçının. Ne olduğunu ve ne yapılması gerektiğini açıkça söyleyin.
Örnekler:
Mesajları bir sonraki adım düğmesiyle bağlayın (“Tekrar dene”, “Ayarları aç”, “Destek ile iletişime geç”) ki kullanıcı hızla kurtulabilsin.
Saha veri toplama genellikle eski telefonlarda, sınırlı depolama ve şarj koşullarında olur. Güvenilirlik için optimize edin:
Uygulama düşük bağlantıda öngörülebilir olduğunda, kullanıcılar uygulamaya güvenecek ve benimseme kolaylaşacaktır.
Çevrimdışı saha uygulamaları laboratuvarda değil, rüzgarlı bir yol kenarında %2 pil ile başarısız olur. Testlerin bu gerçeği yansıtması gerekir, özellikle mobil senkronizasyon, ekler ve GPS yakalama etrafında.
Sadece “internet yok”u değil, daha fazlasını test edin. Tekrarlanabilir bir test kontrol listesi hazırlayın:
Kullanıcının çalışmaya devam edebildiğini, yerel veritabanının tutarlı kaldığını ve UI'nın neyin yerelde kayıtlı neyin senkronize olduğunu net gösterdiğini doğrulayın.
Senkronizasyon hataları genellikle ancak tekrar deneyimler sonra ortaya çıkar. Otomatik testler (unit + entegrasyon) ekleyin ki:
Mümkünse, bu testleri kararsızlık enjekte eden bir staging sunucusuna karşı çalıştırın (zaman aşımı, 500 hataları, yavaş yanıtlar) ki saha koşullarını taklit edin.
“Birkaç günlük çevrimdışı” ve “her şey aynı anda senkronize oluyor” senaryolarına hazırlanın. Binlerce kayıt, çok sayıda ek ve eski öğelere yapılan düzenlemelerle stres testi yapın. Pil tüketimini, cihaz depolama büyümesini ve düşük uç telefonlardaki senkronizasyon süresini ölçün.
Kısa saha pilotları yapın ve geri bildirimi hemen toplayın: hangi mobil formlar kafa karıştırıyor, hangi doğrulamalar işi engelliyor, hangi senkronizasyon davranışları yavaş hissettiriyor. Geniş dağıtımdan önce form akışı ve çakışma çözümü kurallarını yineleyin.
Bir çevrimdışı saha uygulamasını yayına almak bitiş çizgisi değildir—gerçek bağlantı, cihaz ve kullanıcı davranış desenleri ilk sürümlerde ortaya çıkar. İlk sürümleri öğrenme aşaması olarak ele alın: net metrikler ve hızlı geri bildirim döngüsü kurun.
Hafif telemetri ekleyin ki temel soruları hızlıca yanıtlayabilesiniz:
Mümkünse, bir senkronun neden başarısız olduğunu kaydedin (auth süresi doldu, payload çok büyük, sunucu doğrulama, ağ zaman aşımı) fakat hassas saha verilerini loglamaktan kaçının.
Çevrimdışı uygulamalar öngörülebilir şekillerde başarısız olur. Basit bir iç kontrol listesi yazın:
Oynatma kitabını mühendis olmayanların (destek ve operasyon) da kullanabileceği şekilde hazırlayın ve kullanıcıya ne yapmasını söyleyeceğinizi ekleyin (örn. uygulamayı Wi‑Fi'de aç, 2 dakika ön planda tut, bir tanılama log ID'si yakala).
Çevrimdışı-öncelikli uygulamalar güvenli yükseltmeler gerektirir. Yerel veritabanı şemasını versiyonlayın ve test edilmiş migrationlar (kolon ekleme, varsayılanlarla backfill, yeniden indeksleme) hazırlayın. Ayrıca API sözleşmelerini versiyonlayın ki eski uygulama sürümleri kibarca geriye doğru uyum sağlasın yerine alanları sessizce düşürmesin.
Saha ekipleri için kısa eğitim rehberleri oluşturun: verinin cihazda kaydedildiğini nasıl doğrularsınız, “gönderilmeyi bekliyor” nasıl anlaşılır, ne zaman tekrar denemeli. Eğer çevrimdışı-öncelikli yaygınlaştırma veya dahili enablement içerikleri oluşturuyorsanız, teşvik düşünün. Örneğin, Koder.ai platformu içerik oluşturma ve yönlendirme için kredi kazanma programları sunabiliyor—bunlar build yaklaşımlarını belgelemek ve benimsemeyi teşvik etmek için yardımcı olabilir.
Eğer rollout veya destek kapsamı planlamasında yardım isterseniz, paydaşları /pricing veya /contact yönlendirin.
Başlangıç için operasyonel hedefleri yazın:
Bu sayılar doğrudan yerel depolama ihtiyaçlarını, veritabanı performansını ve senkronizasyonun artımlı, partili veya yalnızca Wi‑Fi üzerinden olup olmayacağını belirler.
Şunu toplayın:
Bunu test edilebilir gereksinimlere dönüştürün: örn. “uçak modunda tam bir denetim oluşturabilme” ve “hiçbir yükleme çubuğu olmadan işi tamamlayabilme.”
Çoğu ekip şu küçük döngü ile başlar:
Ağır özellikleri (çevrimdışı panolar, global arama, karmaşık onaylar) temel yakalama + senkronizasyon güvenilir olana kadar erteleyin.
Riskleri azaltacak basit kurallar kullanın:
Kuralı UI'da görünür kılın (örn. “Taslak kaydedildi. Göndermek için senkronizasyon gerekli.”).
Aşağıdaki özellikleri sağlayabilen bir yerel veritabanı seçin:
Yaygın seçenekler:
Çalışma halinde olan verileri modelleyin, sadece sunucu kayıtlarını değil:
Her eki ayrı bir mini iş olarak ele alın:
Form tamamlanmasını anlık dosya yüklemeye bağlamayın; kayıt senkronize olsun, ekler bağlantı geldiğinde yetişsin.
Bir outbox deseni kullanın:
Arka planda açıkken otomatik senkronizasyon + manuel “Sync now” düğmesini birleştirin; büyük birikimleri partiler, sayfalandırma ve backoff ile yönetin.
Kayıt türüne göre çakışma kurallarını seçin ve dokümante edin:
Önemli kayıtlar için (denetimler, imzalar) otomatik birleştirme yapmayın; yerel vs sunucu sürümünü gösteren basit bir çakışma ekranı sunun ve kullanıcıya seçim hakkı verin.
Cihaz üzerindeki veriler saha verileridir; telefon güvenlik sınırınızın parçası olur:
Sunucu tarafında da senkronizasyon sırasında doğrulama yapın; bu, riski azaltırken uygulamayı kullanılmaz hale getirmez.
Bağlantı sorunlarını laboratuvarda değil gerçek dünyada yaşatın. Test listeniz şunları içermelidir:
Bu senaryoların otomatik testlerini (retry, kısmi hata, idempotency) ve yük testlerini yapın; pilot kullanıcılarla kısa saha testleri düzenleyip geri bildirim alın.
Basit içgörüler toplayın ki hızlı karar alabilirsiniz:
Mümkünse, neden senkronizasyonun başarısız olduğunu (auth expired, payload çok büyük, sunucu doğrulama, ağ zaman aşımı) kaydedin ama hassas saha verilerini loglamayın.
Platformunuza ve eski cihazlarda tutarlı performans ihtiyacınıza göre seçin.
created_at, updated_at, device_id, user_id, versionBu, uygulama yeniden başlatıldığında çevrimdışı düzenlemeleri, silmeleri ve yeniden denemeleri öngörülebilir kılar.
İhtiyaç varsa rollout veya destek kapsamı konusunda yardım için paydaşları /pricing veya /contact’a yönlendirin.