Flutter uygulaması internet yokken nasıl çalışır ve veriler nasıl senkronize edilir?

Bir saha çalışanı bodrum katta form dolduruyor, mağaza görevlisi ürün sayıyor ya da depo çalışanı raf kontrolü yapıyor. Bu sırada bağlantı kesilebilir. Uygulama yalnızca sunucuya erişebildiğinde açılıyor veya kaydı tamamlıyorsa iş yarıda kalır. Flutter uygulamasını internet yokken de kullanılabilir tasarlamak için önce verinin nerede tutulacağını ve bağlantı geri geldiğinde nasıl aktarılacağını belirlemek gerekir.

Çevrimdışı destek, her ekrana bir hata mesajı eklemek demek değildir. Kullanıcı hangi işleri bağlantısız yapabilir, hangi bilgiler güncel olmalı, bir değişiklik başka bir cihazdan da yapılırsa ne olacak gibi soruların yanıtı gerekir. Bu kararlar arayüz kodundan önce verilir. Küçük ve açık kurallar, sonradan ortaya çıkan veri kaybı ve tutarsızlık sorunlarını azaltır. İnternet kesildiğinde de satışa devam etmesi gereken bir kasa uygulamasında yerel veri katmanı ve senkronizasyon üzerinde çalışıyorum; bu yazıda bu tür uygulamalarda verilmesi gereken temel kararları anlatıyorum.

Yerel veritabanını uygulamanın çalışma kaynağı yapın

Drift, Flutter ve Dart projelerinde SQLite veritabanına erişmek için kullanılan bir katmandır. Verileri tablolar halinde tanımlamanıza, sorgular yazmanıza ve sorgu sonuçlarını akış olarak izlemenize yardım eder. SQLite veritabanı cihazda bulunduğu için kayıt okuma ve yazma işlemleri ağ bağlantısına bağlı değildir.

Uygulama ekranlarının veriyi doğrudan HTTP yanıtından göstermesi yerine yerel veritabanından beslenmesi daha sağlam bir düzendir. Sunucudan gelen yeni ya da değişmiş kayıt önce SQLite'a yazılır. Ekran da veritabanındaki güncel durumu gösterir. Böylece internet varken de yokken de arayüz aynı veri yolunu kullanır. Uygulama açıldığında önce kayıtlı içerik görünür, eşitleme tamamlandığında değişiklikler ekrana kendiliğinden yansır.

Drift'in watch() sorguları, izlenen tablolar değişince yeni sonuç akışı sağlar. Örneğin ürün listesini izleyen bir ekran, eşitleme servisi bir ürünün stok miktarını güncellediğinde yeniden çizilebilir. Bu yapı ekranların ağ isteği başlatmasına gerek bırakmaz. Ağ katmanı veritabanını günceller; arayüz ise yerel sorguyu dinler. Bu ayrım çevrimdışı davranışı anlamayı ve hata ayıklamayı kolaylaştırır.

Yerel veritabanını tek doğru kaynak yapmak, sunucunun önemsiz olduğu anlamına gelmez. Sunucu, kullanıcılar ve cihazlar arasında kalıcı ve ortak durumun tutulduğu yerdir. Ancak uygulamanın ekranda göstereceği anlık çalışma durumu SQLite'tan okunur. Sunucudan alınan veriler yerel kayda işlenir; kullanıcı değişiklikleri de önce yerelde saklanır, sonra sunucuya gönderilir. Böylece ağ isteği sırasında ekran boş kalmaz ve kayıt işlemi bağlantı hatasıyla kaybolmaz.

Bekleyen işlemleri outbox tablosunda tutun

Kullanıcı çevrimdışıyken bir işi tamamladığında, uygulama yerel kaydı hemen güncellemelidir. Aynı işlem için outbox adı verilen bekleyen işlemler tablosuna da gönderilecek komut yazılır. Bir satırda işlem kimliği, gönderilecek veri, oluşturulma zamanı, deneme sayısı ve durum tutulabilir. Hassas bilgileri gereksiz yere kuyrukta saklamamak ve işlem tamamlanınca kayıt politikasına göre temizlemek gerekir.

