Çevrimdışı-öncelikli mobil uygulama arka plan senkronu: çatışmalar, yeniden denemeler, UX

Sorun: kullanıcılar çevrimdışı düzenlerken gerçeklik değişiyor

Biri iyi bağlantıyla bir göreve başlar, sonra asansöre, depo köşesine veya metro tüneline girer. Uygulama çalışmaya devam eder, bu yüzden kullanıcı işi sürdürür. Kaydet'e dokunur, not ekler, durumu değiştirir, belki yeni bir kayıt oluşturur. Ekran hemen güncellendiği için her şey yolunda gibi görünür.

Daha sonra bağlantı geri gelir ve uygulama arka planda yakalama yapmaya çalışır. İşte arka plan senkronu insanları şaşırtabilir.

Uygulama dikkatli değilse aynı eylem iki kez gönderilebilir (çoğaltmalar) veya sunucudaki daha yeni bir değişiklik kullanıcının yaptığı şeyi üzerine yazabilir (kaybolan düzenlemeler). Bazen uygulama aynı anda “Kaydedildi” ve “Kaydedilmedi” gibi kafa karıştırıcı durumlar gösterir; bir kayıt senkron sonrası görünür, kaybolur ve yeniden görünür.

Çatışma basittir: aynı şeye iki farklı değişiklik yapılmış ve uygulama bunları uzlaştırmaya fırsat bulamamıştır. Örneğin, bir destek görevlisi çevrimdışıyken bir bileti Öncelik: Yüksek olarak ayarlar, ancak çevrimiçi bir ekip arkadaşı biletin kapandığını işaretler. Telefon tekrar bağlandığında, kurallar olmadan her iki değişiklik de düzgün uygulanamaz.

Amaç çevrimdışını kusursuz yapmak değil. Amaç onu öngörülebilir kılmak:

• İnsanlar işlerini kaybedeceklerinden korkmadan çalışmaya devam edebilsin.
• Senkron daha sonra gizemli çoğaltmalar olmadan gerçekleşsin.
• Dikkat gerektiren bir durum olduğunda uygulama ne olduğunu ve sonraki adımı açıkça söylesin.

Bu, Kotlin/SwiftUI ile elle kod yazarken veya AppMaster gibi bir kod-suz platformla yerel uygulamalar oluştururken aynı şekilde doğrudur. Zor olan UI bileşenleri değil; kullanıcının çevrimdışıyken dünyaya göre uygulamanın nasıl davranacağını kararlaştırmaktır.

Basit bir çevrimdışı-öncelikli model (jargonsuz)

Çevrimdışı-öncelikli bir uygulama telefonun bazen ağı kaybedeceğini varsayar, ama uygulama yine de kullanılabilir hissettirmelidir. Ekranlar yüklenmeli ve düğmeler sunucu ulaşılamazken bile çalışmalıdır.

Dört terim çoğu durumu kapsar:

• Yerel önbellek: uygulamanın anında bir şey gösterebilmesi için cihazda saklanan veri.
• Senkron kuyruğu: kullanıcı ağsızken (veya ağ dalgalı iken) yaptığı işlemlerin listesi.
• Sunucu gerçeği: nihayetinde herkesin paylaştığı backend versiyonu.
• Çatışma: kullanıcının kuyruğa alınmış değişikliğinin artık sunucu versiyonuna temiz uygulanamaması.

Okumaları yazmadan ayrı tutmak faydalıdır.

Okumalar genelde basittir: en iyi mevcut veriyi göster (çoğunlukla yerel önbellekten), sonra ağ geri gelince sessizce yenile.

Yazmalar farklıdır. "Tüm kaydı bir kerede kaydetmeye" güvenme. Bu çevrimdışıyken kırılır.

Bunun yerine kullanıcının ne yaptığını küçük girdiler olarak bir değişiklik günlüğüne kaydet. Örneğin: “durumu Onaylandı yap”, “X yorumunu ekle”, “miktarı 2'den 3'e değiştir”. Her giriş zaman damgası ve bir ID ile senkron kuyruğuna gider. Arka plan senkronu sonra bunları iletmeye çalışır.

