Saha operasyonu, depo yönetimi, servis ekipleri, mağaza içi süreçler, üretim hattı onayları. Bu akışların ortak bir kırılma noktası vardır: bağlantı kalitesi. Kurumsal mobil uygulama yalnızca güçlü Wi‑Fi olan ofislerde kullanılmaz; asansör boşluğunda, bodrum katta, kırsal bölgede, yurt dışı seyahatinde ya da kalın beton duvarların arasında da çalışmak zorundadır. İşte tam bu noktada offline mobil uygulama yaklaşımı kritik hale gelir.

İnternet kesildiğinde uygulamanın sadece “uyarı vermesi” yeterli olmaz. Kullanıcı veri girmeye devam edebilmeli, işlem kuyruğa alınmalı, kayıt cihaz üzerinde güvenli biçimde tutulmalı ve bağlantı geri geldiğinde sunucuyla tutarlı şekilde eşitlenmelidir. Aksi halde iki temel risk ortaya çıkar: veri kaybı ve operasyonun durması. 5 dakikalık bir kesinti, 50 saha formunun yeniden girilmesine; tek bir hatalı senkron ise mükerrer siparişe ya da eksik stok kaydına yol açabilir.

İyi kurgulanmış bir offline mimari, “internet yoksa uygulama da yok” anlayışını ortadan kaldırır. Ancak bunu sağlamak için yalnızca yerel veritabanı eklemek yetmez. Veri modeli, senkron kuralları, çakışma çözümü, güvenlik, loglama ve kullanıcı deneyimi birlikte düşünülmelidir.

Offline çalışma hangi kurumsal senaryolarda zorunludur?

Her mobil uygulamanın offline desteğe ihtiyacı aynı düzeyde değildir. Ancak bazı kullanım alanlarında bu özellik bir konfor değil, operasyonun gereğidir. Örneğin saha servis teknisyeni günde 20 adrese gidiyorsa ve bu adreslerin 6-7’sinde bağlantı zayıfsa, iş emri ekranının çevrimdışı çalışmaması doğrudan kapasite kaybına neden olur.

Benzer durumlar oldukça yaygındır:

  • Saha servis: Bakım formu, fotoğraf ekleme, imza alma, parça tüketimi girişi.
  • Lojistik ve depo: Barkod okutma, sevkiyat onayı, sayım kayıtları.
  • Perakende: Mağaza içi stok kontrolü, fiyat güncelleme, sipariş toplama.
  • Sağlık: Evde bakım ziyaretleri, hasta notları, kontrol listeleri.
  • Üretim: Vardiya kayıtları, kalite kontrol checklist’leri, duruş nedenleri.

Buradaki kritik ayrım şudur: Kullanıcı çevrimdışı kaldığında uygulama tamamen kilitleniyorsa, mobil çözüm aslında masaüstü mantığıyla tasarlanmıştır. Yani mobilin gerçek koşulları yeterince hesaba katılmamıştır.

İnternet kesintisinde veri kaybı nasıl oluşur?

Veri kaybı çoğu zaman tek bir büyük arızadan değil, küçük tasarım hatalarının birleşiminden kaynaklanır. En sık görülen örneklerden biri, kullanıcının formu doldurup “Kaydet”e bastığında verinin yalnızca API çağrısıyla sunucuya gönderilmesidir. Ağ yanıtı dönmezse ekran hata verir, kullanıcı da neyin kaydedilip neyin kaydedilmediğini anlayamaz.

Başka bir senaryoda kayıt geçici olarak bellekte tutulur. Uygulama kapanır, telefon yeniden başlar ya da işletim sistemi uygulamayı arka planda sonlandırır. Sonuç bellidir: girilen veri kaybolur. Özellikle 15-20 alan içeren servis formlarında bu durum ciddi zaman kaybı yaratır.

Risk yaratan başlıca nedenler şunlardır:

  • Yerel kalıcı depolama olmaması.
  • İşlem durumlarının izlenmemesi; örneğin draft, queued, synced, failed gibi statülerin tanımlanmaması.
  • Bağlantı geri geldiğinde tekrar deneme mekanizmasının bulunmaması.
  • Aynı kaydın birden fazla cihazda güncellenmesi halinde çakışma kurallarının belirsiz kalması.
  • Dosya, fotoğraf ve imza gibi büyük eklerin farklı akış gerektirdiğinin göz ardı edilmesi.

