Mobil Uygulamada Çevrimdışı Mod Nasıl Tasarlanır? İnternet Yokken Çalışan Uygulama

Bu rehberde Talha Aslan ve ekibi olarak çevrimdışı mod kararını adım adım ele alıyoruz. Amacımız genel bir mobil geliştirme anlatısı değil; yalnızca tek bir soruya cevap vermek: internet kesildiğinde uygulamanız ne yapmalı? Bu yüzden her bölümde bir kontrol listesi, bir karar ya da numaralı adım bulacaksınız. Kod örneği vermiyoruz; mimari kararları ürün sahibi, tasarımcı ve geliştirici aynı masada konuşabilsin diye kavram düzeyinde anlatıyoruz.

İnternet yokken çalışan uygulama hangi işlerde şarttır?

Her uygulamanın çevrimdışı çalışması gerekmez. Öte yandan bazı iş modellerinde bağlantı kopması doğrudan iş kaybı demektir. Özellikle şu durumlarda çevrimdışı mod bir lüks değil, ürünün kendisidir:

• Saha ekipleri: servis teknisyeni, satış temsilcisi, sayaç okuyucu, denetçi gibi bodrum, şantiye ya da kırsal bölgede çalışan kişiler.
• Depo ve stok işlemleri: raf arası sinyalin zayıf olduğu alanlarda barkod okutma, sayım ve sevk onayı.
• Lojistik ve teslimat: teslim imzası, fotoğraf ve not alma gibi işlemler yolda kesintiye uğrayabilir.
• Eğitim ve içerik uygulamaları: uçakta, metroda ya da kotası azalan kullanıcının içeriğe ulaşması.
• Form ve kayıt toplama: etkinlik girişleri, anket, saha gözlem formları.

Buna karşılık banka havalesi, anlık ödeme ya da canlı stok rezervasyonu gibi işlemler gerçek zamanlı sunucu onayı ister. Yani çevrimdışı mod bir evet hayır sorusu değil, işlem bazında verilen bir karardır. Hangi işlemin çevrimdışı yapılabileceğini netleştirmek, projenin geri kalanındaki tüm tartışmaları kısaltır.

Offline first ile "internet gelince çalışır" yaklaşımı arasındaki fark ne?

Pek çok ekip uygulamayı aslında çevrimiçi kurgular; bağlantı yoksa bir hata ekranı gösterir. Offline first yaklaşımında ise bakış tersine döner. Android geliştirici belgelerindeki offline first uygulama rehberi, bu tür bir uygulamanın temel işlevlerinin tamamını ya da kritik bir bölümünü internet olmadan yerine getirebilmesini tanım olarak koyar. Ayrıca kullanıcının ilk ağ çağrısını beklemeden yerel veriyi hemen görmesini önerir.

Farkı pratikte şöyle düşünebilirsiniz. Çevrimiçi öncelikli bir uygulamada kullanıcı ekranı açar, sunucuya istek gider, cevap gelince liste dolar. Offline first bir uygulamada ise ekran cihazdaki veritabanından anında dolar, uygulama arka planda ağdan güncel veriyi ister ve gelen veriyi önce yerel veritabanına yazar. Böylece ekran her zaman tek bir kaynaktan okur. Kısacası kullanıcı beklemez; uygulama veriyi sessizce tazeler. Bu yaklaşımın maliyeti, senkronizasyon ve çakışma kurallarını baştan düşünmek zorunda olmanızdır.

Çevrimdışı mod için hangi verileri cihazda saklamalısınız?

Her şeyi cihaza indirmek hem depolama hem pil hem de veri güvenliği açısından yanlıştır. Bu nedenle önce veri envanteri çıkarın. Aşağıdaki kontrol listesi bu envanteri hızlandırır:

1. Kullanıcının günlük işini yapmak için mutlaka görmesi gereken kayıtlar hangileri? Örneğin o günün iş emirleri.
2. Referans veriler hangileri? Ürün kataloğu, fiyat listesi, müşteri adresi gibi az değişen tablolar.
3. Kullanıcının çevrimdışıyken üreteceği veriler hangileri? Form, fotoğraf, imza, not.
4. Hassas veri var mı? Kişisel veri varsa cihazda şifreli saklama ve oturum kapanınca silme kuralı gerekir.
5. Ne kadar geçmiş yeterli? Son otuz günlük kayıt mı, yoksa yalnızca açık işler mi?