Kullanıcı değişiklikler beklemede iken çalışmaya devam eder ve öğeler beklemeden senkron olmuşa geçer.

AppMaster gibi bir kod-suz platform kullanıyorsanız da aynı yapı taşlarını istersiniz: hızlı ekranlar için önbellekli okumalar ve yeniden denenebilen, birleştirilebilen veya çatışma olduğunda işaretlenebilen açık bir kullanıcı eylemi kuyruğu.

Gerçekte çevrimdışı desteği gerçekten neyin gerektirdiğine karar verin

Çevrimdışı-öncelikli, “her şey bağlantısız çalışır” gibi gelebilir, ama bu vaat birçok uygulamayı zor durumda bırakır. Gerçekten çevrimdışı desteğinden faydalanan parçaları seçin ve kalanları açıkça çevrimiçi-özel tutun.

Kullanıcı niyeti açısından düşünün: insanlar bodrumda, uçakta veya düzensiz servis olan bir depoda ne yapmak zorunda? İyi bir varsayılan, günlük işleri yaratan/güncelleyen eylemleri desteklemek ve "en güncel gerçeklik" önemli olduğu durumları engellemektir.

Pratik bir set genelde çekirdek kayıtların oluşturulmasını ve düzenlenmesini (notlar, görevler, muayeneler, biletler), taslak yorumları ve fotoğraf eklemeyi (önce yerelde sakla, sonra yükle) içerir. Silme de çalışabilir ama sunucu onaylayana kadar geri almanın mümkün olduğu yumuşak silme daha güvenlidir.

Gerçek zamanlı kalması gerekenleri belirleyin: ödemeler, izin değişiklikleri, onaylar ve hassas veri içeren her şey genelde bir bağlantı gerektirmelidir. Kullanıcı sunucuyu kontrol etmeden eylemin geçerli olduğundan emin olamıyorsa, çevrimdışı izin verme. Gizemli bir hata yerine açık bir “bağlantı gerekiyor” mesajı gösterin.

Tazelik beklentilerini belirleyin. “Çevrimdışı” ikili değildir. Verinin ne kadar bayat olmasına izin verildiğini tanımlayın: dakikalar, saatler veya "uygulama bir sonraki açıldığında" gibi. Bu kuralı UI'da düz sözlerle koyun: “Son güncelleme 2 saat önce” ve “Çevrimiçi olunca senkronlanıyor.” gibi.

Son olarak, yüksek çatışma olasılığı olan verileri erken işaretleyin. Envanter sayımları, paylaşılan görevler ve ekip mesajları hızlıca birden fazla kişi tarafından düzenlendiği için çatışma mıknatısıdır. Bunlarda çevrimdışı düzenlemeleri taslaklarla sınırlamayı veya tek bir değeri üzerine yazmak yerine değişiklikleri ayrı olaylar olarak yakalamayı düşünün.

AppMaster ile inşa ediyorsanız, bu karar veri ve iş kurallarını modellemenize yardımcı olur, böylece uygulama çevrimdışı güvenli taslaklar saklarken riskli eylemleri çevrimiçi tutar.

Senkron kuyruğunu tasarlama: her değişiklik için ne saklamalısınız

Kullanıcı çevrimdışı çalışırken, “veritabanını senkron etme”ye çalışmayın. Kullanıcının eylemlerini senkron edin. Açık bir eylem kuyruğu arka plan senkronunun belkemiğidir ve işler bozulduğunda anlaşılması kolay kalır.

Eylemleri küçük ve insan diline yakın tutun, kullanıcının gerçekten ne yaptığıyla hizalanmış:

• Kayıt oluştur
• Belirli alan(lar)ı güncelle
• Durumu değiştir (gönder, onayla, arşivle)
• Sil (tercihen onaylanana kadar yumuşak silme)

Küçük eylemler hata ayıklamayı kolaylaştırır. Destek bir kullanıcıya yardım ederken “Durum: Taslak -> Gönderildi olarak değiştirildi” gibi ifadeler büyük bir JSON blobunu incelemekten çok daha anlaşılır.

Her kuyruğa alınmış eylem için, güvenli şekilde yeniden oynatmak ve çatışma tespit etmek için yeterli meta veri saklayın:

