8 dk

Çevrimdışı Saha Veri Toplama için Mobil Uygulama Nasıl Oluşturulur

Çevrimdışı-öncelikli bir saha veri toplama mobil uygulaması planlamayı, tasarlamayı ve geliştirmeyi öğrenin: depolama, senkronizasyon, çakışmalar, güvenlik ve test etme dahil.

Çevrimdışı Saha Veri Toplama için Mobil Uygulama Nasıl Oluşturulur

Saha İş Akışını ve Çevrimdışı Gereksinimleri Tanımlayın

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.

Kim veri topluyor ve nerede?

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).

Tam olarak neler yakalanıyor?

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:

  • Yapılandırılmış formlar (kontrol listeleri, değerlendirmeler, ölçümler)
  • Fotoğraflar ve videolar (kayıt başına kaç tane, tipik çözünürlük)
  • GPS noktaları veya izleri (gerekli doğruluk, örnekleme sıklığı)
  • İmzalar ve onay beyanları
  • Barkod/QR taramaları, NFC etiketleri veya sayaç okumaları

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?

Çevrimdışı beklentileri ve sınırlar

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.

Uyum ve onaylar

İç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 Ürün Kapsamını Seçin

Ç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.

Hangi işlemlerin çevrimdışı çalışması gerektiğine karar verin

Çoğu saha veri toplama takımı için uygulamanın ağ olmadan desteklemesi gereken temel eylemler şunlardır:

  • Kayıt oluşturma ve düzenleme (denetimler, ziyaretler) mobil formlar aracılığıyla
  • Son kayıtları ve atanan işleri arama ve filtreleme
  • Bir site/varlık için geçmişi görüntüleme (son ziyaret notları, açık sorunlar)
  • GPS verisi ve zaman damgalarını otomatik yakalama
  • Fotoğraf/dosya ekleme (mantıklı limitler ve sıkıştırma ile)
  • Temel harita erişimi veya en azından koordinatlı önbelleğe alınmış site listesi

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.

“Olmazsa olmaz” ile “iyi olur”u ayırın

Çevrimdışı karmaşıklığı azaltmanın pratik bir yolu, en küçük çevrimdışı döngüyü önce sunmaktır:

  • Olmazsa olmaz: oluşturma/düzenleme, değişiklikleri kuyruklama, mobilde yerel veritabanı, net senkronizasyon durumu
  • İyi olur (sonra): çevrimdışı analitik panolar, gelişmiş global arama, büyük ek işler, çevrimdışı çok adımlı onaylar

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.

Uygulamanın hangi durumlarda eylemleri engellemesi gerektiğini tanımlayın

Bazı işlemler çevrimdışıyken (veya referans veriler eskiyken) engellenmelidir. Örnekler:

  • En güncel uyumluluk kontrol listesi veya fiyat kodları gerektiğinde form gönderimi
  • ID'lerin merkezi doğrulanması gerektiğinde yeni varlık oluşturma

“Araçta taslağa izin ver, gönderim için senkronizasyon gerektir” gibi net kurallar kullanın.

Çevrimdışı durum için UX kuralları belirleyin

Bağlantıyı gizlemeyin—bunu açıkça gösterin:

  • Kalıcı çevrimdışı/çevrimiçi bandı ve son senkronizasyon zamanı
  • Kayıt başına senkronizasyon simgeleri (kuyrukta, senkronize ediliyor, başarısız)
  • Düz ve anlaşılır mesajlar: “Cihazda kaydedildi. Bağlantı olunca yüklenecek.”

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.

Mobil Yığını ve Mimarisi Seçin

Ç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.

Birincil platformu seçin

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.

Yerel depolama yaklaşımını seçin

Çevrimdışı-öncelikli uygulamalar cihazdaki veritabanına bağlıdır. Tipik seçenekler:

  • SQLite tabanlı depolama (sarmalayıcılar aracılığıyla) geniş uyumluluk ve kontrol sağlar.
  • Native Android için Android Room güçlü şema/sorgu ve iyi araçlar sunar.
  • Native iOS için Core Data Apple’ın entegre kalıcılık modelini kullanır.
  • Realm nesne-odaklı yaklaşım ve hızlı okuma/yazma sunar.

Her ne seçerseniz seçin, güvenilir migration, eski cihazlarda sorgu performansı ve şifreleme desteğine öncelik verin.

