Mobil uygulama

Makine dairesinde sinyal yoktur

ASNPRO’yu yazarken öğrendiğimiz ilk şey buydu. Bakım teknisyeni asansörün makine dairesinde, çoğu zaman bodrumda ve çoğu zaman şebekesizdir. Kaydı orada giremeyen teknisyen akşam ofiste hatırladığı kadarını girer; girilen bilgi de o andaki gerçeği değil, hatırlananı yansıtır.

Saha uygulaması ile vitrin uygulaması arasındaki fark burada başlar. Vitrin uygulaması internet olmadığında bir uyarı gösterip bekleyebilir. Saha uygulamasının internet olmadığında da çalışması, kaydı alması ve şebeke geldiğinde göndermesi gerekir. Bu tercih mimarinin tamamını değiştirir; sonradan eklenen bir özellik değildir.

Çevrimdışı kuyruk nasıl kuruluyor

Uygulama yazma işlemlerini doğrudan sunucuya değil, önce cihazdaki yerel veritabanına yazar. Her kayıt bir sıra numarası ve cihaz kimliğiyle işaretlenir. Bağlantı geldiğinde kuyruk sırayla gönderilir; gönderilen kayıt onay alana kadar kuyruktan silinmez, uygulama kapanıp açılsa bile kuyruk yerinde durur.

İşin zor kısmı çakışmadır: aynı kaydı iki kişi çevrimdışıyken değiştirirse ne olacağı baştan kararlaştırılmalıdır. Bazı alanlarda son yazan kazanır, bazılarında sunucudaki değer korunur, bazılarında kullanıcıya sorulur. Bu kuralı alan alan biz değil, sizin işinizin mantığı belirler; kapsam adımında tek tek konuşuruz.

Fotoğraflar ayrı bir kuyrukta taşınır. Büyük dosyalar cihazda küçültülür ve parça parça gönderilir; yarıda kesilen aktarım baştan başlamaz, kaldığı yerden devam eder.

Kamera, QR ve konum akışları

ASNPRO’da bir bakım, asansör kabinindeki QR okutulmadan kapanmaz. Bunun sebebi teknisyene güvensizlik değil, kaydın nerede üretildiğinin doğrulanabilir olması. Aynı mantık depo sayımında, teslimat onayında ve varlık takibinde de kurulabilir: iş kapanırken bir doğrulama noktasından geçer.

Kamera tarafında karşılaşılan pratik sorunlar bellidir: düşük ışık, buğulu kamera camı, eldivenle kullanım, farklı üreticilerin farklı kamera davranışları. QR okuyucuyu bu koşullarda test ederiz. Konum tarafında ise kaydın alındığı andaki koordinat ile o anki doğruluk payını birlikte saklar, pil tüketimini artırmamak için sürekli değil olay bazlı konum alırız.

Flutter’ı neye göre seçiyoruz

Flutter’ı tek kod tabanından Android ve iOS çıkarabildiğimiz için kullanıyoruz. İki ayrı ekip, iki ayrı sürüm takvimi ve aynı hatanın iki kez düzeltilmesi ortadan kalkıyor. Arayüzü kendi çizdiği için iki platformda da aynı görünür, bu da tasarım onayını tek geçişe indiriyor.

Her iş için doğru araç değildir. Ağır kamera işleme, özel sürücü konuşması ya da platforma çok bağlı bir arka plan davranışı gerekiyorsa o parçayı yerel dilde yazıp köprüyle bağlarız; bazen de doğrudan yerel geliştirmeyi öneririz. Araç tercihini teklif aşamasında gerekçesiyle yazarız, sonradan tartışılacak bir konu olarak bırakmayız.

Arka uç, panel ve sürüm yönetimi

Mobil uygulama tek başına bir ürün değildir. Yanında veriyi tutan bir arka uç, yöneticinin baktığı bir panel ve sürüm yönetimi gerekir. Paneli genellikle web tarafında kurarız: kullanıcı ve yetki yönetimi, kayıtların listelenmesi, raporlar ve dışa aktarma.

Sürüm yönetiminde önemli bir kural var: kullanıcıların bir kısmı her zaman eski sürümde kalır. Bu yüzden arka uç API’si eski sürümlerle çalışmaya devam edecek şekilde sürümlenir ve zorunlu güncelleme yalnızca gerçekten kırıcı bir değişiklik olduğunda devreye girer. Uzaktan açılıp kapanabilen özellik anahtarları da aynı sebeple kullanılır: yeni bir akışı önce sınırlı bir ekibe açarız.

Test cihazlarından mağaza yayınına

Geliştirme sırasında her teslim test dağıtımıyla sizin telefonunuza düşer; mağazaya çıkmadan kendi ekibiniz gerçek cihazda kullanır. Saha uygulamalarında bu adımı uzun tutarız, çünkü bir akışın masabaşında doğru, sahada yanlış olması sık rastlanan bir durumdur.

Mağaza yayınında hazırlanması gereken kalemler bellidir: uygulama simgesi ve ekran görüntüleri, gizlilik politikası ve veri toplama beyanı, hesap silme yolu, izin metinlerinin gerekçeleri. Bunları biz hazırlarız, hesapların sizin adınıza açılması için gereken adımlarda eşlik ederiz. Yayından sonra çökme raporlarını izler, ilk sürümün ardından gelen düzeltmeleri planlanan bakım kapsamında yayımlarız.

İzinler, pil ve cihaz çeşitliliği

Mağaza incelemelerinin takıldığı en yaygın nokta izinlerdir. İstenen her izin için hangi özelliğin onu gerektirdiği açıkça yazılmalıdır; gerekçesiz istenen konum ya da rehber izni reddedilme sebebidir. Bu yüzden izin listesini özellik listesinden türetir, kullanılmayan izinleri paketten çıkarırız. İzni, kullanıcı ilgili özelliği ilk kez açtığında ve neden gerektiğini anlatan kısa bir açıklamayla isteriz.

Pil tüketimi saha uygulamalarında somut bir şikâyet kalemidir. Sürekli konum takibi, açık kalan kamera ve sık sunucu sorgusu bataryayı vardiya bitmeden tüketir. Konumu olay bazlı alır, sunucu sorgularını toplu hale getirir ve arka plan işlerini işletim sisteminin uygun gördüğü aralıklara bırakırız.

Cihaz çeşitliliği tarafında ise test listesini sizin ekibinizin gerçekten kullandığı telefonlardan çıkarırız. Sahada beş yıllık, düşük bellekli bir Android cihaz varsa test cihazı odur; en yeni modelde sorunsuz çalışan bir ekran orada takılabilir.