Android'de hangi Mimari desenleri kullanılıyor? [kapalı]

Mobil platformlarla ilgili küçük bir araştırma yapıyorum ve Android'de hangi tasarım modellerinin kullanıldığını bilmek istiyorum?

örneğin iOS Model-view-controller delegasyon ve diğer modellerle birlikte çok yaygın olarak kullanılmaktadır.

Android hangi kalıpları ve özellikle nerede kullanıyor?

DÜZENLE

Çekirdek, dalvik vb. Derinlerde kullanılan tasarım kalıpları değil, bir uygulama geliştiricisinin uygulama geliştirirken karşılaşacağı kalıplar hakkında soruyorum.

Android geliştirme yapmak için hem model-görünüm-denetleyici (MVC) hem de model-görünüm-sunucu mimari desenlerini kullanmayı denedim . Bulgularım model-görünüm-denetleyici iyi çalışıyor, ancak birkaç "sorun" var. Her şey Android Activitysınıfını nasıl algıladığınıza bağlı . Bir denetleyici mi yoksa bir görüş mü?

Gerçek Activitysınıf Android'in Viewsınıfını genişletmez , ancak kullanıcıya bir pencere görüntülemeyi ve o pencerenin olaylarını (onCreate, onPause vb.) İşler.

Bu, bir MVC kalıbı kullandığınızda, denetleyicinizin gerçekte sahte bir görünüm denetleyicisi olacağı anlamına gelir. SetContentView ile eklediğiniz ek görünüm bileşenleri ile kullanıcıya bir pencere görüntülemeyi yönettiği ve en azından çeşitli etkinlik yaşam döngüsü olayları için olayları işlediği için.

MVC'de, kontrolörün ana giriş noktası olması gerekir. Etkinlik çoğu uygulamanın doğal giriş noktası olduğu için, Android geliştirmeye uygulanırken durum biraz tartışmalıdır.

Bu nedenle, kişisel olarak model-görünüm-sunucu deseninin Android geliştirme için mükemmel bir uyum olduğunu düşünüyorum. Görünümün bu modeldeki rolü:

• Giriş noktası olarak hizmet vermek
• İşleme bileşenleri
• Kullanıcı olaylarını sunucuya yönlendirme

Bu, modelinizi şöyle uygulamanızı sağlar:

Görünüm - bu, kullanıcı arayüzü bileşenlerinizi içerir ve bunlar için etkinlikleri işler.

Sunucu - bu, modeliniz ve görünümünüz arasındaki iletişimi ele alır, modelinize bir geçit olarak bakar. Yani, temsil eden karmaşık bir etki alanı modeliniz varsa, Tanrı neyi bilir ve görüşünüzün bu modelin çok küçük bir alt kümesine ihtiyacı varsa, sunum yapan kişinin işi modeli sorgulamak ve sonra görünümü güncellemektir. Örneğin, bir metin paragrafı, bir başlık ve bir kelime sayısı içeren bir modeliniz varsa. Ancak belirli bir görünümde, başlığı yalnızca görünümde görüntülemeniz gerekir. Ardından, sunucu modelden gerekli verileri okuyacak ve görünümü buna göre güncelleyecektir.

Model - temelde tam alan modeliniz olmalıdır. Umarım etki alanı modelinizi daha "sıkı" hale getirmenize yardımcı olacaktır, çünkü yukarıda belirtildiği gibi vakalarla başa çıkmak için özel yöntemlere ihtiyacınız olmayacaktır.

Modeli görünümden hep birlikte ayırarak (sunum yapan kişi kullanarak), modelinizi test etmek çok daha sezgisel hale gelir. Etki alanı modeliniz için birim testleri ve sunum yapanlarınız için birim testleri yapabilirsiniz.

Denemek. Ben şahsen Android geliştirme için çok uygun buluyorum.

Kasım 2018 Güncellemesi

Android'de MVC ve MVP hakkında birkaç yıl çalıştıktan ve blog yazdıktan sonra (aşağıdaki cevabın gövdesine bakın), bilgi ve anlayışımı daha kapsamlı ve kolay sindirilebilir bir biçimde yakalamaya karar verdim.

Bu yüzden, Android uygulamaları mimarisi hakkında tam bir video dersi yayınladım. Bu nedenle, Android geliştirmedeki en gelişmiş mimari kalıplara hakim olmak istiyorsanız, bu kapsamlı kursa buradan göz atın .

Bu yanıt Kasım 2016'dan itibaren geçerli kalabilmek için güncellendi

Görünüşe göre tasarım desenlerinden ziyade mimari desenler arıyorsunuz .

Tasarım kalıpları , programcının belirli bir yinelenen yazılım görevlerini yönetmek için uygulayabileceği genel bir "numara" tanımlamayı amaçlamaktadır. Örneğin: OOP'de, bir nesnenin bazı olaylar hakkında bir dizi başka nesneyi bildirmesi gerektiğinde, gözlemci tasarım deseni kullanılabilir.