API stilinizi ve versiyonlamayı planlayın

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.

  • REST referans veri indirme ve değişiklikleri yükleme endpoint'leri için basittir.
  • GraphQL fazla veri çekmeyi azaltabilir, fakat yine dikkatli cache ve senkronizasyon semantiği gerekir.

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.

Dosyalarla nasıl başa çıkacağınıza karar verin

Fotoğraflar, imzalar, ses ve belgeler için ayrı bir planınız olsun:

  • Dosyaları yerel önbellekte saklayın ve net saklama kuralları belirleyin.
  • Görüntü/video yüklemeden önce sıkıştırın.
  • Uygulama yeniden başlatmalarına dayanıklı bir yükleme kuyruğu kullanın; yeniden deneme/backoff ve kullanıcıya görünür durum (örn. “3 öğe yüklenmeyi bekliyor”) sağlayın.

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ışı Depolama için Veri Modelleri Tasarlayın

Ç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.

Taslakları, düzenlemeleri ve silmeleri açıkça modelleyin

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.

Senkronizasyon sırasında ihtiyaç duyacağınız meta verileri ekleyin

Teknik olmayan ekipler için bile, birkaç tutarlı alan her şeyi daha kolay debug ve uzlaştırılabilir kılar:

  • created_at ve updated_at (zaman damgaları)
  • device_id (hangi telefon/tabletin değişikliği ürettiği)
  • user_id (hangi kullanıcının işlem yaptığı)
  • version (artan bir sayı veya sunucudan gelen revizyon)

Çevrimdışı ID oluşturuyorsanız, çakışmaları önlemek için UUID kullanın.

Referans veriyi çevrimdışı içeriği olarak önceliklendirin

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.

Hızlı çevrimdışı arama için indeksleyin

Ç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.

Çevrimdışı Formlar ve Alan Yakalama Özellikleri Oluşturun

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.

İş kaybı yaşatmayacak çevrimdışı dostu formlar

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.

Tekrarlanabilir bölümler ve koşullu sorular

Gerçek denetimler genellikle “başka bir öğe ekle” desenleri içerir: birden çok varlık, okuma veya kusur. Tekrarlanabilir bölümleri destekleyin:

  • Formu terk etmeden öğe ekle/düzenle/sil
  • Her öğe için kompakt özet satırı (kullanıcıların ne yakalandığını hızlıca tarayabilmesi için)
  • Liste çok büyümeden önce makul limitler ve uyarılar

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.

Cihaz sinyallerini birinci sınıf veri olarak yakalayın

Uygulamanın ilgili olduğunda bağlamı otomatik toplamasını sağlayın:

  • GPS konumu ve doğruluğu (metre cinsinden), bunun taze mi yoksa önbelleğe alınmış mı olduğu
  • Zaman damgası (cihaz zamanı) ve mümkünse olay sırasını koruyacak monotonik sıra
  • Açıklamalı fotoğraf ve kısa videolar
  • Varlık ID'leri için barkod/QR taramaları

Bu sinyalleri kullanıcı tarafından girilen değerlerle birlikte saklayın ki kayıt daha sonra denetlenip güvenilirliği doğrulanabilsin.

Kötü bağlantıda bile kalan ekler

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.

Referans Veri ve Haritalara Çevrimdışı Erişim Sağlayın

Prototype your offline capture flow
Describe your field workflow and let Koder.ai generate a working mobile form with drafts.

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.

Önemli veri setlerini önbelleğe alın (kullanıcıların sadece ihtiyaç duyduklarını indirmesine izin verin)

İş 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:

  • Ne saklanacağı (veri setleri ve boyut tahminleri)
  • Hangi bölge/proje filtresinin uygulandığı
  • Ne zaman son güncellendiği

gibi bilgileri gösterin.

Çevrimdışı haritalar: karo önyükleme ve önbellek boyutunu yönetin

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:

  • Eski karoları otomatik temizleme (ör. 30 günde kullanılmayan alanları kaldırma)
  • İndirilen bir alanı manuel silme
  • İndirmeye başlamadan önce depolama azsa uyarı gösterme

Akıllı çevrimdışı arama, filtreler ve kaydedilmiş sorgular

Ç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.

Veri tazeliğini ve bozulmayı zarifçe gösterin

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.