Bu listeyi doldurduğunuzda çoğu projede verinin üç gruba ayrıldığını görürsünüz: mutlaka yerelde olacaklar, isteğe bağlı önbelleğe alınacaklar ve yalnızca çevrimiçi kalacaklar. Üstelik bu ayrım, uygulamanın ilk kurulumda ne kadar veri indireceğini de belirler. Sunucu tarafında önbellek kavramına daha genel bakmak isterseniz yazılımda önbellekleme yazımız konunun arka uç tarafını anlatıyor.

Yerel önbellek ile yerel veritabanı arasında nasıl seçim yaparsınız?

"Önbellek" kelimesi çoğu zaman iki farklı şeyi anlatır. Birincisi geçici önbellektir: bir ekranı hızlı açmak için son cevabı saklarsınız, silinirse sorun olmaz. İkincisi kalıcı yerel veritabanıdır: kullanıcının çevrimdışı ürettiği veri burada durur ve kaybolması kabul edilemez. Dolayısıyla ilk soru şudur: bu veri kaybolursa ne olur?

Android belgeleri yerel veri kaynağının uygulamanın asıl doğruluk kaynağı olmasını ve üst katmanların veriyi yalnızca buradan okumasını önerir. Satır ve sütun düzenindeki veri için ilişkisel veritabanı, basit ayarlar için anahtar değer deposu, büyük medya için dosya sistemi tipik seçimlerdir. iOS tarafında da benzer biçimde kalıcı depolama çözümleri bulunur; hangisini seçtiğiniz, ekibinizin yığınına bağlıdır. Burada önemli olan teknoloji adı değil, kuraldır: kullanıcının girdiği veriyi her zaman önce kalıcı depoya yazmalısınız, ağ ikinci adımdır.

Çevrimdışı mod için yazma stratejisini nasıl seçersiniz?

Android rehberi çevrimdışı yazma işlemleri için üç strateji tarif eder. Her işlem için bunlardan birini seçmeniz gerekir; tek bir strateji bütün uygulamaya uymaz. Aşağıdaki karar tablosu seçimi kolaylaştırır:

Saha ve depo uygulamalarının büyük kısmı üçüncü stratejiyi kullanır, çünkü kullanıcının girdiği hiçbir verinin kaybolmaması gerekir. Ancak bu strateji çakışma riskini de beraberinde getirir; bu yüzden aşağıdaki çakışma bölümünü atlamayın.

Bağlantı geri geldiğinde senkronizasyon nasıl çalışmalı?

Senkronizasyon, yerel veri ile sunucudaki veriyi uzlaştırma işidir. Android belgeleri iki ana yaklaşım tarif eder: çekme tabanlı ve itme tabanlı senkronizasyon. Çekme tabanlı yaklaşımda uygulama, bir ekranı göstermeden hemen önce o ekranın verisini ister. Uygulaması kolaydır; ancak uzun kesintilerde kullanıcı hiç ziyaret etmediği bir ekrana girerse boş ya da eski veriyle karşılaşır.

İtme tabanlı yaklaşımda ise uygulama ilk açılışta yeterli veriyi indirir, sonra sunucu bir veri değiştiğinde cihaza haber verir ve uygulama yalnızca değişen kaydı çeker. Bu yaklaşım uzun süre çevrimdışı kalabilen uygulamalara uyar, fakat sunucunun senkronizasyonu desteklemesini ve verinin sürümlenmesini gerektirir. Pek çok ekip ikisini karıştırır: sık değişen akışlar için çekme, kullanıcı profili ve iş emri gibi kritik veriler için itme. Örneğin saha uygulamasında sabah iş emirleri itme ile gelir, ürün kataloğunu ise uygulama ekran açıldıkça çeker.