Android uygulamaları (ve AOSP'nin çoğu) nesne yönelimli Java'da yazıldığından, Android'de KULLANILMAYAN tek bir OOP tasarım deseni aramakta zorlanacağınızı düşünüyorum.

Öte yandan mimari desenler , belirli yazılım görevlerini ele almaz - söz konusu yazılım bileşeninin kullanım durumlarına dayalı olarak yazılım organizasyonu için şablonlar sağlamayı amaçlar .

Biraz karmaşık gelebilir, ancak umarım bir örnek açıklığa kavuşacaktır: Uzak bir sunucudan veri almak ve kullanıcıya yapılandırılmış bir şekilde sunmak için bazı uygulamalar kullanılacaksa, MVC dikkate almak için iyi bir aday olabilir. Yazılım görevleri ve uygulamanın program akışı hakkında hiçbir şey söylemediğimi unutmayın - sadece kullanıcının bakış açısından tanımladım ve bir mimari desen adayı ortaya çıktı.

Sorunuzda MVC'den bahsettiğinizden, mimari desenlerin aradığınız şey olduğunu tahmin ediyorum.

Tarihsel olarak, Google'ın uygulama mimarileri hakkında (diğer nedenlerin yanı sıra) Android uygulamalarının kaynak kodunda tam bir karmaşaya yol açan resmi bir kılavuz yoktu. Aslında, bugün gördüğüm çoğu uygulama hala OOP en iyi uygulamalarını takip etmiyor ve net bir mantıksal kod organizasyonu göstermiyor.

Ancak bugün durum farklı - Google kısa süre önce Android Studio ile tamamen entegre olan Veri Bağlama kütüphanesini yayınladı ve hatta Android uygulamaları için bir dizi mimari plan çıkardı .

İki yıl önce Android'de MVC veya MVP hakkında bilgi bulmak çok zordu. Bugün, MVC, MVP ve MVVM, Android topluluğunda "vızıltı kelimeler" haline geldi ve sürekli olarak MVx'in MVy'den daha iyi olduğuna ikna etmeye çalışan sayısız uzmanla çevriliyiz. Kanımca, MVx'in MVy'den daha iyi olup olmadığını tartışmak tamamen anlamsızdır, çünkü terimlerin kendileri çok belirsizdir - sadece bu sorunun cevaplarına bakın ve farklı insanların bu kısaltmaları tamamen farklı yapılarla ilişkilendirebileceğini anlayacaksınız.

Android için en iyi mimari desen arayışının resmen başlatılması nedeniyle, sanırım birkaç fikir daha ortaya çıkıyor. Bu noktada, gelecekte hangi örüntünün (veya örüntülerin) endüstri standardı olacağını tahmin etmek gerçekten imkansızdır - beklememiz ve görmemiz gerekecek (sanırım bir iki yıl meselesi).

Ancak, yüksek derecede güvenle yapabileceğim bir tahmin var: Veri Bağlama kütüphanesinin kullanımı endüstri standardı olmayacak. Veri bağlama kitaplığı (mevcut uygulamada) kısa vadeli verimlilik kazanımları ve bir tür mimari rehberlik sağladığı için eminim, ancak kodun uzun vadede sürdürülemez olmasını sağlayacaktır. Bu kütüphanenin uzun vadeli etkileri ortaya çıktıktan sonra terk edilecektir.

Şimdi, bugün bir çeşit resmi yönerge ve aracımız olmasına rağmen, şahsen, bu yönergelerin ve araçların mevcut en iyi seçenekler olduğunu düşünmüyorum (ve kesinlikle sadece bunlar değil). Uygulamalarımda bir MVC mimarisi uygulamamı kullanıyorum. Basit, temiz, okunabilir ve test edilebilir ve herhangi bir ek kütüphane gerektirmez.

Bu MVC sadece kozmetik olarak diğerlerinden farklı değildir - Android'deki Etkinliklerin kod organizasyonu üzerinde büyük etkileri olan UI Öğeleri olmadığı teorisine dayanmaktadır .

Dolayısıyla, SOLID ilkelerini takip eden Android uygulamaları için iyi bir mimari desen arıyorsanız, Android'deki MVC ve MVP mimari desenleri hakkındaki yazımda bir açıklama bulabilirsiniz .

Bu gönderiye ulaştığımda gerçekten örneklerle desenleri anlamama yardımcı oluyor, bu yüzden Android Framework'te Tasarım desenlerini ve örneklerini açıkça görmek için aşağıdaki tabloyu yaptım

Umarım faydalı bulacaksınız.

• Referans için bazı yararlı bağlantılar:
  

  1. Kotlin ile Android için Ortak Tasarım Desenleri

  2. Android Tasarım Desenlerine Giriş

  3. Tasarım desenleri

Android çerçevesinde kullanılan çeşitli desenler vardır:

• Yayın alıcısı Observer desenini kullanıyor
• Uzak kullanıcı hizmeti çağırma Proxy kalıbı kullanır
• Görüntüleme ve görüntüleme grubu Bileşik desen kullanır
• Medya çerçevesi Cephe desenini kullanıyor

İşte Android için Ortak Tasarım Desenleri hakkında harika bir makale :

Yaratıcı desenler:

• Oluşturucu (örn. AlertDialog.Builder )
• Bağımlılık Enjeksiyonu (örn. Hançer 2 )
• Singleton

Yapısal desenler:

• Adaptör (örn. RecyclerView.Adapter )
• Cephe (örneğin Retrofit )

Davranış kalıpları:

• Komut (ör. EventBus )
• Gözlemci (örneğin RxAndroid )
• Model Görünümü Denetleyici
• Model Görünümü ViewModel ( yukarıdaki MVC modeline benzer )

Aşağıdaki Android Sınıfları Tasarım Desenleri kullanır

1) Görünüm Tutucu Singleton Tasarım Deseni kullanır