Güvenilir Bir Senkronizasyon Stratejisi Planlayı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.

Doğru senkron tetikleyicilerini seçin

Farklı ekiplerin farklı zamanlama ihtiyaçları vardır. Yaygın tetikleyiciler:

  • Manüel senkron (açık bir “Senkrone et” düğmesi) kullanıcının tam kontrolü için
  • Uygulama açıkken arka plan senkronizasyonu ile çalışma sessizce yüklenir
  • Fotoğraflar ve GPS izleri için yalnızca Wi‑Fi seçeneği veri maliyetlerini engellemek için
  • Zamanlanmış aralıklar (örn. her 15 dakika) kesintili sinyal olan bölgelerde istikrarlı ilerleme sağlar

Çoğu uygulama bunları birleştirir: varsayılan olarak arka plan senkronu, güven duymak için manüel seçenek.

Yerel değişiklikler için bir outbox deseni kullanın

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.

Yeniden denemmeye güvenli hale getirin (idempotent)

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:

  • Yeni kayıtlara istikrarlı istemci ID'leri atayın
  • Her outbox olayı için benzersiz istek ID'leri kullanın
  • Upsert davranışını destekleyen sunucu API'lerini tercih edin

Büyük beklemeleri zarifçe yönetin

Bir gün çevrimdışı kaldıktan sonra yüklemeler büyük olabilir. Zaman aşımı ve throttling'i önlemek için:

  • Güncellemeleri indirirken sayfalandırma
  • Yüklemeleri partiler halinde (küçük, tutarlı parçalar) gönderme
  • Backoff ve yeniden denemeyle rate limitlere saygı gösterme

Görünür ilerleme hedefleyin (“120 öğeden 23'ü yüklendi”) ki saha personeli uygulamaya güvenip bir sonraki adımı bilsin.

Çakışmalar ve Veri Bütünlüğünü Ele Alma

Test your MVP on Koder.ai
Try Koder.ai free to validate offline-first workflows before upgrading your plan.

Ç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.

Açık çakışma kuralları seçin (ve dokümante edin)

Aynı kaydın iki yerde düzenlendiği durumda uygulamanızın ne yapması gerektiğini tanımlayın.

  • Last-write-wins (LWW): en basit, ama önemli güncellemeleri sessizce yok edebilir
  • Server-wins: merkezi yönetilen kayıtlar için daha güvenli, fakat saha kullanıcıları için sinirlendirici olabilir
  • Alan bazlı birleştirme: farklı kişilerin farklı alanları değiştirdiği formlar için en iyi deneyim, fakat daha fazla mühendislik gerektirir

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.

Önemli olduğunda basit bir çakışma ekranı gösterin

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ı:

  • Bu cihazda ne değişti? (yerel versiyon)
  • Sunucuda ne değişti? (uzaktaki versiyon)

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.

Çakışmaları oluşmadan önleyin

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.

Destek ve denetim için senkron sonuçlarını kaydedin

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.

Cihazdaki Çevrimdışı Veriyi Güvenceye Alın

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.

Yerel depolamayı şifreleyin (ve anahtarları güvenli saklayın)

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.

Kimlik doğrulama, token'lar ve çevrimdışı oturumlar

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:

  • Başarılı çevrimiçi oturumdan sonra zaman sınırlı bir çevrimdışı oturuma izin verin (örn. 8–24 saat)
  • Oturum süresi dolduğunda, cihaz çevrimdışı olsa bile yeniden kimlik doğrulaması isteyin

Bu, bir cihaz kaybolduğunda maruziyeti sınırlar ve önbelleğe alınmış verilere süresiz erişimi engeller.

Hassas ekranları koruyun ve omuz üzerinden bakmayı azaltın

Çevrimdışı uygulamalar halka açık yerlerde kullanılır—depolar, sahalar, lobiler—bu yüzden ekran düzeyi korumalar önemlidir.

  • Uygulamayı veya belirli bölümleri açmak için biyometrik kilit (Face ID / parmak izi) sunun
  • Arka plana alındıktan sonra hızlı tekrar kilit açma ile otomatik zaman aşımı ekleyin
  • Risk profiliniz gerektiriyorsa ekran görüntüsü almayı engelleme politikalarını düşünün (kullanılabilirliği etkileyebileceğini açıkça bildirin)

Denetlenebilirlik ve kurcalamaya direnç

Çevrimdışı veri senkronizasyondan önce düzenlenebilir. Kurcalamayı azaltmak için doğrulama için tasarlayın:

  • Her kayda audit alanları ekleyin: created_at, created_by, updated_at, device_id ve ilgiliyse GPS zaman damgası/kaynağı
  • Senkron sırasında sunucu tarafı doğrulaması yapın (zorunlu alanlar, aralıklar, izin verilen geçişler)
  • Yetkilendirme ve son kabul için sunucuyu nihai gerçek kaynağı kabul edin

Bu adımlar tüm riski ortadan kaldırmaz ama çevrimdışı depolamayı güvenli tutarken uygulamayı katlanılmaz kılmaz.

Saha UX'i, Güvenilirlik ve Düşük Bağlantı için Tasarlayın

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).

