Mobil Uygulama: Çevrimdışı Çalışma ve Senkronizasyon

“Çevrimdışı çalışır” vaadini işlem bazında tanımlayın

Çevrimdışı kullanım tek bir özellik değildir. Ürün listesini okumak, sipariş taslağı oluşturmak, stok ayırmak ve ödeme almak farklı gereksinimlerdir. Bağlantı olmadan katalog görüntülenebilirken, stok veya fiyatın son durumunu doğrulamak için sunucuya ihtiyaç duyulabilir. Ürünün neyi ne zaman garanti ettiği açık olmalıdır.

Önerilen iş listesi her eylemi üç gruba ayırır: yerel olarak tamamlanabilen, sonradan eşitlenebilen ve canlı onay gerektiren. Varsayımsal bayi ziyaret uygulamasında not yazmak ilk grupta, sipariş taslağı ikinci grupta, merkezde kesin stok ayırmak üçüncü grupta olabilir. Bu dağılım örnektir; işletmenin kurallarıyla değiştirilmelidir.

Android’in offline-first mimari rehberi yerel ve ağ veri kaynaklarının birlikte ele alınmasını, kuyruk ve çakışma çözümü gibi konuların tasarlanmasını anlatır. Buradaki rehber de bu kavramları ürünün iş davranışına bağlayan bir karar çerçevesi sunar. [1]

Cihazda kaydedildi ile sunucuda onaylandı farklı durumlardır

Önerilen durum modeli taslak, cihazda kayıtlı, gönderim bekliyor, gönderiliyor, sunucuda onaylandı ve inceleme gerekiyor adımlarını ayırır. Kullanıcıya bu durumların hepsini teknik terimlerle göstermek şart değildir; fakat yanlış güven vermemek gerekir. “Cihazınıza kaydedildi, bağlantı kurulduğunda gönderilecek” ifadesi “sipariş tamamlandı” ifadesinden daha doğru olabilir.

Uygulamanın kapanması, yeniden başlaması ve kullanıcının aynı ekrana tekrar gelmesi bu durumları bozmamalıdır. Bekleyen işlemler yalnız ekran belleğinde tutuluyorsa, uygulama kapandığında kaybolabilir. Önerilen tasarımda uygun yerel kalıcılık ve güvenli saklama gereksinimleri birlikte ele alınır. Hassas veri için cihaz kaybı, oturum kapanışı ve erişim sınırları ayrıca değerlendirilmelidir.

Yeniden gönderimi aynı iş niyetiyle eşleştirin

Telefon isteği gönderip yanıtı alamayabilir. Yeniden denemede yeni sipariş oluşturmak yerine, aynı iş niyetini tanıyacak bir kimlik tasarlanmalıdır. Bu kimlik kullanıcı işlemi başlattığında oluşturulabilir ve tekrarlar boyunca korunabilir. Ancak kimliğin tanınması ve iş etkisinin güvenli olması sunucu tarafında da uygulanmalıdır.

Amazon’un idempotency rehberi, aynı niyetle yinelenen çağrıların ek yan etki üretmemesini ve istek kimliğiyle davranışın tanımlanmasını ele alır. Mobil istemcide tek başına düğmeyi devre dışı bırakmak, ağ tekrarını çözmez. [2]

Varsayımsal sipariş kuyruğunda yerel işlem kimliği, kuruluş bağlamı, içerik sürümü ve son deneme durumu tutulabilir. Kullanıcı aynı üründen ikinci bir gerçek sipariş verdiğinde yeni niyet oluşur. Buna karşılık aynı taslağın bağlantı nedeniyle tekrar iletilmesi aynı niyet olarak kalır. Bu ayrımı yalnızca aynı ürün ve tutarın tekrar gelmesine göre kurmayın.

Çakışma kuralını veri türüne göre seçin

İki çalışan aynı müşterinin kaydını bağlantısızken değiştirebilir. Birinin telefon numarası düzeltmesiyle diğerinin teslimat notu eklemesi farklı alanları etkiliyor olabilir. İki kişinin aynı teslimat gününü değiştirmesi ise doğrudan çakışmadır. Bütün kayıtları tek bir “son yazan kazanır” kuralıyla ele almak, bazı değişiklikleri sessizce kaybettirebilir.

Android rehberi çakışma çözümünde sürümleme ihtiyacını ve last-write-wins gibi yaklaşımları açıklar; seçimin uygulamanın gereksinimine bağlı olduğunu belirtir. Bu nedenle hangi veri türünde otomatik birleştirme, hangi durumda kullanıcı incelemesi yapılacağını ürün kararı olarak yazın. [1]