Kurumsal uygulamada “Kaydedildi” mesajı teknik bir taahhüttür. Bu mesaj yalnızca sunucuya ulaşıldığında değil, veri güvenli şekilde yerel kuyruğa yazıldığında da doğru biçimde tanımlanmalıdır.

Offline mobil uygulama mimarisi nasıl kurulmalı?

Sağlam bir yapı için temel prensip offline-first yaklaşımıdır. Yani uygulama önce cihaz üzerinde güvenilir biçimde çalışır, ağ erişimi olduğunda senkron olur. Bu modelde mobil istemci yalnızca bir ekran katmanı değildir; sınırlı ölçüde veri ve iş kuralı taşıyan aktif bir bileşendir.

1) Yerel veritabanı ve kalıcı kayıt

Mobil tarafta SQLite tabanlı çözümler, Realm benzeri yerel veri katmanları veya platformun güvenilir kalıcı depolama mekanizmaları kullanılabilir. Burada önemli olan nokta, yalnızca cache tutmak değil; iş için kritik verileri cihazda tutarlı biçimde saklamaktır. Örneğin son 30 günün iş emirleri, müşteri kartları ve ürün listeleri önceden cihaza indirilebilir.

2) İşlem kuyruğu

Kullanıcının yaptığı her değişiklik bir senkron kuyruğuna yazılmalıdır. Yeni kayıt, güncelleme, silme, fotoğraf yükleme gibi işlemler ayrı tiplerde tutulabilir. Basit bir örnek:

{
  "operationId": "op_98127",
  "entity": "service_form",
  "entityId": "local_452",
  "action": "create",
  "createdAt": "2026-07-22T10:15:00Z",
  "syncStatus": "queued"
}

Bu kayıt yazıldıysa, uygulama kapanıp açılsa bile işlem kaybolmaz. Ağ geri geldiğinde kuyruk sırayla işlenir.

3) Durum yönetimi

Kullanıcıya görünür senkron durumları tanımlanmalıdır. “Taslak”, “Gönderim bekliyor”, “Eşitlendi”, “Hata oluştu” gibi etiketler belirsizliği azaltır. Özellikle kırmızı hata ikonu yerine açıklayıcı bir metin göstermek, destek taleplerini azaltır.

4) Arka plan senkronu

Uygulama yalnızca açıldığında değil, uygun olduğunda da senkron yapmalıdır. iOS ve Android tarafında arka plan görevleri belli limitlerle çalışır; bu yüzden tasarım, işletim sistemi kısıtları dikkate alınarak yapılmalıdır. Büyük dosyalar için parçalı yükleme ve yeniden deneme stratejisi özellikle önemlidir.

Operasyonun durmasını önleyen senkronizasyon yöntemleri

Kurumsal senaryolarda tek bir senkron yöntemi her duruma uymaz. Veri tipine göre strateji seçmek gerekir. Metin tabanlı formlar ile yüksek çözünürlüklü fotoğraflar aynı kuralla yönetilmemelidir.

Push, pull ve delta senkron

Tüm veriyi her seferinde yeniden indirmek hem yavaştır hem de mobil veri tüketimini artırır. Daha verimli yaklaşım, yalnızca değişen kayıtları taşımaktır. Yani delta senkron. Örneğin son senkron zamanı 2026-07-22 09:00 ise, sunucu yalnızca bu saatten sonra değişen iş emirlerini döner.

İdempotent API tasarımı

Mobil uygulama aynı isteği ağ hatası nedeniyle 2 kez gönderebilir. Sunucu bu durumda mükerrer kayıt üretmemelidir. Bunun için istemcinin her işlem için benzersiz bir anahtar göndermesi yaygın bir yöntemdir. Sunucu, daha önce işlenmiş anahtarı tanıyıp aynı sonucu döner.

Çakışma çözümü

Aynı müşteri kaydı iki farklı cihazda düzenlenebilir. Burada “en son yazan kazanır” yaklaşımı bazı alanlarda yeterli olsa da her zaman doğru değildir. Fiyat, stok, sözleşme tarihi gibi kritik alanlarda kullanıcıya çakışma ekranı göstermek daha güvenlidir. Not alanı ile durum alanı için farklı kurallar tanımlanabilir.