Çevrimdışı durumu açık (ve sakin) gösterin

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:

  • “Verilerim bu cihazda kaydedildi mi?”
  • “Yüklendi mi?”
  • “Sonraki adım ne olmalı?”

Kullanıcılara pratik kontroller verin

En iyi senkronizasyon bile bazen yavaşlar. Gerçek saha iş akışlarına uyan kontroller sağlayın:

  • Senkrone et (şimdi) düğmesi
  • Sadece başarısız olanları yeniden deneme (Retry failed)
  • Pil tasarrufu veya veri maliyeti için yüklemeleri duraklat
  • Unsynced kayıtları silmeden önbelleği temizleme seçeneği (dikkatle etiketlenmiş)

Arka plan senkronizasyonu destekliyorsanız, bir kuyruk sayacı gösterin (örn. “3 öğe bekliyor”) ki kullanıcı tahmin etmek zorunda kalmasın.

Hataları eyleme geçirilebilir yapı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:

  • “Bağlantı yok. Girdiniz cihazda kaydedildi. Geri geldiğinizde otomatik olarak senkronize edeceğiz.”
  • “Yükleme engellendi. Devam etmek için lütfen tekrar giriş yapın.”
  • “1 fotoğraf yüklemek için çok büyük. Bitirmek için sıkıştırın veya kaldırın.”

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.

Düşük uç cihazları ve zorlu koşulları gözetin

Saha veri toplama genellikle eski telefonlarda, sınırlı depolama ve şarj koşullarında olur. Güvenilirlik için optimize edin:

  • Sürekli GPS sorgulamaktan kaçının; gerekmedikçe veya aralıklarla GPS yakalayın
  • Medyayı yerel veritabanına kaydetmeden önce yeniden boyutlandırın/sıkıştırın
  • Uygulama yeniden başlatmalarına dayanıklı olun: formları otomatik kaydedin, taslakları saklayın ve çökme sonrası durumu geri yükleyin

Uygulama düşük bağlantıda öngörülebilir olduğunda, kullanıcılar uygulamaya güvenecek ve benimseme kolaylaşacaktır.

Çevrimdışı, Senkronizasyon ve Gerçek Dünya Kenar Durumlarını Test Edin

Plan sync before you code
Use Planning Mode in Koder.ai to outline outbox sync and retry rules.

Ç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.

Gerçek bağlantı problemlerini simüle edin

Sadece “internet yok”u değil, daha fazlasını test edin. Tekrarlanabilir bir test kontrol listesi hazırlayın:

  • Uçak modunda baştan sona test (oluştur, düzenle, sil, fotoğraf ekle, GPS yakala)
  • Dalgalı ağlar (LTE/3G/yok arasında hızlı geçiş)
  • Captive portal'lar (bağlı ama internet engelli Wi‑Fi)
  • Uygulama yeniden başlatma ve OS öldürmeleri (arka plan senkronizasyonu yarıda kesildiğinde)

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 hata senaryolarını otomatikleştirin

Senkronizasyon hataları genellikle ancak tekrar deneyimler sonra ortaya çıkar. Otomatik testler (unit + entegrasyon) ekleyin ki:

  • Backoff ile yeniden deneme davranışı ve uygulama yeniden başlatma sonrası durum doğrulansın
  • Kısmi hatalar (bazı kayıtlar yüklendi, bazıları reddedildi) test edilsin
  • Çoğaltmayı önleme (idempotency): tekrar gönderimler ekstra kayıt yaratmasın
  • Sıralama kısıtları (örn. önce bir “ziyaret” olmalı, sonra onun “fotoğrafları” yüklenmeli)

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.