2) Niyet Fabrika Tasarım Desenini kullanır

3) Adaptör Adaptör Tasarım Deseni kullanır

4) Yayın Alıcı Gözlemci Tasarım Deseni kullanır

5) görünüm kullanır kompozit tasarım deseni

6) Medya FrameWork Cephe Tasarım Deseni kullanır

Gelen bildirimler durumunda, NotificationCompat.Builderkullandığı Oluşturucu Desen

sevmek,

mBuilder = new NotificationCompat.Builder(this)
                    .setSmallIcon(R.drawable.ic_stat_notification)
                    .setContentTitle(getString(R.string.notification))
                    .setContentText(getString(R.string.ping))
                    .setDefaults(Notification.DEFAULT_ALL);

Android ayrıca ViewHolder tasarım desenini de kullanıyor.

ListView kaydırırken performansını artırmak için kullanılır.

ViewHolder tasarım deseni, her bir liste öğesi görünümüne, aramaya gerek kalmadan erişmenizi ve değerli işlemci döngülerini kaydetmenizi sağlar. Özellikle, ListView kaydırma sırasında sık sık findViewById () çağrılarını önler ve bu onu düzgünleştirir.

Tüm bu desenler, MVC, MVVM , MVP ve Sunum Modeli , Android uygulamalarına uygulanabilir, ancak üçüncü taraf bir çerçeve olmadan, iyi organize edilmiş yapı ve temiz kod almak kolay değildir.

MVVM, PresentationModel kaynaklıdır. MVC, MVVM ve Sunum Modeli'ni bir Android uygulamasına uyguladığımızda, gerçekten istediğimiz şey, açık bir yapılandırılmış projeye sahip olmak ve birim testleri için daha da önemlisi daha kolaydır.

Şu anda, üçüncü taraf çerçevesi olmadan, genellikle herhangi bir işletme değeri katmayan çok sayıda kodunuz var (addXXListener (), findViewById () vb.). Dahası, normal JUnit testleri yerine Android birim testlerini çalıştırmanız gerekir; bu, çalıştırmak ve birim testlerini biraz pratik yapmaz.

Bu nedenlerle, birkaç yıl önce , Android platformu için bir veri bağlayıcı Sunum Modeli çerçevesi olan RoboBinding açık kaynaklı bir proje başlattık . RoboBinding, okunması, test edilmesi ve bakımı daha kolay UI kodu yazmanıza yardımcı olur. RoboBinding, addXXListener gibi gereksiz kod gereksinimini ortadan kaldırır ve UI mantığını POJO olan ve normal JUnit testleri ile test edilebilen Sunum Modeline kaydırır . RoboBinding, kalitesini sağlamak için 300'den fazla JUnit testi ile birlikte gelir.

Android Framework'te uygulanmış bir tasarım deseni eklemek istiyorum. Bu, Asynctask uygulamasında kullanılan Half Sync Half Async modelidir. Tartışmamı şurada görün:

https://docs.google.com/document/d/1_zihWXAwgTAdJc013-bOLUHPMrjeUBZnDuPkzMxEEj0/edit?usp=sharing

Android'de "iş kuyruğu işlemcisi" kalıbı genellikle görevleri uygulamanın ana iş parçacığından boşaltmak için kullanılır.

Örnek: IntentService sınıfının tasarımı.

IntentService, Intents'i alır, bir işçi iş parçacığı başlatır ve hizmeti uygun şekilde durdurur.Tüm istekler tek bir iş parçacığı üzerinde işlenir.

Binder, Ölüm Alıcı bildirimleri için "Gözlemci Düzeni" kullanır.