Uygulama başladığında, bağlantı geldiğinde veya belirli aralıklarla eşitleme servisi bekleyen satırları sırayla alabilir. Her işlem başarıyla gönderilince tamamlandı olarak işaretlenir. Hata olursa kuyrukta bırakılır ve daha sonra yeniden denenir. Örneğin önce müşteri kaydı oluşturulmalı, ardından o müşteriye bağlı sipariş gönderilmelidir. Bu nedenle işlemlerin bağımlılık sırası veri modelinde açık olmalıdır. Gönderim sırasında uygulama kapanırsa işlem kaybolmamalı; sonraki açılışta kuyruktan devam edebilmelidir.

Yeniden deneme, her hatayı aynı şekilde ele almamalıdır. Geçici ağ kopması veya sunucunun kısa süreli yanıt vermemesi tekrar denemeye uygundur. Yetki hatası, geçersiz alan veya silinmiş hesap ise kullanıcı ya da uygulama müdahalesi gerektirebilir. Sık ve kesintisiz istek göndermemek için denemeler arasında artan bekleme süresi uygulanabilir. İşlem başarısız kaldığında kullanıcıya anlaşılır bir eşitleme durumu gösterin.

Ağ isteği sunucuda işlendiği halde yanıt cihaza ulaşmayabilir. Uygulama bunu başarısız sanıp aynı isteği yeniden yollarsa sipariş veya ödeme kaydı iki kez oluşabilir. Her outbox işlemi sabit ve benzersiz bir idempotency anahtarı taşımalıdır. Sunucu bu anahtarı daha önce işlediyse yeni kayıt yaratmadan önceki sonucu döndürür. Bu koruma istemci tarafındaki tekrar denemeyi güvenli kılar. Anahtar her denemede yeniden üretilmemeli; aynı mantıksal işlem boyunca aynı kalmalıdır.

Çakışma kuralını verinin anlamına göre seçin

İki cihaz aynı kaydı çevrimdışı değiştirebilir. Bağlantı kurulunca hangi değerin geçerli olacağı önceden tanımlanmalıdır. Son yazan kazanır yaklaşımında daha yeni zaman damgalı güncelleme tutulur. Taslak not veya kullanıcının son tercihi gibi alanlarda pratik olabilir; fakat saatlerin farklı olması ya da önemli bir güncellemenin üzerine yazılması risk taşır.

Sürüm numarası yaklaşımında istemci, değiştirdiği kaydın gördüğü sürümünü gönderir. Sunucu sürüm değişmemişse güncellemeyi kabul eder ve yeni sürüm üretir. Başka bir cihaz önce kaydı değiştirmişse çakışma yanıtı verir. Uygulama güncel kaydı indirip kullanıcıya seçim sunabilir veya iş kuralına göre yeniden birleştirebilir. Stok, rezervasyon ve finansal kayıt gibi yanlış güncellemenin iş sonucu doğurduğu verilerde bu kontrol daha uygundur.

Alan bazında birleştirme, iki tarafın farklı alanlarda yaptığı değişiklikleri koruyabilir. Örneğin bir cihaz açıklamayı, diğeri teslimat notunu değiştirdiyse ikisi de saklanabilir. Aynı alan iki tarafta da değiştiyse yine bir karar gerekir. Birleştirme kuralı her veri türüne göre tasarlanmalı; tüm kayıtları körlemesine bir araya getirmemelidir.

Bağlantı sinyalini internet testi sanmayın

connectivity_plus cihazın Wi-Fi veya hücresel ağ gibi bir ağa bağlı olup olmadığını bildirebilir. Bu sinyal sunucunun erişilebilir olduğunu garanti etmez. Wi-Fi yönlendiricisinin interneti olmayabilir, kurumsal ağ sunucuyu engelleyebilir veya sunucu geçici olarak kapalı olabilir. Bu yüzden bağlantı değişikliği eşitlemeyi denemek için ipucu sayılmalı; başarının kanıtı sayılmamalıdır. Gerçek isteklerin zaman aşımı, sunucu hatası ve tekrar deneme davranışı da ele alınmalıdır.

İşe başlamadan önce bağlantısız kullanılacak ekranları, saklanacak alanları ve çakışma halinde verilecek kararı listeleyin. Ardından yerel tabloları, outbox durumlarını ve eşitleme kurallarını bu listeye göre tasarlayın; uygulamayı uçak modunda ve bağlantısı sık kesilen bir ortamda deneyin.