Mobil Uygulamada Çevrimdışı Çalışma: Veri Eşitlemeden Önce Hangi Kararlar Alınmalı?

Bir sürücü depo çıkışında internetin çekmediği bir bölgeye girdiğinde, uygulamanın ona “bağlantı yok” demesi çoğu zaman iş akışının durması anlamına gelir. Mobil uygulamada çevrimdışı çalışma, bu kesintiyi bir istisna olarak değil, sahanın olağan koşulu olarak ele almayı gerektirir. Asıl zorluk veriyi cihazda tutmak değildir. Zor olan, bağlantı döndüğünde aynı verinin sunucuya doğru sırayla, eksiksiz ve mükerrer kayıt oluşturmadan ulaşmasıdır. Bu kararların çoğu kod yazılmadan önce verilmelidir. Sonradan eklenen bir eşitleme katmanı genellikle kayıp veri, çift kayıt ve belirsiz durumlarla geri döner.

Bu yazıda lojistikte bir teslimat adımını örnek alıyoruz: sürücü paketi teslim eder, fotoğraf çeker, alıcıdan imza alır ve “teslim edildi” durumunu kaydeder. Bağlantı yokken bu dört işlemin başına ne gelmesi gerektiğini, hangi kararların önceden netleşmesi gerektiğini adım adım ele alıyoruz.

011. Çevrimdışı kapsamını belirleyin: Hangi işlemler bağlantısız çalışacak?

İlk karar teknik değil, iş kararıdır. Uygulamanın her ekranını çevrimdışı çalıştırmak hem maliyeti hem karmaşıklığı artırır. Önce sahadaki kritik akışı seçin. Teslimat örneğinde bu akış şöyle olabilir:

• Okuma: Sürücünün günlük teslimat listesi, adresler ve alıcı notları sabah bağlantı varken cihaza indirilir.
• Yazma: Teslimat adımı, fotoğraf ve imza bağlantı olmadan kaydedilir.
• Çevrimiçi kalacaklar: Rota yeniden hesaplama ya da harita katmanı gibi sunucuya bağımlı özellikler çevrimdışıyken devre dışı kalabilir. Bu durumda kullanıcıya açık bir mesaj gösterilir.

Kapsamı yazılı hâle getirirken şu soruları cevaplayın:

1. Bağlantısız çalışması zorunlu olan işlemler hangileri?
2. Cihazda en fazla ne kadar süre veri bekleyebilir (vardiya sonu, gün sonu, birkaç gün)?
3. Kullanıcı verinin eşitlenip eşitlenmediğini ekranda nasıl görecek?

Üçüncü soru sık atlanır. Sürücü “kaydettim” ile “sunucuya ulaştı” arasındaki farkı görmezse, aynı teslimatı tekrar girmeye ya da uygulamayı kapatıp açmaya çalışır.

022. Cihazda saklama: Veri, fotoğraf ve imza nasıl tutulur?

Çevrimdışı çalışmada her kayıt önce cihazdaki yerel veritabanına yazılır, ekran da bu yerel kayıttan beslenir. Sunucu yanıtını beklemek zorunda kalmayan arayüz hızlı ve tutarlı çalışır. Kayıt tasarlarken şu alanları düşünün:

• Yerel benzersiz kimlik: Cihazda üretilen, sunucudan bağımsız bir UUID. Eşitleme sırasında mükerrer kaydı önlemenin temelidir.
• Durum alanı: Örneğin beklemede, yükleniyor, eşitlendi, hata.
• Zaman damgası: İşlemin cihazda gerçekleştiği an. Sunucuya ulaştığı an ayrı tutulur. Sunucu zamanı yerine cihaz zamanına güvenmenin sınırlarını da belgeleyin, çünkü cihaz saati yanlış ayarlanmış olabilir.
• İlişkili dosyalar: Fotoğraf ve imza veritabanına gömülmez. Dosya olarak saklanır, kayıtta yalnızca yolu ve özet bilgisi (boyut, sağlama değeri) tutulur.

Fotoğraf boyutu burada kritik bir karardır. Telefon kameraları çoğu zaman birkaç MB’lık görüntüler üretir. Bir sürücü gün içinde onlarca teslimat yaptığında bunlar cihaz belleğini ve mobil veri kotasını hızla tüketebilir. Teslim kanıtı olarak yeterli çözünürlüğü iş tarafıyla birlikte belirleyin, yüklemeden önce görüntüyü bu hedefe göre küçültün. İmzayı ise piksel görüntüsü yerine vektör (çizim noktaları) olarak saklamak hem boyutu düşürür hem sonradan görüntü üretmeyi kolaylaştırır.

Cihazdaki veri kişisel veri içerir: alıcı adı, adres, imza ve fotoğraf. Bu nedenle cihaz kaybı senaryosunu baştan düşünün: yerel veritabanının ve dosyaların şifrelenmesi, oturum açma gereksimi, uzaktan oturum kapatma ve eşitlenen verinin cihazdan silinme süresi KVKK uyumlu süreçlerin parçasıdır.

033. Eşitleme kuyruğu: Sıra, yeniden deneme ve çakışma kuralları

Bağlantı döndüğünde uygulama bekleyen kayıtları tek tek göndermeye başlar. Burada üç karar öne çıkar.

Gönderim sırası

“Teslim edildi” durumu, fotoğraf ve imza birbirine bağlıdır. Önce dosyaları yükleyip ardından durum kaydını göndermek ya da durumu “kanıt bekliyor” olarak ayrı işaretlemek, sunucuda eksik kanıtlı teslimat görünmesini önler. Hangi sıranın seçileceğini iş kuralı belirler, bu yüzden önceden yazın.