• Kayıt tanımlayıcısı (ve yeni kayıtlar için geçici yerel ID)
• Eylem zaman damgası ve cihaz tanımlayıcısı
• Kaydın beklenen versiyonu (veya bilinen son güncelleme zamanı)
• Payload (değiştirilen alanlar ve mümkünse eski değer)
• İdempotans anahtarı (yeniden denemeler çoğaltma yaratmasın diye benzersiz eylem ID'si)

Bu beklenen versiyon çatışmayı dürüstçe ele almanın anahtarıdır. Sunucu versiyonu ilerlediyse, sessizce başkasını ezmek yerine duraklayıp karar sormak mümkün olur.

Bazı eylemler kullanıcı tarafından bir adım olarak görüldüğü için birlikte uygulanmalıdır. Örneğin, “Sipariş oluştur” artı “üç satır öğesi ekle” işlem çiftinin ya tümüyle başarılı olması ya da tümüyle beklemede kalması istenir. Bunları birlikte gönderebilecek şekilde bir grup ID'si (veya işlem ID'si) saklayın.

Elle mi inşa ediyorsunuz yoksa AppMaster ile mi, amaç aynı: her değişiklik bir kez kaydedilir, güvenli şekilde yeniden oynatılır ve uyuşmazlık çıktığında açıklanabilir olur.

Kullanıcılara açıklayabileceğiniz çatışma çözüm kuralları

Çatışmalar normaldir. Amaç onları imkansız kılmak değil. Amaç nadir, güvenli ve gerçekleştiğinde açıklaması kolay olmalarını sağlamaktır.

Çatışmanın hangi anda olduğunu isimlendirin: uygulama bir değişiklik gönderir ve sunucu der ki, “Bu kayıt, düzenlemeye başladığınız versiyon değil.” Bu yüzden versiyonlama önemlidir.

Her kayıtta iki değeri tutun:

• Sunucu versiyonu (sunucuda şu anki versiyon)
• Beklenen versiyon (telefonun düzenlediğini düşündüğü versiyon)

Beklenen versiyon eşleşiyorsa güncellemeyi kabul edin ve sunucu versiyonunu yükseltin. Eşleşmiyorsa çatışma kuralınızı uygulayın.

Her veri türü için bir kural seçin (her şey için tek kural değil)

Farklı veriler farklı kurallar gerektirir. Bir durum alanı uzun bir notla aynı değildir.

Kullanıcıların kolayca anlayacağı kurallar:

• Son yazan kazanır: görüntü tercihleri gibi düşük riskli alanlar için uygun.
• Alanları birleştir: alanlar bağımsızsa (durum vs notlar) en iyi sonuç.
• Kullanıcıya sor: fiyat, izinler veya toplamlar gibi yüksek riskli düzenlemeler için en iyi yol.
• Sunucu kazanır, bir kopya sakla: sunucu değeri tutulur, ancak kullanıcı düzenlemesini yeniden uygulayabilmesi için taslak olarak kaydet.

AppMaster'da bu kurallar görsel mantığa iyi uyum sağlar: versiyonları kontrol et, alanları karşılaştır, sonra yolu seç.

Silmelerin nasıl davranacağına karar verin (aksi halde veri kaybedersiniz)

Silme en zor durumdur. Kaydı hemen kaldırmak yerine bir mezar taşı ("silindi" işareti) kullanın. Sonra bir yerde o kaydı düzenleyen biriyle karşılaşırsanız ne olacağını karar verin.

Açık bir kural: “Silmeler kazanır, ama geri yüklenebilir.” Örnek: bir satış temsilcisi çevrimdışıyken bir müşteri notunu düzenlerken bir yönetici o müşteriyi silerse, senkron çalıştığında uygulama “Müşteri silindi. Notunuzu uygulamak için geri yükleyin mi?” diye sorabilir. Bu, sessiz kayıpları önler ve kontrolü kullanıcıya verir.

Yeniden denemeler ve hata durumları: öngörülebilir tutun

Senkron başarısız olduğunda çoğu kullanıcı nedenini umursamaz. Onlar işlerinin güvende olup olmadığını ve sonraki adımın ne olacağını bilmek ister. Öngörülebilir bir durum seti panik ve destek taleplerini önler.

