Mobil uygulama geliştirme / DIJION
Bağlantı kesildiğinde mobil uygulama ne yapmalı?
Çevrimdışı okumayı, taslağı, bekleyen gönderimi ve yeniden eşitlemeyi ayıran uygulanabilir bir durum planı.
Bir telefonun bağlantısı var görünmesi, belirli bir isteğin tamamlanabileceği anlamına gelmez. Tünel, zayıf Wi-Fi veya yanıt vermeyen servis aynı ekranda farklı sonuçlar doğurabilir. Çevrimdışı deneyimi yalnızca bir uyarı bandı olarak tasarlamak yerine kullanıcının yapmak istediği işlemi düşünün. Buradaki yaklaşım örnek bir uygulama içindir; Dijion’un herhangi bir ürününün çevrimdışı özelliklerini tanımlamaz.
Bağlantı ve veri durumlarını birlikte tanımlayın
İlk açılışta hiç veri bulunmaması ile daha önce yüklenmiş içeriğin gösterilmesi aynı boş ekran değildir. Kullanıcı eski bilgiyi okuyabiliyorsa bunun güncelliğini anlamalıdır. Hiç yerel veri yoksa boş içerik izlenimi vermeden, neden yüklenemediğini ve nasıl devam edileceğini açıklayın.
Tüm sütunlar için tabloyu yatay kaydırabilirsiniz.
| Bağlantı | Yerel veri | Önerilen davranış |
|---|---|---|
| Var | Var | Mevcut içeriği göster; gerektiğinde yenile |
| Var | Yok | Yükleme durumunu göster; başarısızlık yolunu tanımla |
| Yok | Var | Son içeriği göster; güncellik sınırını belirt |
| Yok | Yok | İlk yüklemenin bağlantı gerektirdiğini açıkla |
Bu matris bir mimari zorunluluk değildir. Örneğin güncel bilgi gerektiren bir işlemde eski veriyi gösterip onunla işlem yaptırmak uygun olmayabilir. Veri türünü ve yanlış bilgiyle karar vermenin sonucunu ayrıca değerlendirin.
Okuma ve yazma için ayrı karar verin
İçeriği okumak ile sunucuda değişiklik yapmak farklı riskler taşır. Bir notu yerel taslak olarak tutmak mümkün olabilir; karşı tarafa mesaj iletildiğini söylemek için ise sunucu onayı gerekir. Arayüzde “Taslak kaydedildi”, “Gönderim bekliyor” ve “Gönderildi” durumlarını ayırın.
Her işlemi otomatik kuyruğa almak da doğru değildir. Zamanı geçmiş bir rezervasyon veya kullanıcının artık istemediği bir paylaşım yeniden bağlanınca kendiliğinden uygulanmamalıdır. Kuyruğa alma kararı; süresi, iptal yolu, tekrarların önlenmesi ve kullanıcının beklentisiyle birlikte tasarlanır.
Durumu kısa ve doğru metinlerle görünür kılın
Tüm sütunlar için tabloyu yatay kaydırabilirsiniz.
| Durum | Türkçe metin | Anlamı |
|---|---|---|
| Eski içerik | Son kaydedilen içerik gösteriliyor. | Güncel bilgi garantisi verilmez |
| Yerel taslak | Taslak bu cihazda kaydedildi. | Sunucuya gönderildiği söylenmez |
| Bekleyen gönderim | Gönderim bekliyor. Bağlantı gelince devam edecek. | Yalnızca gerçek kuyruk varsa kullanılır |
| Belirsiz sonuç | Gönderimin tamamlandığını doğrulayamadık. | Başarısızlık veya başarı varsayılmaz |
Metni davranıştan sonra doğrulayın. Uygulama kapatılınca taslak siliniyorsa “bu cihazda kaydedildi” yanıltıcı olabilir. Eski içeriğin tarihi gösterilecekse tarih gerçek veri güncellemesini temsil etmeli; ekranın açıldığı anı güncelleme zamanı diye sunmayın.
Yeniden bağlanma ayrı bir akıştır
Bağlantı geri geldiğinde hangi verinin önce eşitleneceğine ve ekrandaki değişikliğin kullanıcıyı nasıl etkileyeceğine karar verin. Kullanıcı bir formu düzenlerken bütün ekranı yenilemek, çevrimdışı dönemde koruduğunuz emeği dönüşte kaybetmesine neden olabilir.
Aynı kayıt iki cihazda değişmişse çakışma politikası gerekir. Son yazanın kazanması bazı basit içeriklerde yeterli olabilir; başka işlemlerde veri kaybına yol açar. Değişiklik geçmişi, birleştirme veya kullanıcı kararı gerekip gerekmediğini veri modeliyle değerlendirin. Mobil cihazdaki bağlantı göstergesi yerine isteğin gerçek sonucunu dikkate alın.
Dört kesinti anını özellikle test edin
- İlk ekran açılmadan önce bağlantıyı kesin; yükleme sonsuza kadar sürmemeli.
- Form doldurulduktan sonra gönderimden önce kesin; bilgi korunmalı.
- İstek başladıktan sonra bağlantıyı kesin; belirsiz sonuç doğru açıklanmalı.
- Bekleyen işlem varken uygulamayı kapatıp açın; durum gerçek saklama davranışıyla eşleşmeli.
Tekrar bağlanmayı da her senaryonun parçası yapın. Birden fazla kez bağlanıp ayrılmak, yinelenen gönderimleri ve yarış durumlarını ortaya çıkarabilir. Test sırasında gerçek ödeme veya kişisel veri yerine kontrollü test kayıtları kullanın.
Tasarım ve geliştirme için ortak teslim çıktısı
Her kritik işlem için okuma kaynağı, yazma onayı, yerel saklama, bekleme süresi, iptal ve çakışma kararlarını tek tabloda toplayın. Böylece tasarım metni ile kodun vaatleri karşılaştırılabilir. Android’in offline-first rehberi yerel ve ağ veri kaynaklarının ayrımını anlatır; uygulamanıza hangi yazma politikasının uygun olduğu yine ürün bağlamına bağlıdır.