Önerilen örnekte serbest notlar ayrı kayıt olarak eklenebilir; fiyat onayı merkezi karar olabilir; müşteri adresi çakışması incelemeye düşebilir. Sunucu sürüm numarası, istemcinin hangi sürümü değiştirerek gönderdiğini anlamaya yardımcı olacak biçimde tasarlanabilir. Cihaz saatini her durumda kesin doğruluk kaynağı saymayın; saat yanlış veya değiştirilmiş olabilir.

Çevrimdışı fiyat ve stok bilgisinin yaşını gösterin

Bağlantısız katalogdaki stok bilgisinin güncel olduğu varsayılmamalıdır. Örneğin kullanıcı son eşitlemenin zamanını görebilir ve siparişin merkez onayına tabi olduğunu anlayabilir. Katalogdaki fiyatın sonradan değişmesi halinde uygulamanın sessizce yeni tutarla sipariş tamamlaması yerine hangi onayın gerekeceğini tanımlayın.

Varsayımsal akışta taslak sunucuya ulaştığında fiyat yeniden değerlendirilir. Fark varsa taslak inceleme durumuna geçer ve kullanıcıya değişen alanlar gösterilir. Bu yöntem her işletmede zorunlu değildir; sözleşme ve fiyatlama kurallarıyla uyumlu ürün kararı verilmelidir. Teknik olarak aktarılabilen bir kayıt, ticari olarak otomatik onaylanabilir olmayabilir.

Stok konusunda da taslak miktarı ile kesin ayrılan miktarı ayırın. Kullanıcıya hangi sonucun garanti edildiğini açıklayın. Çevrimdışı deneyimin iyi olması, merkezde bulunmayan stoğu varmış gibi sunmak değildir. Doğru sınırlar, akıcı ekran kadar önemlidir.

Oturum ve kuruluş değişimini kuyrukla birlikte düşünün

Bir kullanıcı A kuruluşunda taslak oluşturup çıkış yaptıktan sonra B kuruluşunda oturum açarsa bekleyen kayıt ne olacak? Uygulama, önceki kuyruğu yeni hesabın yetkisiyle göndermemelidir. Önerilen tasarımda işlem sahibi ve kuruluş bağlamı kuyruk kaydıyla ilişkilendirilir; gönderim anındaki yetki ayrıca kontrol edilir.

Hesap kapatıldığında veya kullanıcı yetkisi kaldırıldığında bekleyen işin davranışı belirlenmelidir. Kayıt otomatik silinecek, uygun biçimde saklanacak veya yetkili kullanıcıya inceleme için gösterilecek olabilir. Seçim veri saklama ve güvenlik gereksinimleriyle birlikte değerlendirilmelidir. Uygulama ekibi bu kararı görünmez bir teknik varsayıma bırakmamalıdır.

Arka planda eşitlemenin hangi koşullarda yapılabildiği hedef platformlarda ayrıca doğrulanmalıdır. Kullanıcıya kesin bir saniye sözü vermek yerine uygulama açıkken, yeniden açıldığında ve bağlantı geri geldiğinde beklenen durumları test edin. Platforma özgü davranışlar tek bir cihazdaki başarılı denemeyle genellenmemelidir.

Gerçekçi bir kabul turu oluşturun

Önerilen testte uygulamayı bağlantılı açın, katalog alın, bağlantıyı kesin, taslak oluşturun, uygulamayı kapatıp yeniden açın ve bağlantıyı geri getirin. Kayıt korunuyor mu? Tek merkez siparişi oluşuyor mu? Durum doğru gösteriliyor mu? Ardından bu senaryoyu fiyat değişikliği, kaldırılmış yetki ve çakışan kayıtla tekrarlayın.

Her mobil uygulama çevrimdışı tasarlanmalı mı?

Hayır. Kullanım ortamı ve iş ihtiyacı belirleyicidir. Fakat bağlantı kesildiğinde kullanıcıya ne gösterileceği her ağ kullanan uygulamada düşünülmelidir. Çevrimdışı özellik yapılmıyorsa bile kaybolmayan taslak ve anlaşılır hata davranışı değerlendirilebilir.

Tek bir geliştirme altyapısı bu sorunları otomatik çözer mi?

Hayır. Yerel saklama aracı veya mobil çatı yardımcı olabilir; ancak tekrar niyeti, çakışma, yetki ve fiyat onayı iş kurallarıdır. Güçlü mobil ürün, yalnızca ekranda hızlı görünen değil; belirsiz bağlantıda da kullanıcıya doğru durum bildiren üründür.