Küçük, görünür bir durum modeliyle başlayın ve ekranlar arasında tutarlı tutun:

• Queued: cihazda kaydedildi, ağ bekleniyor
• Syncing: şimdi gönderiliyor
• Sent: sunucu tarafından onaylandı
• Failed: gönderilemedi, yeniden denenecek veya dikkat gerektiriyor
• Needs review: gönderildi ama sunucu reddetti veya işaretledi

Yeniden denemeler pil ve veri üzerinde nazik olmalı. İlk başta hızlı denemeler yapın (kısa sinyal kopmaları için), sonra yavaşlayın. 1 dk, 5 dk, 15 dk, sonra saatlik gibi basit bir geri çekilme (backoff) mantığı anlaşılması kolaydır. Ayrıca sadece anlamlı olduğunda yeniden deneyin (geçersiz bir değişiklik için durmadan yeniden denemeyin).

Hataları farklı şekilde ele alın, çünkü sonraki adım farklıdır:

• Çevrimdışı / ağ yok: kuyruğa kal, çevrimiçi olunca yeniden dene
• Zaman aşımı / sunucu ulaşılamaz: başarısız olarak işaretle, backoff ile otomatik yeniden dene
• Kimlik doğrulama süresi doldu: senkronu duraklat ve kullanıcıdan tekrar oturum açmasını iste
• Doğrulama başarısız (geçersiz girdi): inceleme gerekli, düzeltilecekleri göster
• Çatışma (kayıt değişti): inceleme gerekli, çatışma kurallarınıza yönlendir

İdempotans yeniden denemeleri güvenli kılan şeydir. Her değişiklik benzersiz bir eylem ID'sine (genellikle UUID) sahip olmalı ve bu istekle birlikte gönderilmelidir. Uygulama aynı değişikliği tekrar gönderirse, sunucu ID'yi tanımalı ve çoğaltma oluşturmak yerine aynı sonucu döndürmelidir.

Örnek: bir teknisyen çevrimdışıyken tamamlanan bir işi kaydeder, sonra asansöre girer. Uygulama güncellemeyi gönderir, zaman aşımına uğrar ve daha sonra yeniden dener. Bir eylem ID'si ile ikinci gönderim zararsızdır. Olmazsa, tekrarlar "tamamlandı" olaylarını çoğaltabilir.

AppMaster'da bu durumları ve kuralları senkron sürecinizde birinci sınıf alanlar ve mantık olarak ele alın, böylece Kotlin ve SwiftUI uygulamalarınız her yerde aynı şekilde davranır.

Bekleyen değişiklikler UX'i: kullanıcı ne görür ve ne yapabilir

İnsanlar çevrimdışı uygulamayı kullanırken güvende hissetmelidir. İyi bir “bekleyen değişiklikler” UX'i sakin ve öngörülebilirdir: çalışmanın cihazda kaydedildiğini kabul eder ve sonraki adımı açıkça gösterir.

İnce bir gösterge uyarı bandından daha iyidir. Örneğin, başlıkta küçük bir “Senkronize ediliyor” ikonu veya düzenlemelerin yapıldığı ekranda sessiz bir “3 bekleyen” etiketi gösterin. Korkutucu renkleri gerçek tehlike için saklayın (örneğin “yükleme yapılamıyor çünkü oturumunuz kapandı”).

Kullanıcılara olan biteni anlamaları için bir yer verin. Basit bir Outbox veya Bekleyen değişiklikler ekranı öğeleri "Ticket 104'e yorum eklendi" veya "Profil fotoğrafı güncellendi" gibi sade ifadelerle listeler. Bu şeffaflık paniği azaltır ve destek taleplerini düşürür.

Kullanıcıların yapabilecekleri

Çoğu kişi sadece birkaç işleve ihtiyaç duyar ve bunlar uygulama boyunca tutarlı olmalı:

• Şimdi yeniden dene
• Yeniden düzenle (daha yeni bir değişiklik oluşturur)
• Yerel değişikliği bırak
• Detayları kopyala (sorun bildirirken faydalı)

