Çevrimdışı çalışan mobil uygulama, kullanıcının bağlantı yokken de veri girebildiği, kayıtları görebildiği ve bağlantı geldiğinde yaptığı her şeyin sunucuya kayıpsız aktarıldığı uygulamadır. Bunu yapmanın yolu "bağlantı kopunca hata göster" mantığını tersine çevirmektir: uygulama önce cihazdaki yerel veritabanına yazar, değişiklikleri bir kuyrukta tutar ve senkronizasyonu arka planda yapar. Bu mimariye offline-first denir ve zor kısmı veriyi saklamak değil, iki cihaz aynı kaydı değiştirdiğinde hangisinin kazanacağını baştan kararlaştırmaktır.
Hangi uygulamanın çevrimdışı çalışması gerekir?
Her uygulamanın offline çalışması gerekmez ve gereksiz yere kurulursa maliyeti ciddi biçimde artırır. Kural basittir: kullanıcı işini bağlantısız bir yerde yapıyorsa ve o anda kaydedemediği veri kayboluyorsa, offline zorunludur. Saha ekipleri, depo ve şantiye çalışanları, şoförler, denetçiler ve kırsal bölgede çalışan satış temsilcileri bu gruptadır; inşaat firmaları, nakliye ve teknik servis yazılımlarında bu ihtiyaç ayrıca anlatıldı. Buna karşılık anlık fiyat, stok ya da bakiye gösteren bir uygulamada eski veriyi göstermek yanlış karar ürettirir; orada doğru davranış veriyi "son güncelleme" zamanıyla göstermek ve işlemi bağlantıya bağlamaktır.
- Tam offline: kullanıcı bütün gün bağlantısız çalışabilir, kayıt oluşturur ve düzenler (saha formu, teslim kaydı, sayım).
- Okuma offline: kullanıcı son indirilen veriyi görebilir ama değişiklik yapamaz (katalog, müşteri listesi, dokümanlar).
- Kısmi offline: bazı işlemler kuyruğa alınır, bazıları (ödeme, rezervasyon, stok düşümü) bağlantı ister ve bu ayrım arayüzde açıkça gösterilir.
Offline-first mimarinin üç parçası
Birinci parça cihazdaki yerel veritabanıdır. Ekranlar sunucudan değil bu veritabanından okur; sunucu verisi buraya senkronize edilir. React Native ve Flutter tarafında SQLite tabanlı çözümler en yaygın seçenektir. Basit anahtar-değer depolaması, filtrelenen ve ilişkili veri için yeterli değildir. İkinci parça işlem kuyruğudur: kullanıcının yaptığı her değişiklik yerel veritabanına yazılırken aynı anda "sunucuya gönderilecek" bir işlem olarak da kaydedilir. Üçüncü parça senkronizasyon motorudur: bağlantı geldiğinde kuyruğu sırayla gönderir, sunucudaki yeni değişiklikleri çeker ve çakışmaları kurala göre çözer.
type PendingOp = {
id: string; // istemcide üretilen benzersiz kimlik (idempotency anahtarı)
entity: 'visit' | 'photo' | 'signature';
payload: unknown;
createdAt: number;
attempts: number;
};
export async function flushQueue(db: LocalDb, api: Api): Promise<void> {
const ops = await db.pendingOps.orderBy('createdAt').toArray();
for (const op of ops) {
try {
// Sunucu aynı id ile ikinci isteği yeni kayıt açmadan kabul eder
await api.post('/sync/' + op.entity, { opId: op.id, data: op.payload });
await db.pendingOps.delete(op.id);
} catch (err) {
if (isConflict(err)) {
await db.conflicts.add({ op, server: err.serverVersion });
await db.pendingOps.delete(op.id);
continue;
}
await db.pendingOps.update(op.id, { attempts: op.attempts + 1 });
break; // Ağ hatası: sırayı bozmamak için dur, sonra tekrar dene
}
}
}Örnekteki üç karar kalıcıdır. Kimlik istemcide üretilir; bağlantı istek gönderildikten sonra koparsa uygulama aynı işlemi tekrar gönderir ve sunucu bunu ikinci kayıt olarak açmaz. Ağ hatasında kuyruk durur, çünkü "ziyaret oluştur" işlemi başarısızken "ziyarete fotoğraf ekle" işlemini göndermek sunucuda sahipsiz kayıt üretir. Çakışma ise sessizce ezilmez, ayrı bir listede kullanıcıya ya da yöneticiye gösterilir.
Offline uygulamada asıl tasarım kararı veriyi nerede saklayacağınız değil, iki cihaz aynı kaydı değiştirdiğinde hangisinin kazanacağıdır; bu kural sonradan eklenemez.
Çakışma kuralları: son yazan kazanır yetmez
En kolay kural "son gelen değişiklik kazanır" kuralıdır ve çoğu projede yanlış sonuç verir. Saatleri farklı iki cihazda "son" kavramı güvenilir değildir; ayrıca bütün kaydı ezmek, diğer kullanıcının değiştirdiği alanları da siler. Doğru yaklaşım çakışmayı alan düzeyinde ve kaydın türüne göre çözmektir.
- Yalnızca ekleme yapılan kayıtlar (ziyaret notu, fotoğraf, imza) çakışmaz; hepsi saklanır.
- Farklı alanların değiştiği durumda iki değişiklik birleştirilir; aynı alan değiştiyse kayıt çakışma listesine düşer.
- Sayaç ve miktar gibi alanlar "yeni değer" olarak değil "artış/azalış" olarak gönderilir; böylece iki cihazın sayımı birbirini ezmez.
- Durum alanlarında sunucu kuralı geçerlidir: sunucuda "iptal" edilmiş bir iş, sahadaki cihazdan "tamamlandı" olarak geri açılamaz, çakışma olarak raporlanır.
- Silme, kaydı fiziksel olarak silmek yerine "silindi" işaretiyle yapılır; aksi hâlde çevrimdışı cihaz silinen kaydı bir sonraki senkronda geri getirir.
Kimlik doğrulama, güvenlik ve depolama sınırları
Offline uygulamada oturum, token süresi dolduğunda bağlantı olmadığı için yenilenemez. Bu yüzden kullanıcının offline çalışabileceği azami süre bir iş kararı olarak belirlenir ve bu süre boyunca cihazda saklanan veri şifrelenir. Token’lar ve şifreleme anahtarı düz depolamada değil işletim sisteminin güvenli deposunda tutulur; ayrıntıları mobil uygulama güvenliği yazısında anlattık. Cihaza indirilen veri de sınırlıdır: kullanıcı yalnızca kendi bölgesinin, kendi işlerinin verisini alır. Bütün müşteri listesini her cihaza indirmek hem depolamayı doldurur hem de kaybolan bir telefonu veri sızıntısına çevirir; hangi verinin kime ineceği rol ve yetki kurgusuyla aynı kuraldan beslenmelidir.
Test edilmesi gereken senaryolar
Offline özellik, ofisteki hızlı Wi-Fi’da test edildiğinde her zaman çalışır. Gerçek sorunlar zayıf ve kesik kesik gelen bağlantıda, uygulama arka plana atıldığında ve günlerce senkron yapılmamış cihazlarda çıkar. Test planında en az şunlar bulunmalıdır: istek giderken bağlantının kopması, uygulamanın kuyruk doluyken kapatılıp açılması, iki cihazın aynı kaydı offline değiştirmesi, saat ayarı yanlış bir cihaz, uzun süre offline kalıp çok sayıda işlem biriktiren cihaz ve kuyrukta işlem varken uygulamanın güncellenmesi. Son senaryo özellikle önemlidir: yeni sürüm yerel veritabanı şemasını değiştiriyorsa, eski sürümde biriken işlemler kaybolmadan taşınmalıdır.
Maliyete etkisi
Offline-first, aynı ekranlara sahip çevrimiçi bir uygulamaya göre belirgin biçimde daha fazla iş çıkarır, çünkü her veri türü için yerel şema, senkron uç noktası ve çakışma kuralı yazılır ve test matrisi büyür. Bu yüzden teklif aşamasında hangi ekranların gerçekten offline çalışacağı tek tek yazılmalıdır; "her şey offline çalışsın" talebi çoğu zaman gereksiz bir kapsam büyümesidir. Bu ayrım mobil uygulama yaptırma maliyetini en çok değiştiren kalemlerden biridir ve sonradan eklemek, baştan kurmaktan daha pahalıdır, çünkü mevcut ekranların veri kaynağı değişir.
Sonuç
Çevrimdışı çalışan bir mobil uygulama; cihazda yerel veritabanı, sıralı ve tekrar gönderilebilir bir işlem kuyruğu ve kayıt türüne göre yazılmış çakışma kurallarıyla kurulur. Hangi ekranların offline çalışacağına, kullanıcının ne kadar süre bağlantısız kalabileceğine ve hangi verinin cihaza ineceğine baştan karar verilirse sahada güvenilir, verisi kaybolmayan bir ürün çıkar. Saha ekibiniz için offline çalışan bir uygulama planlıyorsanız mobil uygulama hizmetimize göz atabilir veya teklif alabilirsiniz.