Bu makale sırasında, Bildirime Dayalı Kullanıcı Arabirimlerinin, Zorunlu Kullanıcı Arabirimleriyle karşılaştırıldığında neden bir seçim olabileceğinin nedenlerini ve gerçekten bunun Android'de önemli olan bir seçim olabileceğinin nedenlerini tartışacağız.
"Sonlu durum" terimini sınırlı sayıda durum gibi anlayan bir durum makinesi veya sonlu durum makinesi. Tanım olarak, matematiksel bir hesaplama modelidir. Bu aslında çok ünlü Turing Makinesi'nin basitleştirilmesidir, temelde bir durum makinesi onun bir alt kümesi olacaktır. Sonlu bir durum kümesi olduğunda ve deterministik bir sonlu durum makinesi seçtiğimizde, o zaman bize somut bir girdiden bir çıktıyı tahmin etme fırsatı verecektir.
Bir ATM, şüphesiz, banka kartımızla bir işlem başlatabileceğimiz ve PIN girildikten ve doğrulandıktan sonra yapabileceğimiz sınırlı sayıda eylem / işlemin olduğu bir durum makinesinin bir örneği olacaktır. Aksi takdirde, PIN doğrulaması maksimum deneme sayısına ulaşır ve son duruma geçer, bu son durum banka kartı çıkarıldığında gerçekleşir.
Yukarıdaki şemada, her bir ok üzerindeki iş akışına karşılık gelen bir durum kombinasyonu görebiliriz. Her "eylem", "doğrulanmış", "reddedilmiş" (bir dizi denemeyle), "reddedilmiş" (maksimum sayıda denemeyle), "doğrulanmış" veya "tamamlanmış" gibi bir "duruma" dönüştürüldüğünde.
Bir durum makinesi aynı zamanda işlevsel programlamada gerçekten önemli bir terimle gerçekten iyi bir şekilde ilgileniyor , "referanslı şeffaflığı" hatırlıyor musunuz?
Kompozisyon yoluyla daha küçük işlevlerden daha büyük işlevler yapma ve belirli bir girdi için her zaman aynı çıktıyı üretme yeteneği
Merak edebilirsiniz, tüm bunların neden Bildirime Dayalı Kullanıcı Arabirimleri için önemli olduğunu merak edebilirsiniz.
Bildirime Dayalı Kullanıcı Arayüzünün doğası gereği düşünerek, bu kavramlardan yararlanırlar.
Bu serinin ilk makalesini hatırlarsanız, Tek Yönlü Veri Akışı ilkelerinden bahsetti . Bir kez modellendiğinde , mevcut eylemin ihtiyaçlarına bağlı olarak bir dizi UI durumu modellenmiştir . Bu eylemler, kullanıcı arayüzünde işlenen durumlara dönüştürüldü.
Daha fazla düşünürsek, temelde sonlu sayıda durum veren bir durum makinesi, dolayısıyla bir sonlu durum makinesi yarattık.
Android uygulamalarında yıllarca onlarla çalıştıysak, Emperatif Kullanıcı Arayüzleri neden yeterince iyi değil?
Bunun için, öncelikle hem Bildirime Dayalı hem de Zorunlu paradigmaları karşılaştırmalıyız.
Tanım olarak, ben mperatif programlamada , bir programın durumunu değiştirmek için ifadeler kullanırız. Bunun anlamı, Emir paradigma odaklanan “ nasıl belli bir duruma” Biz bunu başarmak alır.
Bu gerçekten kötü bir şey değil, değil mi?
Düşünmek Zorunlu UI daha spesifik ve kompleksliklerini artar daha bunların her biri kendi durumunu başarınca yanı sıra onları orkestra için bir ihtiyaç. Bir
Viewtipik olarak durumunu tanımlayan bir veya daha fazla değişkeni ilişkilendirir. Örneğin bir düğme geçildiğinde kapalı için ve tam tersi . Şimdi, birden çok XML ve özel görünümde birkaç iç içe görünüm içeren gerçekten karmaşık bir kullanıcı arayüzüne sahip olduğunu hayal edin. Daha sonra, tüm eyaletleri ayrı ayrı ele almayı ve her biri için ebeveynlerin hiçbirinin bilmediği bazı ara durumları kaydetmeyi düşünün. Tam da o anda, muhtemelen pişman olduğumuz ve asıl mesele ortaya çıktığı andır. Belirleyici bir yaklaşımımız yok, o zamana kadar sonlu bir durum kümesi de yok.
Şimdi, Bildirime Dayalı Kullanıcı Arayüzlerini düşündüğümüzde , önemli kavram " ne " dir, " nasıl " değil , Bildirici paradigmada onu "nasıl" istediğimizi tanımlamaya gerek yok . Biraz sonra "Neden" e bakacağız !
Bildirime Dayalı Kullanıcı Arayüzlerinin Uygulanmasında yapılan bazı önemli noktaları hatırlamak için . Bir görünümün gizlendiğini mi yoksa gösterildiğini mi söylerdik . Böylece, görünüm bu bilgiyi kaydetti ve kendi durumunu değiştirdi.
Farklı olarak, gerekli olmayan Bildirime Dayalı UI'larda. Bir ekran, devletin açıkça zorunlu kıldığı şekilde görüntülenir. Bu, sadece kullanıcı arayüzü mantığımız ve durum makinemiz tarafından anlaşılan bir dizi kural getirerek, isteğe bağlı UI görünümleri oluşturacağımız anlamına gelir.
Şimdi, tüm bu kavramları özellikle Android'e indirgiyoruz. Daha modern bir kullanıcı arayüzü sağlamak için ihtiyacımız olan her şeye sahip olup olmadığımızı düşünmeliyiz.
Kontrol etmek isteyebileceğimiz ilk şey Birlikte Çalışabilirliktir .
Android üzerinde düşünmek, gerçekten Jetpack Compose Birlikte Çalışabilirlik harika.
Örneğin, bir ekranı tanımlayan bir kullanıcı arayüzüne sahip olduğumuzda ve bu ekranın bitlerini ve parçalarını Compose'a taşımak istediğimizde, hepsini bazı gömülü XML dosyalarına alabiliriz. Neyse ki bu uyumludur ve kullanılarak klasik bir XML düzenine kolayca entegre edilebilir
ComposeView. Bu kullanım senaryosu, onu mevcut bir düzene entegre etmek istediğimizde gereklidir. Genişletilmiş bir örnek için buradan daha fazlasını okuyun .
Ancak tam tersi yönde, ister parlak yeni bir Compose ekranı yaratmış olsak, ister eski yıllarda oluşturulmuş gerçek bir büyük özel görünümü yeniden kullanmamız gerekse, merak etmeyin, onu da dahil edebiliriz
AndroidView.
Hakkında daha fazla içerik için İşletilebilirlik , ben tavsiye bu yazıyı tarafından Adam Bennett .
Compose ile Classic View sistemi arasındaki önemli bir fark, Compose'un grupsuz olmasıdır. Bu, Android işletim sisteminin bir parçası olmadığı anlamına gelir, çünkü bir kitaplıktır. Bu aynı zamanda muhtemelen her iki tür paradigma ve görüşle yaşamamız gerektiği anlamına gelir.
Az önce yeniden düzenlemeden bahsettik, ama ya durumları farklı yeniden düzenlemelerde kurtarmamız gerekirse?
Bu amaçla,
remember yeniden düzenlemeden sonra kullanılacak ve bizim için tutulacak yerel bir devleti kurtaracak bir şeyimiz var .
Bir başka ilginç kavram, Kompozisyon Yerel (CL) olarak adlandırılır , tüm oluşturulabilir işlevlere açıkça bir parametre eklemek zorunda kalmadan bir veri akışını ağaçtan ve çocuklarından geçirmenin en basit yolu olarak kabul edilir (bu kavramı genişletmeyeceğim çünkü o tam bir blog yazısı olabilir, belki de Dependency Injection'a aşina iseniz, bu size tanıdık bir şey gibi görünebilir).
Birleştirilebilir işlevlerimizden birine bir yan etki (bir veritabanı işlemi veya ağ isteği gibi) eklemek istersek ne olur? Biz kaplıdır SideEffect ve diğer Etkisi Yükleyici . Bunlar her yeniden düzenlemeden sonra koşarlar. Daha fazla okumak için tavsiye bu yazıyı tarafından Jorge Castillo .
Klasik görünümlerde, diyelim ki devasa dosyayı genişletmek zorundayız
View. Tipik olarak, çok az bir değişiklik elde etmek için görünüme gittikçe daha fazla katman eklemeye başlamamız gerekir. Ki bu ideal değil.
Bu ve her zaman XML dosyalarından Java / Kotlin koduna geçiş. Her ikisi arasında bir bariyer belirleyen, View-Binding ile yine de ortadan kaybolan bir bariyer , ancak bunlar arasında açık bir ayrım oldu.
Bir yandan, hem Compose (XML yerine) hem de başka herhangi bir şey için kod kullanmanın gizli maliyeti, artık endişelerin ne zaman / nasıl uygun şekilde ayrılacağının farkında olmamız gerektiğidir. Teşekkürler, Tek Yönlü Veri Akışı .
Öte yandan, Compose, basit bir kullanıcı arayüzü için gereken kod satırı sayısını kesinlikle kazanır.
Vatansız olmak için hedefler oluşturun . Bu, daha önce bahsettiğimiz klasik görüşün tersine, görüşle ilişkili bir durum olmadığı anlamına gelir. Şimdiye kadar, kullanıcı arayüzünün yeniden yapılandırılmasını etkinleştirmek ve Tek Yönlü Veri Akışından yararlanmak için değişmez veri yapıları göndermeyi öğrendik. Oluşturma'da UI öğelerinin görünürlüğünü ayarlamıyoruz, görünüm oluşturulduğunda UI ağacında veya yuva tablosunda ya da yok.
Klasik görünümler durum bilgisine sahiptir . Genellikle bir görünümün kendisiyle ilişkilendirilmiş bir durumu vardır, örneğin görünürlüğü. Belirli bir değişikliğe bağlı olarak değişen dahili olarak değişken durumlara sahip olma eğilimindedir.
Compose, gerçekten hızlı koşmayı hedefler çünkü ağacın her yeniden kompozisyonunu paralel olarak çalıştırabilir. Ancak bu, bu yeniden düzenlemeler için bir emir vermeyi garanti etmez.
Henüz performansta iyileştirme için alan olmasına rağmen. Compose ekibi şu anda performans iyileştirmelerine odaklanıyor.
Compose, Bildirime Dayalı olduğu için elde edilmesi daha kolay olacaktır. Varsayılan olarak yalnızca değişmez veri yapılarını geçirirsek, farklı bileşenleri ayrı ayrı test edebiliriz. Tüm derin katmanların zaten test edildiğini varsayalım. Bu durumda, doğrudan UI testleri, Karumi'nin Shot adlı kütüphanesiyle ekran görüntüsü testleri veya Espresso benzeri UI testleri gerçekleştirebiliriz .
UI bileşenlerinin yeniden kullanılabilirliği, yeniden kullanılabilen ve daha da önemlisi genişletilebilen genel bileşenler oluşturmak oldukça kolaydır.
Yeni bir bileşen oluşturmak, klasik Android görünümlerinden çok daha az kod satırı gerektirir. Bölüm 2'de UDF'yi Uygulama'dan
RecyclerView Android'de a örneğine bakın .
Bildirime dayalı kullanıcı arayüzleri, daha kolay deneme ve bununla birlikte yeni çalışma yöntemleri sağlar. Örneğin, Compose, sonsuz sayıda sınıf olmadan Sunucu Tahrikli Kullanıcı Arabirimlerini etkinleştirir (iyi makale Joe ! İçin teşekkürler !).
Açıkça devlet beyanlarını BUGÜN kabul etmeye başlamanızı tavsiye ederim . Kesinlikle hem Bildirime Dayalı hem de Zorunlu Kullanıcı Arabirimlerini etkinleştirir, sistemlerimizin daha belirleyici (belirli bir girdiden gelen bir çıktıyı tahmin etme) veya sonlu durumlu makine benzeri olmasına ve dolayısıyla daha öngörülebilir ve hataya dayanıklı olmasına yardımcı olur .
Bildirime dayalı kullanıcı arayüzleri kesinlikle gelecek. Aslında, React JS ile Web için, Flutter ile çoklu platformda ve SwiftUI ile iOS için bir gerçek oldular . Kotlin Multiplatform ve Compose Desktop'ı unutmadan .
Android'e rağmen, bir süre yaşayacağımızdan emin olmak için işletim sistemi görünümlerine ihtiyacımız olacak, Compose'u daha fazla kullanacağımız zaman parlak bir gelecek görebiliyorum.
Bu bir paket. Umarım dizinin bu son makalesini yazdığım kadar beğenmişsindir.
Bu makaleyi beğendiyseniz, alkışlayın ve paylaşın, lütfen!
Şerefe!
Raul Hernandez Lopez
GitHub | Twitter | Eserler
Adam Bennett ve Jossi Wolf'a ( onları takip edin ) bu makalenin iyi incelemesi için ve onu herkes için daha okunaklı hale getirdikleri için özel bir teşekkür etmek istiyorum !
Bu dizinin önceki makaleleri şunlardı:
Devam eden bu makale dizisi, Firebase Test Lab'de çalışan Android enstrümantasyon testleri için bir kod kapsamı raporunun nasıl oluşturulacağını açıklayacaktır. Bölüm 3 için Gereksinimler Bu dizinin 1. Bölümünde şunların nasıl yapıldığını gördük: Flank, Firebase Test Lab'de testleri yürütmek için kullandığımız birçok ortak özelliği kaldırmamıza izin veren harika bir test çalıştırıcıdır.
Muhtemelen, Google Play'de yeni bir uygulama yayınlamak üzereyseniz, dünya çapında bir hedefiniz varsa ve entegre reklamcılık yapıyorsanız, kesinlikle Avrupa Ekonomik Alanı'ndaki (AEA) kullanıcılar için GDPR onayını uygulamaya çalıştınız. Kullanıcı kişiselleştirilmiş reklamlara, kişiselleştirilmemiş reklamlara izin vermeyi veya hatta reklamları hiç görmemek için ödeme yapmayı seçebildiğinden, eski izin kitaplığı ile çok basit bir adımdı.
Bu ay tüm yeni abonelerimize ve yazarlarımıza sıcak bir karşılama; sürülerinizde ortaya çıkıyorsunuz ve bunun için size teşekkür ediyoruz. Burada harika bir topluluk oluşturuyoruz ve yorumlarınızı ve makalelerinizi okumak harika.
Arka hikaye Her ürünün bir hikayesi vardır ve bu Yapdoof'un başlangıç hikayesidir. Yapdoof, Omept Technology Nijerya Limited'in bir ürünüdür.
Bugün farklı bir yolculuğa çıkıyoruz. Çoğunlukla resimler.
Amerikalı koşucu Athing Mu, profesyonel kariyerinde ilk kez 800 metrelik bir yarışı kaybedebilirmiş gibi görünüyordu. Mu, tipik olarak, az kol hareketi ve görünüşte az enerji içeren benzersiz ve zahmetsiz bir adımla yarışlarına hükmeder.