Durum etiketlerini basit tutun: Pending, Syncing, Failed. Bir şey başarısız olduğunda insan gibi açıklayın: “Yüklenemedi. İnternet yok.” veya “Bir başkası bu kaydı değiştirdiği için reddedildi.” Hata kodlarından kaçının.

Tüm uygulamayı engellemeyin

Sadece gerçekten çevrimiçi olmayı gerektiren eylemleri engelleyin, örneğin “Stripe ile ödeme yap”. Diğer her şey çalışmaya devam etmelidir; son verileri görüntülemek ve yeni taslaklar oluşturmak dahil.

Gerçekçi bir akış: bir saha teknisyeni bir iş raporunu bodrumda düzenler. Uygulama “1 bekleyen” gösterir ve çalışmaya devam etmelerine izin verir. Sonra “Senkronize ediliyor” olur ve otomatik olarak temizlenir. Hata olursa iş raporu erişilebilir kalır, “Failed” ile işaretlenir ve tek bir “Şimdi yeniden dene” düğmesi sunulur.

AppMaster ile inşa ediyorsanız, bu durumları her kaydın parçası olarak modelleyin (pending, failed, synced) ki UI bunları özel durum ekranları olmadan her yerde yansıtabilsin.

Çevrimdışı iken kimlik, izinler ve güvenlik

Çevrimdışı mod güvenlik modelinizi değiştirir. Kullanıcı bağlantı yokken eylemler yapabilir, ama sunucu yine de gerçeklik kaynağıdır. Her kuyruğa alınmış değişikliği "talep edildi" olarak düşünün, "onaylandı" değil.

Çevrimdışıyken oturum süresi dolması

Tokenlar süresi dolabilir. Bu durumda çevrimdışıyken kullanıcı düzenlemeye devam etmesine izin verin ve bunları beklemede saklayın. Ödemeler veya yönetici onayları gibi sunucu onayı gerektiren eylemleri tamamlandı gibi göstermeyin. Başarılı kimlik yenilemesine kadar bunları beklemede tutun.

Uygulama çevrimiçi olduğunda önce sessiz bir yenileme deneyin. Yeniden oturum açmayı kullanıcıdan istemeniz gerekirse, bir kez isteyin ve sonra senkronu otomatik sürdürün.

Yeniden oturum açıldıktan sonra her kuyruğa alınmış öğeyi göndermeden önce yeniden doğrulayın. Kullanıcı kimliği değişmiş olabilir (paylaşılan cihaz) ve eski düzenlemeler yanlış hesaba gönderilmemelidir.

İzin değişiklikleri ve yasaklanmış eylemler

İzinler kullanıcı çevrimdışıyken değişebilir. Çevrimdışıyken izin verilen bir düzenleme ertesi gün yasaklanmış olabilir. Bunu açıkça ele alın:

• Her kuyruğa alınmış eylem için sunucu tarafında izinleri yeniden kontrol edin
• Yasaksa o öğeyi durdurun ve net bir neden gösterin
• Kullanıcının yerel düzenlemesini saklayın ki kopyalayabilsin veya erişim isteyebilsin
• "Yasak" hataları için tekrarlı yeniden denemelerden kaçının

Örnek: bir destek görevlisi uçakta çevrimdışıyken bir müşteri notunu düzenler. Gece boyunca rolü kaldırılırsa, senkron çalıştığında sunucu güncellemeyi reddeder. Uygulama “Yüklenemiyor: artık erişiminiz yok” göstermeli ve notu yerel taslak olarak tutmalıdır.

Çevrimdışı saklanan hassas veriler

Ekranları render etmek ve kuyruğu yeniden oynatmak için gereken minimumu saklayın. Yerel depolamayı şifreleyin, sırları önbelleğe almayın ve çıkış için net kurallar koyun (örneğin: yerel verileri sil veya yalnızca açık kullanıcı onayıyla taslakları sakla). AppMaster ile çalışıyorsanız, kimlik modülünden başlayın ve kuyruğun her zaman geçerli bir oturum bekleyecek şekilde tasarlandığından emin olun.

Kayıp işe veya çoğaltılan kayıtlara yol açan yaygın tuzaklar

