Çevrimdışı öncelikli uygulama nedir?
Çevrimdışı öncelikli uygulama, veriyi önce cihazdaki veritabanından okuyup oraya yazan ve ağı, bağlantı olduğunda eşitlendiği bir kaynak olarak gören uygulamadır. Android'in çevrimdışı öncelikli uygulama rehberi bunu, temel işlevlerinin tamamını ya da kritik bir bölümünü internet erişimi olmadan yerine getirebilen uygulama olarak tanımlar. Bu tasarımda ekranların gösterdiği her şeyin asıl doğruluk kaynağı yerel veridir; kullanıcı arayüzü ağla hiçbir zaman doğrudan konuşmaz, sunucudan veri çekip yerel depoyu güncelleyen ayrı bir veri katmanı (repository) vardır. En alt çıta, okumaların bağlantı olmadan çalışmasıdır.
Bu, birkaç ekranı önbelleğe almaktan farklı bir iştir. Önbellekteki ekran dünün verisini gösterir ve kullanıcı bir şeyi değiştirmeye çalıştığı anda hata verir. Çevrimdışı öncelikli uygulama ise bodrumdaki teknisyenin, çelik raflar arasındaki depo çalışanının ya da kırsal sahadaki denetçinin işini bitirmesine izin verir ve hangi bilginin sunucuya ulaştığını dürüstçe gösterir. Asıl tasarım işi yerel veritabanı değildir: Hangi eylemlerin çevrimdışı yapılabileceğine, kuyruktaki değişikliklerin sunucuya nasıl tam bir kez ulaşacağına ve iki kişi aynı kaydı değiştirdiğinde ne olacağına karar vermektir.
Hangi işlemler çevrimdışı çalışmalı?
Kararı işlem işlem verin; çünkü bazı yazma işlemleri sunucu olmadan hiç yapılmamalıdır. Android rehberi üç yazma stratejisi tarif eder: banka havalesi gibi zamana duyarlı işlemler için yalnızca çevrimiçi yazma, analitik gibi kritik olmayan veriler için kuyruğa alınan yazma ve uygulamanın önce yerele yazıp değişikliği ilk fırsatta sunucuya bildirdiği "tembel yazma" (lazy write). Uygulamayı çevrimdışı öncelikli yapan tembel yazmadır; çatışma çözümü gerektiren de odur. Bir saha servisi uygulaması için kapsam tablosu şöyle olabilir:
| İşlem | Çevrimdışı davranış | Gerekçe |
|---|---|---|
| Günün işlerini, adresleri, ekipman geçmişini görmek | Yerel veritabanından okunur, son eşitleme zamanı gösterilir | Çalışan sinyal olmadan işe başlayabilmeli |
| Not, fotoğraf, kullanılan parça ve müşteri imzası kaydetmek | Tembel yazma: yerele kaydedilir, eşitleme kuyruğuna alınır | İşin kendisi budur; asıl risk bu bilginin kaybolmasıdır |
| Kullanım analitiği ve tanılama kayıtları | Kuyruğa alınır; toplu gönderilebilir, eskiyince atılabilir | Yararlıdır ama kritik değildir |
| Ödeme almak, ortak havuzdan stok ayırmak | Yalnızca çevrimiçi; açık bir mesajla devre dışı bırakılır | İki cihaz aynı ürünü vaat edebilir ya da iki kez ücret alabilir |
| Yeni bir cihazda ilk oturum açma | Yalnızca çevrimiçi | Kimlik ve yetkiler sunucuda doğrulanmalı |
Her çevrimdışı işlem için cihazda hangi verinin, ne kadar süre kalabileceğini ve kullanıcı çıkış yaptığında ya da yetkisi kaldırıldığında ne olacağını da yazın.
Çevrimdışı yazmalar nasıl kuyruğa alınıp eşitlenmeli?
Her değişikliği, kalıcı bir işlem kuyruğundaki kaydıyla birlikte aynı yerel veritabanı işleminde saklayın ve bağlantı geldiğinde kuyruğu sırayla gönderin. Her kuyruk kaydında şunlar bulunmalı:
- Cihazda üretilen işlem kimliği: Sunucu yeniden denemeyi tanısın ve işlemi yalnızca bir kez uygulasın diye.
- Kayıt kimliği: Yeni kayıtlar için bu da cihazda üretilir; uygulama, kullanıcının az önce oluşturduğu bir şeye sunucunun ad vermesini beklemez.
- Temel sürüm: Kullanıcının düzenlediği kaydın sürümü; sunucu, arada başka birinin kaydı değiştirdiğini buradan anlar.
- İçerik ve oluşturma zamanı: Varsa bağımlılıkla birlikte; ait olduğu ziyaret sunucuda oluşmadan bir fotoğraf yüklenemez.
Gönderim, uygulamanın kapanmasından ya da telefonun yeniden başlamasından etkilenmemelidir. Android'de WorkManager tam olarak bunun için vardır: Zamanlanan işleri kendi iç veritabanında saklar ve cihaz yeniden başladığında yeniden planlar; ağ bağlantısı gibi bir koşulu bekleyebilir ve başarısız işi üstel artan beklemeyle yeniden dener. Hangi platformda olursanız olun, yalnızca arka plan zamanlamasına güvenmeyin; uygulama ön plana döndüğünde de eşitleme başlatın.
Ters yön de aynı ölçüde önemlidir. Android rehberi, uygulamanın veriyi ihtiyaç duydukça çektiği çekme tabanlı eşitlemeyi, cihazın ihtiyaç duyduğu verinin bir kopyasını tuttuğu ve sunucunun neyin değiştiğini bildirdiği itme tabanlı eşitlemeyle karşılaştırır. İtme tabanlı eşitleme uygulamanın uzun süre çevrimdışı kalmasına izin verir ama sürümleme gerektirir. Hangisini seçerseniz seçin, silmeleri açıkça bildirin: Sunucu iptal edilen bir işi yalnızca listeden çıkarırsa, çevrimdışı kalmış cihaz onu göstermeye devam eder. Değişiklik akışında silme işaretleri (tombstone) döndürün.
Cihazlar arasındaki çatışmalar nasıl çözülür?
Çatışmayı kayıt sürümleriyle tespit edin, ardından her alanı taşıdığı anlama göre çözün. "Son yazan kazanır" en basit kuraldır; Android rehberi bunu cihazların eklediği zaman damgalarıyla anlatır: Sunucu, elindeki durumdan eski veriyi atar. Bir yer imi için kabul edilebilir. İş kayıtları için tehlikelidir; çünkü cihaz saatleri kayar ve bu kural bir kişinin emeğini sessizce siler.
AWS AppSync'in çatışma çözümü belgesi başlıca alternatifleri somut olarak gösterir. İyimser eşzamanlılıkta sunucu, sürümü güncel sürümden farklı olan yazmayı reddeder ve en son kaydı döndürür; istemci birleştirip yeniden dener. Automerge'de çatışan tekil (skaler) alan sunucudaki değeri korur, çatışan listeye gelen değerler eklenir ve tekrarlar korunur, kümelerde iki tarafın birleşimi alınır, yeni alanlar kayda eklenir. Özel bir işleyici ise kendi kurallarınıza göre kaydı çözebilir, reddedebilir ya da silebilir. AppSync kullanmasanız bile bu kurallar işe yarar bir dil sağlar; çünkü her alan türü için bir karar vermeye zorlar.
Bu kararı bir politika tablosu olarak yazın. Varsayımsal bir servis ziyareti kaydı için şu kurallar kullanılabilir:
| Alan | Çatışmada uygulanacak kural |
|---|---|
| Teknisyen notları | İkisi de eklenir; notlar bir listedir, hiçbiri kaybolmaz |
| Kullanılan parçalar | İki küme birleştirilir, miktarlar incelemeye işaretlenir |
| Randevu zamanı | Sunucu kazanır; takvimin sahibi sevk ekibidir, teknisyene bildirilir |
| Müşteri imzası ve fotoğraflar | Asla üzerine yazılmaz; gönderilen her öğe kanıt olarak saklanır |
| Ziyaret durumu | "Tamamlandı" ile "ertelendi" çatışırsa karar bir kişiye bırakılır |
| Onaylanmış fatura tutarı | Tutar onaylandıktan sonra çevrimdışı düzenleme reddedilir |
İki sürümü ve verilen kararı bir denetim kaydında tutun. Çatışma bir kişinin kararını gerektiriyorsa kullanıcıya hangi alanların eşitlendiğini, hangilerinin karar beklediğini gösterin.
Varsayımsal örnek: bodrumda kaydedilen ziyaret
Bir teknisyen 09.10'da eşitleme yapar ve 10.30'da sinyal olmayan bir kazan dairesine iner. 10.40'ta sevk görevlisi ziyareti ertesi güne alır; sunucudaki sürüm 7'den 8'e çıkar. 10.55'te hâlâ 7. sürümle çalışan teknisyen değiştirdiği vanayı kaydeder, bir not ekler, müşterinin imzasını alır ve ziyareti tamamlandı olarak işaretler. Uygulama her değişikliği "bu cihaza kaydedildi, eşitleme bekliyor" olarak gösterir.
11.20'de telefon yeniden bağlanır ve kuyruk dört işlemi sırayla gönderir. Sunucu, 7. sürüme dayanan değişikliklerin güncel 8. sürümle çatıştığını görür ve politikayı uygular: Not eklenir, vana kullanılan parçalara girer, imza kanıt olarak saklanır, randevu zamanı sevk ekibinin belirlediği gibi kalır ve "tamamlandı" ile "ertelendi" arasındaki durum çatışması işaretlenir. Teknisyen ziyaretin sevk görevlisinin kararını beklediğini söyleyen bir uyarı görür; sevk görevlisi iki sürümü yan yana inceler. Stok ve faturalama ancak durum netleştikten sonra sunucuda hesaplanır. Teknisyenin girdiği hiçbir bilgi kaybolmaz ve hiçbir şeyin üzerine sessizce yazılmaz.
Cihazdaki çevrimdışı veri nasıl korunur?
Yalnızca çevrimdışı işin gerektirdiği veriyi saklayın, onu durağan hâlde koruyun ve nasıl silineceğini planlayın. OWASP'ın mobil uygulama güvenliği standardı, uygulamaların kişisel veri, kriptografik materyal, gizli anahtar ve API anahtarı gibi bilgileri sıklıkla cihazda sakladığını ve bu verinin yedekleme ya da kayıt dosyaları gibi sistem özellikleri üzerinden istemeden de sızabileceğini belirtir; depolama bölümündeki ilk kontrol de uygulamanın hassas veriyi güvenli saklamasıdır. Pratikte bütün müşteri tabanını değil bugünün ve yarının işlerini eşitleyin, yerel veritabanını şifreleyin, anahtarları düz dosyalarda tutmayın, verinin cihaz yedeklerine girip girmeyeceğine karar verin ve kişisel veriyi kayıt dosyalarına yazmayın. Belirli bir çevrimdışı süreden sonra kullanıcının yeniden oturum açmasını isteyin; hesap yetkisi kaldırıldığında yerel veriyi silin. Kuyrukta değişiklik varken oturum anahtarının süresi dolarsa kuyruğu koruyun, kullanıcıdan yeniden giriş yapmasını isteyin ve sonra devam edin; eşitlenmemiş işi çıkış sırasında uyarmadan asla silmeyin.
Web uygulamaları da çevrimdışı öncelikli olabilir mi?
Evet; veri kuralları aynıdır, altyapı farklıdır. Jake Archibald'ın çevrimdışı tarif kitabı service worker stratejilerini anlatır: Uygulama iskeletini önbellekten sunun, biraz eski olabilecek içerik için "eskiyi göster, arkada yenile" (stale-while-revalidate) yaklaşımını kullanın ve "önce ağ, olmazsa önbellek" stratejisinde dikkatli olun; çünkü yavaş ya da kesik kesik bağlantıda kullanıcı, cihazda zaten bulunan içeriği görmek için ağın başarısız olmasını bekler. Arka plan eşitlemesi, acil olmayan güncellemeleri bağlantı geri geldiğinde gönderebilir. Yanıt önbelleği, kullanıcının düzenlediği kayıtların yeri değildir; bu kayıtlar yerel bir veritabanında, mobil uygulamadakiyle aynı işlem kuyruğu, sürümler ve çatışma kurallarıyla tutulmalıdır. Arka plan özelliklerinin kullanıcılarınızın gerçekten kullandığı tarayıcılarda desteklenip desteklenmediğini kontrol edin ve yedek olarak sayfa her açık olduğunda eşitleme yapın.
Çevrimdışı öncelikli uygulama nasıl test edilir?
Yalnızca "çevrimiçi" ve "çevrimdışı" durumlarını değil, aralarındaki geçişleri test edin:
- Uygulamayı yeni kurulumdan sonra ve olağan bir günlük eşitlemeden sonra ağ olmadan açın.
- Fotoğraf yüklemesinin ortasında bağlantıyı kesin, sonra geri getirin.
- Oturum anahtarının süresi dolana kadar birkaç gün çevrimdışı kalın.
- Cihaz saatini bir saat ve bir gün yanlış ayarlayın.
- İki cihaz da çevrimdışıyken aynı kaydı iki cihazda ve arka ofiste düzenleyin.
- Eşitleme sırasında uygulamayı kapatın; kuyruk doluyken telefonu yeniden başlatın.
- Kuyrukta işlem varken yerel veritabanı şemasını değiştiren bir uygulama güncellemesi yükleyin.
- Asansörde ve trende olduğu gibi bağlantıyı art arda açıp kapatın.
En eski bekleyen işlemin yaşını, eşitleme başarı oranını, her yüz işlemdeki çatışma sayısını, sunucunun reddettiği tekrarları ve yeniden bağlandıktan sonra tamamen toparlanma süresini ölçün. Kaybolan kullanıcı girişi için hedef sıfırdır; her kayıp bir olay olarak ele alınmalıdır.
Sık yapılan hatalar
- Değişiklik yalnızca tek bir cihazdayken "kaydedildi" göstermek.
- Bütün çatışmaları cihaz saatine göre çözmek.
- Kimlikleri yalnızca sunucuya ürettirmek; böylece çevrimdışı oluşturulan kayıtlara başvurulamaması.
- Çıkışta ya da oturum süresi dolduğunda kuyruğu temizlemek.
- Yerel veritabanı için geçiş (migration) planı olmadan yayına çıkmak.
Nereden başlamalı?
Kullanıcıların sinyal olmadan bitirmek zorunda olduğu tek bir iş akışıyla başlayın, onun için işlem tablosunu ve çatışma politikasını doldurun; eşitleme kütüphanesini ya da servisini ancak ondan sonra seçin. Çevrimdışı çalışma, mobil uygulama geliştirme hizmetimizin kapsamında yer alır; aynı sayfadan ücretsiz keşif görüşmesi de planlayabilirsiniz.