Bağlantıyı yeniden kurma sırasında başarısız istekleri hemen tekrar tekrar göndermek pili ve sunucuyu yorar. Bu nedenle belgeler, denemeler arasındaki süreyi giderek artıran üstel geri çekilme yöntemini önerir. Yetkisiz bir isteği ise oturum yenilenmeden tekrar denememek gerekir.

Senkronizasyon çakışması nedir ve nasıl çözersiniz?

Çakışma, aynı kaydın iki farklı yerde, birbirinden habersiz değiştirilmesidir. Örnek senaryo: depo sorumlusu tablette bir ürünün sayımını 40 olarak girer, aynı sırada merkezdeki kullanıcı aynı kaydı 38 olarak düzeltir. Tablet çevrimiçi olduğunda hangisi geçerli olacak? Bu soruyu proje başında cevaplamazsanız, cevabı rastgele bir kod satırı verir.

Android belgeleri mobil uygulamalarda yaygın yaklaşım olarak "son yazan kazanır" kuralını anlatır: cihaz her yazma işlemine zaman bilgisi ekler, sunucu daha yeni olanı kabul eder. Basittir; ancak her veri tipi için doğru değildir. Bu yüzden veri tipine göre şu seçenekleri değerlendirin:

• Son yazan kazanır: kullanıcı ayarları, durum alanları gibi tek kişinin değiştirdiği veriler.
• Alan bazında birleştirme: bir kişi telefon numarasını, diğeri adresi değiştirdiyse ikisini birden korumak.
• Toplamsal kayıt: stok hareketini "son değer" değil "giriş çıkış hareketi" olarak saklamak; böylece iki hareket de kaybolmaz.
• Kullanıcıya sorma: hukuki ya da finansal etkisi olan kayıtlarda iki sürümü gösterip seçim istemek.
• Sunucu kuralı: kapanmış bir iş emrine çevrimdışı yapılan ekleme gibi durumlarda sunucunun reddetmesi ve nedenini bildirmesi.

Çakışmayı önlemek için veri modelini nasıl kurmalısınız?

Çakışmayı çözmek, onu baştan azaltmaktan daha pahalıdır. Bu nedenle veri modelini çevrimdışı senaryoya göre kurun. İlk olarak her kayda cihazda üretilen benzersiz bir kimlik verin; sunucunun kimlik atamasını beklemek, çevrimdışı oluşturulan kayıtları birbirine bağlamayı zorlaştırır. İkinci olarak her kayda bir sürüm ya da son değişiklik zamanı ekleyin. Üçüncü olarak silme işlemini kaydı fiziksel olarak silmek yerine "silindi" işaretiyle yapın; aksi halde diğer cihazlar silmeyi hiç öğrenemez.

Bir de aynı isteğin iki kez gitmesi sorunu vardır. Bağlantı tam yanıt anında koparsa cihaz isteğin ulaşıp ulaşmadığını bilemez ve tekrar gönderir. Sunucu aynı işlemi iki kez kaydederse çift teslim ya da çift stok çıkışı oluşur. Bunu önlemenin yolu, her işleme bir işlem anahtarı eklemek ve sunucunun aynı anahtarı ikinci kez işlememesidir. Bu kavramı idempotency yazımızda ayrıntılı anlattık; çevrimdışı senkronizasyonda neredeyse zorunlu bir kuraldır. Uygulamanın konuştuğu arayüzün temellerini merak ediyorsanız API nedir yazımız iyi bir başlangıç noktası.

Çevrimdışı mod projesine başlamadan hangi soruları cevaplamalısınız?

Buraya kadar okuduysanız çevrimdışı modun bir ekran özelliği değil, uygulamanın veri mimarisi olduğunu fark etmişsinizdir. Pratikte ekiplerin en çok zorlandığı nokta, bu kararları sonradan, uygulama yayına çıktıktan sonra eklemeye çalışmaktır. Çevrimiçi kurgulu bir uygulamaya çevrimdışı mod eklemek çoğu zaman veri katmanını yeniden yazmak anlamına gelir. Bu yüzden başlamadan önce şu soruları yazılı olarak cevaplayın: hangi işlemler çevrimdışı yapılacak, kullanıcı en uzun ne kadar çevrimdışı kalabilir, hangi veriler cihazda tutulacak, çakışmada kim kazanacak?