En kötü durumu yük testi ile sınayın

“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.

Gerçek saha kullanıcıları ile pilot uygulama

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.

Çevrimdışı Uygulamayı Yayına Alın, İzleyin ve Sürdürün

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.

“Sağlıklı senkron”un ne demek olduğunu instrument edin

Hafif telemetri ekleyin ki temel soruları hızlıca yanıtlayabilesiniz:

  • Senkron başarı oranı (genel ve endpoint bazlı)
  • Ortalama bekleyen birikim boyutu (bir cihazın taşıdığı gönderilmemiş kayıt sayısı)
  • Tekrar bağlandıktan sonra senkronizasyon süresi (medyan ve en kötü durum)
  • Cihaz modeli, OS sürümü ve uygulama sürümü ile etiketlenmiş çökme raporları

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.

Saha için destek prosedürü oluşturun

Çevrimdışı uygulamalar öngörülebilir şekillerde başarısız olur. Basit bir iç kontrol listesi yazın:

  • “Senkron takılı kaldı”: son senkron zaman damgası, bekleyen kuyruk sayısı, pil tasarruf kısıtları, arka plan verisinin kapalı olup olmadığı
  • Veri eksiklikleri: kaydın yerelde olup olmadığı, sunucu doğrulamasıyla reddedilip reddedilmediği, çakışma sonuçlarının gözden geçirilmesi
  • Hesap ve izin sorunları: token süresi dolmuş, rol değişiklikleri, erişimin iptali

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).

Yerel şemalar ve API versiyonları için migration planı yapın

Ç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.

Onboarding ve eğitimi dokümante edin

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.

SSS

What does “offline” actually need to mean for a field data collection app?

Başlangıç için operasyonel hedefleri yazın:

  • Bir cihazın maksimum ne kadar süre çevrimdışı kalabileceği (saat/gün)
  • Her cihazın beklenen günlük/haftalık kayıt sayısı
  • Tipik ve maksimum eklenti boyutları (fotoğraf/video)
  • Kullanıcıların geçmişteki kayıtları arayıp arayamayacağı

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.

How do I translate real field workflows into offline requirements?

Şunu toplayın:

  • Roller (denetçiler, teknisyenler, taşeronlar) ve kısıtlar (tek elle kullanım, eldiven, paylaşılan cihazlar)
  • Çalışma ortamları (bodrumlar, uzak sahalar, sınır geçişleri) ve bağlantı desenleri
  • Şarj imkanları ve kullanıcıların “senkronizasyon için bekleyip bekleyemeyeceği”

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.”

Which features should be in the offline-first “must have” scope?

Çoğu ekip şu küçük döngü ile başlar:

  • Çevrimdışı formlarda kayıt oluşturma/düzenleme
  • Otomatik olarak taslak kaydetme
  • Fotoğraf/dosya ekleme (limitler ve sıkıştırma ile)
  • Atanmış işleri ve son kayıtları arama/filtreleme
  • Her şeyi daha sonra yüklemek üzere kuyruğa alma ve açık durum göstergesi

Ağır özellikleri (çevrimdışı panolar, global arama, karmaşık onaylar) temel yakalama + senkronizasyon güvenilir olana kadar erteleyin.

When should the app block actions while offline?

Riskleri azaltacak basit kurallar kullanın:

  • Sunucu doğrulaması gerektirdiğinde taslağa izin verin, gönderim için senkronizasyon isteyin
  • Referans verinin güncel olması gerektiğinde işlemleri engelleyin (uyumluluk kontrol listeleri, fiyat kodları)
  • ID'lerin merkezi doğrulanması gerektiğinde yeni varlık yaratılmasını engelleyin

Kuralı UI'da görünür kılın (örn. “Taslak kaydedildi. Göndermek için senkronizasyon gerekli.”).

What’s the best on-device storage option for offline-first apps?

Aşağıdaki özellikleri sağlayabilen bir yerel veritabanı seçin:

  • Güvenilir şema yükseltmeleri
  • Hızlı sorgular + indeksleme
  • Şifreleme desteği

Yaygın seçenekler:

  • SQLite tabanlı depolama (geniş uyumluluk)
  • Android Room (native Android)
  • Core Data (native iOS)
  • Realm (objekt‑odaklı model)

