Offline-first nedir; hangi işlemler çevrimdışı çalışmalı?
Offline-first, ürünün temel işlevlerinin tamamını veya belirlenen bir bölümünü sürekli internet bağlantısına bağımlı olmadan sunmasıdır. Bu, her işlemi çevrimdışı onaylamak anlamına gelmez. Android’in mimari rehberi de çevrimdışı okuma ile çevrimdışı yazmayı ayrı tasarım kararları olarak ele alır.
Bir saha ziyareti senaryosu düşünün: çalışan görev listesini görmeli, not almalı ve fotoğraf ekleyebilmelidir. Buna karşılık merkezdeki son stok miktarına bağlı bir rezervasyon, sunucu onayı gerektirebilir. Keşif aşamasında her işlem için ‘bağlantısız okunabilir’, ‘taslak olarak kaydedilebilir’ veya ‘çevrimiçi onay gerekir’ kararı vermek, belirsiz bir offline özelliğinden daha yararlıdır.
Yerel veri ile sunucu verisinin sorumluluğunu ayırın
Arayüzün okuyacağı yerel veri katmanı, bağlantı değişirken tutarlı bir deneyim sağlar. Ağdan gelen güncellemeler bu katmana işlenir; ekranlar farklı bağlantı durumlarında farklı veri kaynaklarına geçmek zorunda kalmaz. Yerel kopyanın güncel olmama ihtimali ise kullanıcıdan saklanmamalıdır.
Örnekte görev bilgisi, ziyaret notu ve büyük fotoğraf dosyası aynı yaşam döngüsüne sahip değildir. Hangi verinin önceden indirileceğini, ne kadar saklanacağını ve ne zaman temizleneceğini ayrı kararlaştırın. ‘Son güncelleme’ bilgisi, güncelliği kritik bir kayıtta kullanıcıya karar bağlamı sunar; her ekrana aynı uyarıyı eklemek ise dikkat dağıtır.
Kaydedildi ile gönderildi aynı durum değildir
Bir ziyaret formunu dolduran kişinin bağlantı kesilince aynı bilgiyi yeniden girmemesi gerekir. Bunun için ürün tasarımında en az üç durumu ayırmak faydalıdır: cihazda kayıtlı, gönderim bekliyor ve sunucuda tamamlandı. İş kuralı nedeniyle reddedilen bir kayıt da bu durumların arasına gizlenmemelidir.
Gönderim kuyruğu için önerilen tasarım; işlemin kimliğini, ilgili kayıt sürümünü, deneme bilgisini ve sonucunu izlenebilir tutmaktır. Kullanıcının ‘Kaydet’ düğmesine basmasıyla ekranda başarı göstermek yerine, gerçekleşen durumu açıkça adlandırın. Bekleyen kayıtlar için anlaşılır bir liste ve düzeltme yolu, destek ekibinin de işini kolaylaştırır.
Yeniden denemeler aynı işlemi çoğaltmamalı
İstek sunucuya ulaşmış, ancak yanıt telefona dönememiş olabilir. Bu durumda yeniden gönderim güvenliği ayrıca tasarlanmalıdır. HTTP’de idempotent yöntemler, aynı isteğin tekrarlanmasının amaçlanan sunucu etkisini değiştirmemesi üzerinden tanımlanır; sıradan bir POST isteği kendiliğinden bu güvenceyi vermez.
Ziyaret kaydı örneğinde, istemcinin oluşturduğu işlem kimliğiyle sunucunun aynı işi ikinci kez oluşturmamasını sağlayan bir sözleşme kurulabilir. Anahtarın kapsamı, saklama süresi ve aynı anahtarla farklı içerik gelirse verilecek yanıt baştan tanımlanmalıdır. Bu, her veri türüne aynen uygulanacak hazır bir reçete değil, API ile mobil istemcinin birlikte vereceği bir karardır.
Çakışmayı verinin anlamına göre çözün
İki kullanıcı aynı kaydı değiştirdiğinde ‘son yazan kazanır’ kuralı her iş için uygun olmayabilir. Ziyaret notuna eklenen yeni bir gözlem ayrı bir kayıt olarak korunabilirken, görev ataması gibi tek değerli bir karar daha açık bir sahiplik kuralı gerektirebilir.
Ürün ekibi için yararlı soru şudur: hangi alanlar birlikte korunabilir, hangileri yeniden onaylanmalıdır? Kritik bir değişiklikte kullanıcıya iki sürümü karşılaştırma imkânı sunmak, sessizce veri ezmekten daha anlaşılır olabilir. Bu senaryoyu yalnızca teknik ekibe bırakmak yerine operasyon sorumlularıyla örnek kayıtlar üzerinden çalışın.
Arka plan senkronizasyonu anlık çalışma garantisi değildir
Mobil işletim sistemleri arka plan işlerini kaynak ve sistem koşullarına göre planlar. Android’de WorkManager gibi araçlar kalıcı işler, çalışma koşulları ve yeniden deneme politikaları için kullanılabilir; ancak ‘bağlantı gelir gelmez kesin şu saniyede gönderilir’ şeklinde bir ürün vaadi doğru değildir.
Bu yüzden kullanıcı uygulamaya döndüğünde güncel durumu görebilmeli ve uygun işlemleri yeniden deneyebilmelidir. Batarya tüketimi, büyük dosya aktarımı ve bekleyen iş sayısını pilot kullanımda birlikte değerlendirin. Teknik olarak çalışan bir senkronizasyonun günlük kullanımda anlaşılır ve yönetilebilir olması da gerekir.
Pilot için somut bir test listesi hazırlayın
İlk sürümde tek bir akışı uçtan uca sınamak iyi bir başlangıçtır: görevi açın, bağlantıyı kesin, not ekleyin, uygulamayı kapatıp açın ve bağlantıyı geri getirin. Ardından aynı işlemi yeniden gönderme, sunucudan reddedilme ve başka kullanıcı tarafından değiştirilen kayıt senaryolarını deneyin. Beklenen ekran durumu ile sunucudaki kayıt sayısını birlikte kontrol edin.
Kabul ölçütlerini de iş dilinde yazın: kullanıcı kaydının durumunu anlayabiliyor mu, bekleyen işi bulabiliyor mu, aynı ziyaret iki kez oluşuyor mu? Yerel verinin hesap değişiminde nasıl ayrılacağı ve erişimin sonlanması halinde hangi işlemlerin duracağı da kapsamda olmalıdır. Offline-first yaklaşımın değeri, bağlantı sorununu gizlemekten çok ürünün bu koşullarda öngörülebilir davranmasını sağlamaktır.