Bu soruların cevabını iş süreciniz belirler, teknoloji değil. Kendi ekibinizde bu kararları verecek mobil mimari deneyimi yoksa mobil uygulama geliştirme sürecinde ilk iş olarak bu çerçeveyi birlikte çıkarıyoruz; böylece ilk sürümde veri katmanını doğru kurarız ve sonradan yeniden yazma ihtiyacı azalır. Çapraz platform bir yığın düşünüyorsanız React Native yazımız tek kod tabanının artı ve eksilerini anlatıyor.

Kullanıcıya bağlantı ve senkronizasyon durumunu nasıl gösterirsiniz?

Çevrimdışı modun en çok ihmal edilen tarafı arayüzdür. Kullanıcı verisinin gönderilip gönderilmediğini bilmezse ya işi iki kez yapar ya da uygulamaya güvenmez. Dolayısıyla her kayıt için net bir durum dili kurun. Önerdiğimiz temel durum seti şöyledir:

1. Cihazda kaydedildi: veri kalıcı depoda, henüz sunucuya gitmedi.
2. Yolda: senkronizasyon devam ediyor.
3. Tamam: sunucu kaydı onayladı.
4. Gönderilemedi: kullanıcının bir şey yapması gerekiyor; nedeni ve çözüm yolu yazıyor.

Ayrıca ekranın üst kısmında genel bir bağlantı göstergesi kullanın, ama bunu kalıcı bir hata kutusuna çevirmeyin. Kullanıcı çevrimdışıyken de çalışabiliyorsa mesaj sakin olmalı: "Çevrimdışısınız, kayıtlarınızı cihazda tutuyoruz." Son olarak "en son güncelleme" bilgisini gösterin; özellikle fiyat ya da stok gibi eskiyebilen verilerde kullanıcı verinin ne kadar taze olduğunu bilmelidir. Durum mesajlarını kısa bildirimlerle vermek istiyorsanız arayüz tarafındaki genel ilkeler için kullanıcı odaklı arayüz tasarımı yazımıza göz atabilirsiniz.

Çevrimdışıyken hangi düğmeler pasif olmalı?

Kural basit: çevrimdışı yapılamayan bir işlemin düğmesini gizlemeyin, ama pasif yapın ve nedenini söyleyin. Gizlemek kullanıcıyı şaşırtır; çünkü düğmeyi dün gördüğü yerde bugün bulamaz. Pasif bir düğmenin yanına kısa bir açıklama koymak hem net hem de erişilebilir bir çözümdür. Ekran okuyucu kullanan kişiler için bu açıklamanın da okunabilir olması gerekir; bu konuyu kardeş yazımız mobil uygulama erişilebilirliği ve VoiceOver, TalkBack testi rehberinde ele alıyoruz.

Örneğin bir saha uygulamasında "iş emrini kapat" işlemi çevrimdışı yapılabilir, fakat "müşteriye fatura gönder" işlemi sunucu ister. Bu durumda ikinci düğme pasif kalır ve "Fatura göndermek için bağlantı gerekiyor; iş emri kapanışı cihazda kaydedildi" gibi bir açıklama gösterir. Böylece kullanıcı hem ne yapabileceğini hem de neyi beklemesi gerektiğini bilir.

Fotoğraf, imza ve büyük dosyaları çevrimdışı nasıl yönetirsiniz?

Saha uygulamalarında asıl yük metin değil medyadır. Bir teslimat fotoğrafı ya da hasar görseli, metin kayıtlarından çok daha büyüktür. Bu yüzden medya için ayrı bir kuyruk kurun. Önce kaydın metin kısmını gönderin, ardından dosyaları ayrı ayrı yükleyin. Böylece zayıf bağlantıda iş kaydı en azından sunucuya ulaşır.

Ayrıca şu kontrol listesini uygulayın: dosyayı cihazda sıkıştırın, yükleme yarıda kalırsa kaldığı yerden devam edebilen bir yöntem seçin, yüklenen dosyayı sunucu onayı gelmeden cihazdan silmeyin, depolama dolarsa kullanıcıyı önceden uyarın. Android belgeleri yönetilen bulut çözümlerinin de kesintide duraklayıp devam eden yükleme sunduğunu belirtir; hazır bir çözüm seçmek ile kendi yığınınızı kurmak arasındaki tercih, kontrol ihtiyacınıza bağlıdır.