Çoğu çevrimdışı hatası karmaşık değildir. Mükemmel Wi-Fi ile test ederken zararsız görünen birkaç küçük karardan kaynaklanır, sonra gerçek iş akışında bozulur.

Yaygın bir hata sessiz üzerine yazmalardır. Uygulama daha eski bir versiyonu yükler ve sunucu bunu kontrol etmeden kabul ederse, başkasının daha yeni düzenlemesini silebilirsiniz ve kimse fark etmez. Versiyon numarası (veya "son güncelleme" damgası) ile senkron yapın ve sunucu ilerlediyse üzerine yazmayı reddedin; böylece kullanıcı net bir seçim yapar.

Bir diğer tuzak yeniden deneme fırtınasıdır. Telefon zayıf bir bağlantı aldığında, uygulama her birkaç saniyede bir backend'i dövebilir; pil tüketir ve çoğaltmalar yaratır. Yeniden denemeler sakin olmalı: her başarısızlıktan sonra yavaşlayın ve binlerce cihaz aynı anda yeniden denememesi için biraz rastgelelik ekleyin.

Kayıp işe veya çoğaltmalara en sık yol açan hatalar:

• Her hatayı "ağ" olarak ele alma: kalıcı hataları (geçersiz veri, izin yok) geçici hatalardan (zaman aşımı) ayırın.
• Senkron hatalarını gizleme: insanlar neyin başarısız olduğunu göremezse görevi tekrar yapar ve iki kayıt oluşturur.
• Aynı değişikliği iki kez göndermek: her isteğe benzersiz bir istek ID'si ekleyin ki sunucu çoğaltmayı algılayıp yok sayabilsin.
• Metin alanlarını otomatik birleştirip kimseye söylememe: sonucu otomatik birleştiriyorsanız, gerekliyse kullanıcıya inceleme imkanı verin.
• Çevrimdışı yeni kayıtlar oluştururken stabil ID kullanmama: geçici yerel ID kullanın ve yüklemeden sonra sunucu ID'siyle eşleştirin, böylece sonraki düzenlemeler ikinci bir kopya oluşturmaz.

Hızlı örnek: bir saha teknisyeni çevrimdışı yeni bir “Site Visit” oluşturur, sonra tekrar bağlanmadan önce iki kez düzenler. Eğer oluşturma çağrısı yeniden denendiğinde iki sunucu kaydı oluşturursa, sonraki düzenlemeler yanlış kayda bağlanabilir. Stabil ID'ler ve sunucu tarafı deduplikasyonu bunu önler.

AppMaster ile inşa ediyorsanız, kurallar değişmez. Fark nerede uygulanacağıdır: senkron mantığınızda, veri modelinizde ve "failed" ile "sent" değişiklikleri gösteren ekranlarda.

Örnek senaryo: iki kişi aynı kaydı düzenliyor

Bir saha teknisyeni Maya, sinali olmayan bir bodrumda "Job #1842" bileti üzerinde çalışıyor. Durumu "In progress"ten "Completed"a değiştirir ve not ekler: “Vana değiştirildi, test OK.” Uygulama hemen kaydeder ve bunu beklemede olarak gösterir.

Yukarıda, ekip arkadaşı Leo aynı işi çevrimiçi olarak düzenliyor. Müşteri aradığı için planlanan zamanı değiştirir ve işi farklı bir teknisyene atar.

Maya tekrar sinyal aldığında, arka plan senkronu sessizce başlar. Öngörülebilir, kullanıcı-dostu bir akışta şu olur:

1. Maya'nın değişikliği hâlâ senkron kuyruğunda (iş ID'si, değiştirilen alanlar, zaman damgası ve en son gördüğü kayıt versiyonu).
2. Uygulama yüklemeye çalışır. Sunucu cevap verir: “Bu iş, sizin gördüğünüzden beri güncellendi” (çatışma).
3. Çatışma kuralınız çalışır: durum ve not birleştirilebilir, ama atama sunucudaki daha yeni değişikliğe göre kazanır.
4. Sunucu birleştirilmiş sonucu kabul eder: durum = "Completed" (Maya'dan), not eklenir (Maya'dan), atanan teknisyen = Leo'nun seçimi (Leo'dan).
5. İş Maya'nın uygulamasında yeniden açılır ve açık bir afiş gösterir: “Güncellemelerle senkronize edildi. Atama çevrimdışıyken değiştirildi.” Küçük bir "İncele" eylemi nelerin değiştiğini gösterir.