Yeniden deneme ve mükerrer kayıt

Zayıf bağlantıda istek sunucuya ulaşmış ama yanıt cihaza dönmemiş olabilir. Uygulama aynı isteği tekrar gönderdiğinde sunucu ikinci bir teslimat oluşturmamalıdır. Çözüm, her isteğe cihazın ürettiği benzersiz anahtarı eklemek ve sunucuda aynı anahtarı bir kez işlemektir (idempotency). Yeniden denemelerde kademeli bekleme süreleri kullanmak ağı ve pili gereksiz yormaz. Büyük fotoğraflar için yüklemeyi kaldığı yerden sürdürebilmek de uzun süreli kesintilerde kullanıcı deneyimini belirgin biçimde iyileştirir.

Çakışma

Sürücü çevrimdışıyken operasyon ekibi aynı teslimatı iptal etmiş ya da adresi değiştirmiş olabilir. İki taraf farklı şeyler söylediğinde kimin kazanacağını önceden belirleyin:

• Alan bazlı kural: Teslim kanıtı sahada oluştuğu için cihaz kaydı esas alınır, adres güncellemesi ise merkezde kalır.
• Son yazan kazanır: Basit ama veri kaybı riski taşır. Kritik alanlarda tek başına kullanılmamalıdır.
• İnsan onayı: Çözülemeyen çakışmalar operasyon ekibinin önüne bir istisna kaydı olarak düşer.

Her durumda çakışmanın sessizce yutulmaması, kayıt altına alınması gerekir. Sonradan “bu teslimat neden iptal görünüyor?” sorusunun yanıtı log kayıtlarında bulunabilmelidir.

044. Saha koşullarında test ve izleme: Kontrol listesi

Çevrimdışı akışlar ofis Wi-Fi ağında test edilirse çoğu hata canlıda ortaya çıkar. Test planınıza şu senaryoları ekleyin:

1. Teslimat adımı yapılırken uçak modunu açıp kapatma.
2. Fotoğraf yüklemesi sırasında bağlantının kesilmesi ve yeniden gelmesi.
3. Uygulamanın eşitleme sürerken sonlandırılması ya da cihazın yeniden başlatılması.
4. Cihaz belleğinin dolmaya yakın olduğu durum.
5. Aynı kaydın iki kez gönderilmesi (mükerrer kayıt oluşmadığının doğrulanması).
6. Cihaz saatinin yanlış ayarlandığı durum.

Canlıya çıktıktan sonra da eşitleme sağlığını izleyin: bekleyen kayıt sayısı, hata durumundaki kayıtlar ve en eski eşitlenmemiş kaydın yaşı sürücüden şikâyet gelmeden sorunu gösterir. Hata raporlama aracı ve operasyon panosu bu metrikleri görünür kılar.

Pratik kural: Kullanıcı bir kaydı “tamamlandı” gördüğünde, sistem o kaydın cihazda güvende olduğunu bilmeli. Sunucuya ulaşıp ulaşmadığı ise ayrıca ve açıkça gösterilmelidir.

05Sık sorulan sorular

Çevrimdışı çalışma her mobil uygulama için gerekli mi?

Hayır. Kullanıcıların çoğunlukla sabit ve güçlü bağlantıda olduğu uygulamalarda basit bir önbellek ve hata mesajı yeterli olabilir. Saha, depo, bodrum ya da kırsal alan gibi bağlantının kesildiği ortamlarda ise çevrimdışı çalışma iş sürekliliğinin parçası olur. Kararı kullanıcının gerçekten çalıştığı ortamlara göre verin.

Çevrimdışıyken biriken veri ne kadar süre cihazda tutulabilir?

Bu süre iş ve güvenlik kararıdır. Teknik olarak depolama alanı sınırlayıcıdır, güvenlik açısından ise cihazda bekleyen kişisel verinin süresi kısa tutulmalıdır. Kuralı baştan yazın: örneğin vardiya sonunda eşitlenmeyen kayıtlar için kullanıcıya uyarı gösterilir, eşitlenen kayıtlar belirli bir süre sonra cihazdan silinir.

Flutter ya da React Native ile çevrimdışı çalışma kurulabilir mi?

Evet. Çapraz platform çerçeveleri yerel veritabanı, arka plan işleri ve dosya yönetimi için gerekli bileşenleri sunar. Native (Swift ve Kotlin) tercih edildiğinde ise işletim sistemi seviyesindeki arka plan kısıtlarını daha ayrıntılı yönetebilirsiniz. Seçim, ekibinizin yetkinliğine ve uygulamanın cihaz özelliklerine ne kadar bağımlı olduğuna göre yapılır.

06Sonuç

Çevrimdışı çalışma, veriyi cihaza yazmaktan çok daha fazlasıdır. Kapsamı, saklama ve şifreleme kurallarını, gönderim sırasını, yeniden deneme davranışını ve çakışma politikasını eşitlemeden önce yazılı hâle getirmek, saha ekibinin güvenle kullanacağı bir uygulamanın temelini oluşturur. Teslimat adımı, fotoğraf ve imza örneğindeki yaklaşım, benzer şekilde denetim, bakım ya da servis uygulamaları için de uyarlanabilir. Kendi sahanıza uygun bir mobil mimariyi birlikte değerlendirmek isterseniz mobil uygulama geliştirme hizmetimizi inceleyebilirsiniz.