Arka planda senkronizasyon pil ve veri kotasını nasıl etkiler?

Çevrimdışı mod tasarlarken unutulan bir başka konu, arka plan işlerinin cihaz kaynaklarını tüketmesidir. Android rehberi, veriyi pil ve veri durumunu gözeterek çekmeyi, örneğin şarjdayken ya da Wi-Fi bağlıyken ağır işleri yapmayı önerir. Android tarafında bu tür kalıcı arka plan işleri için WorkManager belgeleri ağ koşulu, yeniden deneme ve tekrar zamanlama gibi kuralları anlatır.

iOS tarafında da arka plan çalışması sistemin izin verdiği sınırlar içinde gerçekleşir ve uygulamanın her istediği anda çalışacağı garanti değildir. Dolayısıyla tasarım şunu varsaymalı: senkronizasyon her zaman uygulama açıldığında da tetiklenebilmeli. Kullanıcının elle "şimdi gönder" diyebileceği bir seçeneği de eklemelisiniz. Kısacası arka plan senkronizasyonu bir kolaylıktır, tek güvence değildir.

iOS ve Android arasında çevrimdışı mod açısından fark var mı?

Mimari ilkeler iki platformda da aynıdır: yerel veri tek doğru kaynak olur, yazmalar kuyruğa girer, senkronizasyon bağlantı gelince başlar. Ancak arka plan çalışmasının kuralları platformdan platforma değişir. Android tarafında ağ koşuluna bağlı kalıcı işler için resmi bir kütüphane bulunur ve sistem bu işleri uygulama kapalıyken de planlayabilir. iOS tarafında ise sistem arka plan süresini daha sıkı yönetir; uygulamanızın tam istediğiniz anda uyanacağını varsaymamalısınız.

Bu fark tasarımı doğrudan etkiler. Örneğin iPhone kullanan bir saha çalışanı için uygulama her açıldığında kuyruğu kontrol etmeli ve bekleyen kayıtları hemen göndermeye çalışmalıdır. Ayrıca iki platformda da kullanıcı pil tasarrufu modunu açtığında arka plan işleri gecikebilir. Dolayısıyla kullanıcıya "en son gönderim" bilgisini göstermek, platform farkını kullanıcı açısından görünmez kılar. Çapraz platform bir çatı kullansanız bile bu davranış farklarını her iki cihazda ayrı ayrı test etmeniz gerekir. Kısacası kod tabanı ortak olabilir; test planı ortak olamaz.

Çevrimdışı modu nasıl test edersiniz?

Çevrimdışı modu yalnızca uçak modunu açıp kapatarak test etmek yetmez. Gerçek hayattaki kesintiler daha karmaşıktır: bağlantı var ama çok yavaştır, istek gider ama cevap gelmez, cihaz kayıt ortasında kapanır. Bu nedenle test planınıza şu senaryoları ekleyin:

1. Uygulamayı tamamen çevrimdışı açın ve temel iş akışını baştan sona tamamlayın.
2. Kayıt sırasında bağlantıyı kesin, sonra geri açın; kaydın tek kez gittiğini doğrulayın.
3. İki cihazda aynı kaydı çevrimdışı değiştirin ve çakışma kuralının beklediğiniz gibi çalıştığını kontrol edin.
4. Uygulamayı senkronizasyon ortasında zorla kapatın; yeniden açınca kuyruğun kaldığı yerden devam ettiğini görün.
5. Oturum süresi dolmuşken bağlantı gelsin; uygulamanın veriyi kaybetmeden yeniden giriş istediğini doğrulayın.
6. Depolama alanı azken medya kaydetmeyi deneyin.
7. Uygulama güncellemesinden sonra bekleyen kuyruğun silinmediğini kontrol edin.