Buna bir hata anı ekleyin: Maya'nın oturum tokeni çevrimdışıyken süresi doldu. İlk senkron denemesi “Oturum açılması gerekiyor” ile başarısız olur. Uygulama düzenlemelerini tutar, onları "Duraklatıldı" olarak işaretler ve tek bir basit istem gösterir. Maya oturum açtıktan sonra senkron otomatik olarak devam eder, hiçbir şeyi yeniden yazmasına gerek kalmaz.

Doğrulama problemi varsa (örneğin, "Completed" olmak için fotoğraf gerekli), uygulama tahminde bulunmamalıdır. Öğe "Dikkat gerekli" olarak işaretlenir, nelerin eklenmesi gerektiği açıkça söylenir, sonra yeniden gönderilmesine izin verilir.

AppMaster gibi platformlar burada yardımcı olabilir: kuyruğu, çatışma kurallarını ve bekleyen durum UX'ini görsel olarak tasarlayabilir, yine de gerçek yerel Kotlin ve SwiftUI uygulamaları dağıtabilirsiniz.

Kısa kontrol listesi ve sonraki adımlar

Çevrimdışı senkronu uçtan uca test edilebilen bir özellik olarak ele alın, yamalar yığını olarak değil. Amaç basit: kullanıcılar işlerinin kaydedilip kaydedilmediğini asla merak etmesin ve uygulama sürpriz çoğaltmalar yaratmasın.

Temelin sağlam olduğunu doğrulamak için kısa bir kontrol listesi:

• Senkron kuyruğu cihazda saklanıyor ve her değişikliğin stabil bir yerel ID'si ile (varsa) sunucu ID'si var.
• Açık durumlar mevcut (queued, syncing, sent, failed, needs review) ve tutarlı kullanılıyor.
• İstekler idempotent (yeniden denemeye güvenli) ve her işlem bir idempotans anahtarı içeriyor.
• Kayıtlarda versiyonlama var (updatedAt, revizyon numarası veya ETag) böylece çatışmalar tespit edilebiliyor.
• Çatışma kuralları düz dille yazılmış (ne kazanır, ne birleştirilir, ne zaman kullanıcıya sorulur).

Bunlar yerinde olduğunda, deneyimin veritabanı modeliniz kadar güçlü olduğundan emin olun. Kullanıcılar neyin beklemede olduğunu görebilmeli, neyin başarısız olduğunu anlayabilmeli ve eylemde bulunabilmeli, işlerini kaybetme korkusu olmadan.

Gerçek hayat senaryolarıyla test edin:

• Uçak modu düzenlemeleri: oluştur, güncelle, sil, sonra yeniden bağlan.
• Dalgalı ağ: senkron ortasında bağlantı kopması ve yeniden denemelerin çoğaltmaması.
• Uygulama kapatıldı: gönderim sırasında zorla kapat, yeniden aç, kuyruğun kurtarıldığını doğrula.
• Saat kayması: cihaz zamanı yanlışsa bile çatışma tespitinin çalıştığını doğrula.
• Çift dokunuş: kullanıcı Kaydet'e iki kez basar, bunun tek sunucu değişikliği olduğunu doğrula.

UI'yi cilalamadan önce tam akışı prototipleyin. Bir ekran, bir kayıt türü ve bir çatışma vakası (aynı alanı iki düzenleme) ile başlayın. Basit bir senkron durum alanı, başarısızlıklar için bir Yeniden Dene düğmesi ve net bir çatışma ekranı ekleyin. Bu çalıştığında, diğer ekranlar için tekrarlayın.

Eğer kodsuz inşa ediyorsanız, AppMaster (appmaster.io) native Kotlin ve SwiftUI uygulamalarının yanı sıra backend de üretebilir, böylece kuyruğa, versiyon kontrollerine ve kullanıcıya yönelik durumlara odaklanabilirsiniz; her şeyi baştan elle bağlamak zorunda kalmazsınız.