Gerçek bir örnek düşünelim: Bir depo çalışanı çevrimdışı iken ürün miktarını 12 olarak güncelledi. Merkez ofis aynı SKU için stoğu 10 olarak revize etti. Ağ geri geldiğinde sistem doğrudan üstüne yazarsa envanter bozulur. Bu durumda hareket bazlı kayıt tutmak, mutlak sayı yerine artış/azalış işlemi göndermek daha doğru olabilir.

Güvenlik tarafı: cihazda tutulan veri nasıl korunur?

Offline çalışmanın bedeli, verinin bir bölümünün cihazda tutulmasıdır. Bu da ek güvenlik önlemleri gerektirir. Özellikle müşteri bilgisi, fiyat listesi, sözleşme detayları veya kişisel veri içeren uygulamalarda cihaz kaybı senaryosu mutlaka hesaba katılmalıdır.

Asgari güvenlik katmanları genellikle şunlardır:

  • Yerel verinin şifreli tutulması.
  • Token ve anahtarların güvenli saklama alanlarında tutulması.
  • Belirli süre sonunda oturum yenileme veya yeniden kimlik doğrulama.
  • Uzaktan oturum sonlandırma ve cihaz yetkisini iptal etme.
  • Hassas veriyi gereksiz süre cihazda tutmama; örneğin 7 gün sonra temizleme politikası.

Kurumsal mobil projelerde güvenlik yalnızca ağ trafiği için TLS kullanmakla sınırlı değildir. Offline veri yaşam döngüsü de tehdit modelinin bir parçası olmalıdır.

Kullanıcı deneyimi neden teknik mimari kadar önemlidir?

Offline destek arka planda ne kadar güçlü olursa olsun, kullanıcı ne olduğunu anlamıyorsa süreç yine aksar. Başarılı uygulamalar bağlantı durumunu net biçimde gösterir. Mesela üst bölümde küçük bir rozetle “Çevrimdışı: 8 işlem gönderim bekliyor” ifadesi tek başına büyük fark yaratır.

Ayrıca formlar parçalı kaydedilmelidir. 25 alanlı bir denetim formunda kullanıcı 18. alanda uygulamadan çıksa bile ilk 17 alan korunmalıdır. Otomatik taslak kaydı burada değerlidir. Fotoğraf eklerinde de “3/5 görsel kuyrukta” gibi ilerleme bilgisi güven verir.

İyi bir kural şudur: Kullanıcıyı ağ problemini yönetmek zorunda bırakmayın. Uygulama bunu kendi içinde ele almalı, kullanıcı ise sadece işine odaklanmalıdır.

Projeye başlamadan önce sorulması gereken 6 teknik soru

Offline mobil uygulama kararı proje başında netleştirilirse, maliyet ve mimari daha sağlıklı yönetilir. Sonradan eklenen offline destek çoğu zaman veri modelinin yeniden ele alınmasını gerektirir.

  1. Hangi ekranlar internet olmadan çalışmak zorunda?
  2. Cihazda tutulacak veri seti ne kadar büyük; 100 kayıt mı, 100 bin kayıt mı?
  3. Hangi işlemler anlık onay gerektiriyor, hangileri kuyruklanabilir?
  4. Çakışma yaşanırsa alan bazında kural ne olacak?
  5. Ek dosyalar için boyut limiti ve tekrar deneme politikası nedir?
  6. Offline modda tutulan veriler için güvenlik ve temizleme politikası var mı?

Bu sorular netleşmeden geliştirilen mobil projeler, canlıya çıktıktan sonra “bazı yerlerde çalışmıyor” türü belirsiz şikayetlerle karşılaşır. Sorun çoğu zaman koddan önce kapsam tanımında ortaya çıkar.

Sonuç: offline destek, mobil projede ek özellik değil temel dayanıklılıktır

Kurumsal mobil uygulamalar gerçek hayat koşullarında yaşar. Ağın kusursuz olduğu varsayımı pratikte geçerli değildir. Bu nedenle offline mobil uygulama yaklaşımı, özellikle saha ve operasyon odaklı projelerde temel bir tasarım prensibi olarak ele alınmalıdır.

Sağlam yerel kayıt, işlem kuyruğu, idempotent API, çakışma yönetimi, güvenli veri saklama ve anlaşılır kullanıcı deneyimi birlikte kurgulandığında internet kesintisi işin durmasına neden olmaz. Uygulama çevrimdışı durumda da üretken kalır. Kurum için asıl değer de burada ortaya çıkar: veri kaybı azalır, tekrar iş yükü düşer, operasyon sürekliliği korunur.