Son madde özellikle önemlidir. Yeni sürümde veritabanı yapısı değişirse eski sürümde bekleyen kayıtlar yeni yapıya taşınmalıdır; aksi halde güncelleme kullanıcının çevrimdışı verisini silebilir. Ayrıca test sırasında gerçek cihaz kullanın; emülatördeki ağ kesintisi, asansör ya da bodrum gibi gerçek ortamlarda yaşanan yavaş ve kararsız bağlantıyı tam olarak yansıtmaz. Bu yüzden ekibinizden birinin uygulamayı bir gün boyunca gerçek iş akışında kullanması, otomatik testlerin kaçırdığı pek çok sorunu gösterir. Örneğin sinyal gidip geldiğinde aynı kaydın kuyrukta iki kez görünmesi ya da durum etiketinin takılı kalması, ancak sahada fark edilir. Bulduğunuz her sorunu test listesine yeni bir madde olarak ekleyin.

Çevrimdışı modda güvenlik ve kişisel veriyi nasıl korursunuz?

Veriyi cihaza indirdiğiniz anda, o cihazın kaybolma ihtimali de veri güvenliği hesabına girer. Bu yüzden cihazda yalnızca işin gerektirdiği veriyi tutun, hassas alanları şifreli saklayın ve kullanıcı oturumu kapattığında yerel veriyi temizleyin. Ancak temizlemeden önce bekleyen kayıt var mı diye bakın ve kullanıcıyı uyarın; aksi halde güvenlik önlemi veri kaybına dönüşür.

Ayrıca uzaktan oturum sonlandırma senaryosunu düşünün: çalışan işten ayrıldığında ya da cihaz çalındığında, cihaz bir sonraki bağlantıda yerel veriyi silebilmelidir. Kişisel veri işleyen uygulamalarda saklama süresi ve silme kuralları için hukuki yükümlülükleriniz de devreye girer; bu yazı hukuki danışmanlık değildir, bu konuda hukuk danışmanınızla çalışın.

Saha ekibi uygulamasında çevrimdışı mod nasıl işler?

Örnek senaryo üzerinden gidelim. Bir servis firmasının teknisyeni sabah ofiste telefonunu açar ve uygulama o günün iş emirlerini, müşteri adreslerini ve yedek parça listesini cihaza indirir. Teknisyen ilk adrese gider; bina bodrumunda sinyal yoktur. Yine de iş emrini açar, yaptığı işlemleri işaretler, kullandığı parçaları seçer, iki fotoğraf çeker ve müşteriye ekranda imza attırır.

Uygulama bu kaydı yerel veritabanına yazar ve kaydın yanında "cihazda kaydedildi" etiketini gösterir. Teknisyen arabaya döndüğünde telefon bağlantıyı yakalar; önce iş emri metni, ardından fotoğraflar ve imza sunucuya gider. Merkezdeki planlamacı birkaç dakika içinde işin kapandığını görür. Bu akışta teknisyen hiçbir anda "internet yok" ekranıyla karşılaşmaz. Üstelik aynı gün merkez bir iş emrini iptal ederse, uygulama bir sonraki bağlantıda bu değişikliği alır ve teknisyene sade bir bildirimle haber verir.

Bu senaryoyu kâğıda dökmek, geliştirme başlamadan önce eksik kararları ortaya çıkarır. Örneğin iptal edilen bir iş emrine teknisyen çoktan başlamışsa ne olacak? Bu sorunun cevabı bir iş kuralıdır ve sizin vermeniz gerekir.

Depo uygulamasında çevrimdışı mod nasıl kurgulanmalı?

Depoda durum farklıdır. Burada aynı ürüne birden fazla kişi aynı anda dokunabilir; dolayısıyla çakışma riski saha uygulamasından daha yüksektir. Bu nedenle stok miktarını "son değer" olarak göndermek yerine her okutmayı bir hareket olarak kaydetmenizi öneriyoruz. Sayım görevlisi on adet ürün okuttuğunda cihaz "on adet giriş" hareketini kuyruğa yazar; sunucu bütün hareketleri toplayarak güncel stoğu hesaplar.

