Ekranı adımlar olarak değil, durumun görünümü olarak düşünün
Hafta sonu gidilebilecek yerleri listeleyen küçük bir uygulama düşünelim. Kartlar, bir arama alanı ve kaydetme düğmeleri var. Bir karta dokunulduğunda yalnızca kalbin rengi değişmiyor; kaydedilenler ekranı ve belki üstteki sayaç da güncelleniyor. Bu küçük etkileşim, arayüzün nasıl kurulacağına dair güzel bir başlangıç noktası.
Flutter’da widget’lar, mevcut veriye ve yapılandırmaya göre ekranda ne görüneceğini tarif eder. Veriyi değiştirdiğinizde ilgili build işlemleri yeniden çalışır; framework yeni açıklamayı öncekiyle karşılaştırır. Tek tek ekrandaki parçaları bulup değiştirmek yerine, ‘Bu yer kaydedilmişse kart nasıl görünmeli?’ sorusuna yanıt verirsiniz. Bu yaklaşıma bildirimsel arayüz denir.
Örnekte PlaceCard adlı bir widget’a yerin adı, görseli, kaydedilme durumu ve bir işlem geri çağrısı verilebilir. Kartın görevi bilgiyi göstermek ve dokunmayı bildirmektir. Hangi kayıtların saklanacağına karar vermesi gerekmez. Böylece aynı kartı keşif ve kaydedilenler ekranlarında farklı veriyle kullanmak kolaylaşır.
Her durum bilgisi aynı yerde yaşamak zorunda değil
Arama kutusunun açık olması gibi yalnızca küçük bir parçayı ilgilendiren geçici bilgiler yerel tutulabilir. Birden fazla ekranın kullandığı kaydedilen yerler ise ortak bir kaynağa ihtiyaç duyar. Bu ayrım, uygulamanın ihtiyacına göre yapılır; bir değişkenin adı hangi yönetim aracını seçeceğinizi tek başına belirlemez.
Keşif ekranında kaydettiğiniz bir yerin diğer ekranda da görünmesini istiyorsanız, aynı listenin iki bağımsız kopyasını güncellemeye çalışmayın. Tek bir kaynağı okuyun, değişiklikleri o kaynak üzerinden yapın. Uygulama kapandığında listenin korunması ayrı bir karardır: Bellekte ortak durum tutmak, kendiliğinden diske ya da sunucuya kayıt yapmak anlamına gelmez.
- Bu bilgiyi hangi ekranların okuduğunu belirleyin.
- Bilgiyi kimlerin ve hangi işlemlerle değiştirebildiğini netleştirin.
- Uygulama yeniden açıldığında korunması gerekenleri ayrıca planlayın.
Yeniden oluşturma normaldir; maliyetini anlamak daha faydalıdır
Bir widget’ın yeniden oluşturulması, ekranın her pikselinin baştan çizildiği anlamına gelmez. Bu yüzden bütün rebuild işlemlerini kaldırmaya çalışmak iyi bir hedef değildir. Önce sık değişen parçaları ayırın: Karttaki kaydetme işleminin, sayfanın ilgisiz bölümlerindeki pahalı hesapları tekrar başlatması gerekmemeli.
Sabit yapılandırmalı widget’ları uygun yerlerde const ile oluşturmak, aynı örneğin yeniden kullanılmasına yardımcı olur. Ancak const, arayüzü donduran bir anahtar değildir. Tek başına akıcılık garantisi de vermez. Büyük bir build metodunu anlaşılır widget’lara bölmek ve değişen bilgiyi onu kullanan bölgeye yakın tutmak, hem kodun takibini hem de ölçüm sonuçlarını yorumlamayı kolaylaştırır.
Bekleme anlarını da deneyimin parçası olarak tasarlayın
Keşif listesinin verisi uzaktan geliyorsa dört ayrı sahne düşünün: Yükleniyor, içerik geldi, sonuç yok ve bir sorun oldu. Boş bir ekran bu durumların hangisini anlattığını söylemez. Kısa bir açıklama, uygun bir tekrar deneme düğmesi ve anlamlı bir boş durum, kullanıcının ne olduğunu anlamasına yardım eder.
Kaydetme işlemi ağ isteği gerektiriyorsa düğmeye art arda dokunulduğunda ne olacağını da belirleyin. İşlem sürerken geri bildirim vermek ve hata olduğunda tutarlı bir duruma dönmek, yalnızca animasyonu hızlandırmaktan daha görünür bir fark yaratabilir. Bu örnekteki davranışları küçük bir akış çizimiyle tarif etmek, uygulamaya geçmeden önce eksik durumları yakalamanızı sağlar.
Akıcılığı gerçek cihazda, aynı senaryoyla ölçün
Android ve iOS arayüz performansını değerlendirirken fiziksel cihazda profile modunu kullanın. Debug modundaki ek kontroller ve emülatörün donanım farkları, yayın sürümünün davranışını temsil etmeyebilir. Flutter DevTools’un Performance görünümü, karelerde zamanın nerede harcandığını incelemenize yardımcı olur.
Ölçüm için kısa bir senaryo yazın: Listeyi aç, birkaç ekran kaydır, bir yeri kaydet ve kaydedilenlere geç. Aynı cihaz ve benzer veriyle önceki sonucu karşılaştırın. Değiştirdiğiniz parçanın bu akışı iyileştirip iyileştirmediğine bakın. Ölçüm notuna cihaz modelini, uygulama sürümünü ve denediğiniz veri miktarını da ekleyin. Sonraki değişiklikte aynı koşulları kurmak ve sonucu ekip içinde paylaşmak çok daha kolay olur. Böylece ‘Daha hızlı hissettirdi’ düşüncesini, tekrar bakabileceğiniz somut bir gözlemle desteklemiş olursunuz.
Kaynaklar ve devamı
Konuyu biraz daha kurcalamak istersen, bu yazıda yararlandığımız resmî dokümanlar burada.