Platformunuza ve eski cihazlarda tutarlı performans ihtiyacınıza göre seçin.

How should I model drafts, edits, and deletions for offline sync?

Çalışma halinde olan verileri modelleyin, sadece sunucu kayıtlarını değil:

  • Her kayda bir sync state ekleyin (draft, pending_upload, synced, pending_delete)
  • Daha sonra hata ayıklamak için meta veriler ekleyin: created_at, updated_at, device_id, user_id, version
  • Çevrimdışı oluşturulan ID'ler için UUID kullanın

Bu, uygulama yeniden başlatıldığında çevrimdışı düzenlemeleri, silmeleri ve yeniden denemeleri öngörülebilir kılar.

How do I handle photos and other attachments with unreliable connectivity?

Her eki ayrı bir mini iş olarak ele alın:

  • Dosyaları yerelde saklayın ve açık saklama kuralları belirleyin
  • Fotoğraf/video yüklemeden önce sıkıştırın
  • Yeniden başlatmaya dayanıklı bir yükleme kuyruğu kullanın
  • Her dosya için durum gösterin: pending, uploading, failed, uploaded

Form tamamlanmasını anlık dosya yüklemeye bağlamayın; kayıt senkronize olsun, ekler bağlantı geldiğinde yetişsin.

What’s a reliable sync strategy for offline field apps?

Bir outbox deseni kullanın:

  • Her yerel oluşturma/güncelleme/silme işlemi outbox kuyruğuna bir olay yazar
  • Bir sync worker outbox'u okur ve değişiklikleri sunucuya gönderir
  • Her olay, sabit istemci ID'leri ve benzersiz istek ID'leri ile idempotent olmalıdır

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.

How do I handle conflicts when the same record is edited offline and online?

Kayıt türüne göre çakışma kurallarını seçin ve dokümante edin:

  • Last-write-wins (LWW): en basit, ama önemli güncellemeleri sessizce üzerine yazabilir
  • Server-wins: merkezi veriler için daha güvenli, fakat saha kullanıcılarını sinirlendirebilir
  • Alan bazlı birleştirme: farklı kişilerin farklı alanları değiştirdiği formlar için en iyi UX, daha fazla mühendislik gerektirir

Ö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.

How do I secure sensitive data stored on devices for offline use?

Cihaz üzerindeki veriler saha verileridir; telefon güvenlik sınırınızın parçası olur:

  • Yerel DB ve ekleri şifreleyin; anahtarları Keychain/Keystore'da saklayın
  • Kısa ömürlü erişim token'ları kullanın ve çevrimdışı oturum süreleri belirleyin (örn. 8–24 saat)
  • Biyometrik/kilit ve otomatik zaman aşımı sunun
  • Her kayda denetim alanları ekleyin: created_at, created_by, updated_at, device_id ve gerekirse GPS zaman damgası

Sunucu tarafında da senkronizasyon sırasında doğrulama yapın; bu, riski azaltırken uygulamayı kullanılmaz hale getirmez.

How should I test offline, sync, and real-world edge cases?

Bağlantı sorunlarını laboratuvarda değil gerçek dünyada yaşatın. Test listeniz şunları içermelidir:

  • Uçak modu baştan sona (oluşturma, düzenleme, silme, fotoğraf ekleme, GPS yakalama)
  • Dalgalı ağlar (hızla LTE/3G/yok arasında geçiş)
  • Captive portal'lar (bağlantı var gibi görünen ama internete erişim yok)
  • Uygulama yeniden başlatmaları ve OS öldürmeleri (arka plan senkronizasyonu yarıda kesilirse)

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.

How should I launch, monitor, and maintain the offline app?

Basit içgörüler toplayın ki hızlı karar alabilirsiniz:

  • Senkronizasyon başarı oranı (genel ve endpoint bazlı)
  • Ortalama bekleyen birikim boyutu (bir cihazdaki gönderilmemiş kayıt sayısı)
  • Tekrar bağlandıktan sonra senkronizasyon süresi (medyan ve en kötü durum)
  • Cihaz modeli, OS ve uygulama sürümü ile etiketlenmiş çökme raporları

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.

İhtiyaç varsa rollout veya destek kapsamı konusunda yardım için paydaşları /pricing veya /contact’a yönlendirin.

Related posts