Böylece iki görevli aynı rafı farklı tabletlerde saydığında hiçbir hareket kaybolmaz. Ayrıca sunucu, mantıksız bir sonucu (örneğin eksiye düşen stok) fark ettiğinde kaydı reddedebilir ve sorumluya inceleme görevi açabilir. Barkod okutma hızı da önemlidir: okutma sonucunu ağdan beklemek yerine yerel ürün kataloğundan anında gösterin. Kısacası depo uygulamasında çevrimdışı mod hem hız hem de veri bütünlüğü için gereklidir.

Çevrimdışı modu bozan en yaygın hatalar hangileri?

Ekiplerin sık düştüğü hatalar birbirine benzer. Projeye başlamadan bu listeyi gözden geçirmenizi öneriyoruz:

• Ekranların bir kısmının hâlâ doğrudan sunucudan okuması; bu durumda aynı veri iki ekranda farklı görünür.
• Kimliği sunucunun atamasını beklemek; çevrimdışı oluşturduğunuz kayıtlar birbirine bağlanamaz.
• Kuyruğu bellekte tutmak; uygulama kapanınca bekleyen işlemler yok olur.
• Hata mesajlarını teknik dille yazmak; kullanıcı ne yapacağını anlamaz.
• Senkronizasyonu yalnızca arka plana bırakmak; sistem işi ertelediğinde veri saatlerce bekler.
• Uygulama güncellemesinde yerel veritabanı geçişini test etmemek.

Bu hataların ortak noktası, çevrimdışı modu bir özellik gibi sonradan eklemeye çalışmaktır. Oysa bu kararlar uygulamanın temelidir; sonradan düzeltmek de teknik borç biriktirir.

Çevrimdışı mod maliyeti ve proje süresini neler etkiler?

Çevrimdışı mod, bir uygulamanın kapsamını belirgin biçimde büyüten özelliklerden biridir. Ancak bu büyümenin miktarını tek bir rakamla vermek yanıltıcı olur; çünkü belirleyen şey işlem sayısı ve çakışma karmaşıklığıdır. Yalnızca okuma yapan bir katalog uygulaması ile çok kullanıcılı bir stok uygulaması aynı işi yapmaz.

Kapsamı şu etkenler belirler: çevrimdışı yapmak istediğiniz işlem sayısı, aynı kaydı değiştirebilecek kişi sayısı, medya yükü, sunucunun senkronizasyonu destekleyip desteklemediği ve eski sürümlerden veri taşıma ihtiyacı. Bu nedenle teklif istemeden önce yukarıdaki soruların cevabını hazırlamak, hem sizin hem de ekibin işini kolaylaştırır. Uygulamanızın mevcut bir Excel ya da tablo düzeninden geliyorsa, Excel'den özel yazılıma geçiş zamanını anlatan yazımız karar sürecine yardımcı olur.

Çevrimdışı mod için son kontrol listesi nedir?

Bu rehberin özetini, projeye başlamadan önce ekibinizle tek tek işaretleyebileceğiniz bir listeye çevirdik. Her maddenin cevabı yazılı olsun:

• Hangi işlemler çevrimdışı yapılabilir, hangileri sunucu ister?
• Yerel veritabanı tek doğru kaynak mı, ekranlar yalnızca oradan mı okuyor?
• Her işlem için yazma stratejisini seçtiniz mi?
• Çakışma kuralı veri tipine göre tanımlı mı?
• Her kaydın cihazda üretilen kimliği ve sürüm bilgisi var mı?
• Tekrar eden isteğe karşı işlem anahtarınız var mı?
• Kullanıcı her kaydın durumunu görebiliyor mu?
• Medya için ayrı ve devam ettirilebilir bir kuyruk var mı?
• Oturum kapanırken bekleyen kayıt uyarısı var mı?
• Güncelleme sonrası bekleyen kuyruk yerinde kalıyor mu?

Bu listenin her maddesi bir mimari karardır. Özetle iyi bir çevrimdışı mod, kullanıcının internetin varlığını düşünmeden işini yapabilmesidir. Bu kararları ürününüz için birlikte netleştirmek ve iş sürecinize uygun bir uygulama kurmak istiyorsanız mobil uygulama yaptırmak sayfamızda nasıl çalıştığımızı bulabilirsiniz.