Android'de MVC deseni

Android için Java'da model-görünüm-denetleyici desenini uygulamak mümkün müdür?

Yoksa zaten Etkinlikler aracılığıyla mı uygulanıyor? Yoksa Android için MVC modelini uygulamanın daha iyi bir yolu var mı?

Android'de MVC'niz yok, ancak aşağıdakilere sahipsiniz:

• Sen tanımla Kullanıcı arayüzünüzü çeşitli XML dosyalarında çözünürlük, donanım vb. .
• Sen tanımla Kaynaklarınızı çeşitli XML dosyalarında yerel ayarlara vb. Göre .
• ListActivity , TabActivity gibi sınıfları genişletiyorsunuz ve XML dosyasını inflaters tarafından kullanırsınız .
• İş mantığınız için istediğiniz kadar sınıf oluşturabilirsiniz.
• Birçok Utils sizin için zaten yazılmıştır - DatabaseUtils, Html.

Evrensel olarak eşsiz bir MVC modeli yoktur. MVC sağlam bir programlama çerçevesinden çok bir kavramdır. Kendi MVC'nizi herhangi bir platformda uygulayabilirsiniz. Aşağıdaki temel fikre bağlı kaldığınız sürece MVC uyguluyorsunuz:

• Model: Ne yapılır?
• Görünüm: Nasıl oluşturulur?
• Denetleyici: Olaylar, kullanıcı girişi

Ayrıca bu şekilde düşünün: Modelinizi programladığınızda, modelin oluşturma (veya platforma özgü kod) hakkında endişelenmesi gerekmez. Model görünüme göre derdi, renderınızın Android mi yoksa iOS mu yoksa Windows Phone mu olduğunu umursamıyorum. Görünüm yalnızca platforma özgü oluşturma kodunu işleyecektir.

Bu, özellikle platformlar arası uygulamalar geliştirmek amacıyla modeli paylaşmak için Mono kullandığınızda kullanışlıdır .

Android'deki eylemler, görünümler ve etkinlikler, Android kullanıcı arayüzüyle çalışma biçimindedir ve model-görünüm-görünüm modeli (MVVM) modelinin bir uygulamasıdır. yapısal olarak benzer (aynı ailede) model görünümü olan -controller.

Bildiğim kadarıyla, bu modelden kurtulmanın bir yolu yok. Muhtemelen yapılabilir, ancak mevcut modelin sahip olduğu tüm avantajı kaybedersiniz ve çalışması için kendi UI katmanınızı yeniden yazmanız gerekir.

Bazı aramalardan sonra, en makul cevap şudur:

MVC zaten Android'de şu şekilde uygulanmaktadır:

1. View = düzen, kaynaklar ve Buttontüretilmiş sınıflarandroid.view.View .
2. Kontrolör = Etkinlik
3. Model = uygulama mantığını uygulayan sınıflar

(Bu arada, etkinlikte hiçbir uygulama etki alanı mantığı anlamına gelmez.)

Küçük bir geliştirici için en makul şey, bu modeli takip etmek ve Google'ın yapmamaya karar verdiklerini yapmaya çalışmaktır.

Not Etkinlik bazen yeniden başlatılır, bu nedenle model verileri için bir yer yoktur (yeniden başlatmanın en kolay yolu android:configChanges="keyboardHidden|orientation"XML'den atlayıp cihazınızı çevirmektir).

DÜZENLE

Biz bahsediyoruz olabilir MVC , ancak bunu söylemek olacak FMVC , Framework - Model - Görünüm - Kontrolörü . Çerçeve (Android işletim sistemi) bileşeni yaşam döngüsü ve ilgili olayların onun fikrini dayattığı ve pratikte Denetleyici ( Activity/ Service/ BroadcastReceiver), bu mücadeleye yardım amaçlı her şeyden önce sorumlu taşımaktadır Çerçeve gibi olayları (empoze edilen ) (onCreate ). Kullanıcı girişi ayrı olarak işlenmeli mi? Gerekirse bile ayıramazsınız, kullanıcı giriş olayları da Android'den geliyor.

Her neyse, Activity/ Service/ içine Android'e özgü olmayan kod ne kadar az olursa o BroadcastReceiverkadar iyidir.

Uymanız gereken tek bir MVC modeli yoktur. MVC, veri ve görünümü karıştırmamanız gerektiğini az çok belirtir, böylece örneğin veriyi tutmaktan görünümler sorumludur veya verileri işleyen sınıflar görünümü doğrudan etkiler.

Ancak yine de, Android'in sınıflar ve kaynaklarla ilgilenme şekli, bazen MVC modelini takip etmek zorunda kalırsınız. Kanımca daha karmaşık olan, bazen görüşten sorumlu olan, ancak yine de aynı zamanda bir denetleyici olarak hareket eden faaliyetlerdir.

XML dosyalarındaki görünümlerinizi ve mizanpajlarınızı tanımlarsanız, kaynaklarınızı res klasöründen yükleyin ve kodunuzda bu şeyleri karıştırmak için az ya da çok kaçınıyorsanız, yine de bir MVC kalıbını takip edersiniz.

MVC'yi Android'de uygulayabilirsiniz, ancak "yerel olarak desteklenmez" ve biraz çaba gerektirir.

Bununla birlikte, kişisel olarak Android geliştirme için daha temiz bir mimari desen olarak MVP'ye yöneliyorum . Ve MVP diyerek şunu kastediyorum:

Ayrıca burada daha ayrıntılı bir cevap gönderdim .

Android'de MVC / MVP uygulamasına çeşitli yaklaşımlarla oynadıktan sonra, bu yazıda tanımladığım makul bir mimari desen buldum: Android'de MVP ve MVC Mimari Desenler .

Android'de MVC uygulamak için bulduğum en iyi kaynak bu yazıdır :

Projelerimden biri için aynı tasarımı takip ettim ve harika çalıştı. Android'de yeni başlayan biriyim, bu yüzden bunun en iyi çözüm olduğunu söyleyemem.

Bir değişiklik yaptım: Model ve denetleyiciyi uygulama sınıfındaki her etkinlik için başlattım, böylece yatay portre modu değiştiğinde bunlar yeniden oluşturulmaz.

JDPeckham'a katılıyorum ve tek başına XML'nin bir uygulamanın UI bölümünü uygulamak için yeterli olmadığına inanıyorum.

Ancak, Etkinliği görünümün bir parçası olarak görürseniz MVC'nin uygulanması oldukça basittir. Uygulamayı geçersiz kılabilirsiniz (Etkinlik'te getApplication () tarafından döndürüldüğü gibi) ve burada uygulamanızın ömrü boyunca hayatta kalan bir denetleyici oluşturabilirsiniz.

(Alternatif olarak, Uygulama belgelerinde önerilen tekli kalıbı kullanabilirsiniz)

Android MVC- Mimari Android MVC yerine MVP Takip Daha İyi. Ama yine de sorunun cevabına göre bu çözüm olabilir

Açıklama ve Yönergeler

     Controller -
        Activity can play the role.
        Use an application class to write the
        global methods and define, and avoid
        static variables in the controller label
    Model -
        Entity like - user, Product, and Customer class.
    View -
        XML layout files.
    ViewModel -
        Class with like CartItem and owner
        models with multiple class properties
    Service -
        DataService- All the tables which have logic
        to get the data to bind the models - UserTable,
        CustomerTable
        NetworkService - Service logic binds the
        logic with network call - Login Service
Helpers -
        StringHelper, ValidationHelper static
        methods for helping format and validation code.
SharedView - fragmets or shared views from the code
        can be separated here

AppConstant -
        Use the Values folder XML files
        for constant app level

NOT 1:

Şimdi burada yapabileceğiniz bir sihir parçası var. Kod parçasını sınıflandırdıktan sonra IEntity ve IService gibi bir temel arayüz sınıfı yazın. Ortak yöntemleri beyan edin. Şimdi soyut sınıf BaseService oluşturun ve kendi yöntemler kümesi ilan ve kod ayırma var.

NOT 2: Etkinliğiniz, kodu / mantığı etkinliğe yazmak yerine birden çok model sunuyorsa, görünümleri parçalara bölmek daha iyidir. O zaman daha iyi. Gelecekte, görünümde görünmesi için başka bir modele ihtiyaç duyulursa, bir parça daha ekleyin.

NOT 3: Kodların ayrılması çok önemlidir. Mimarideki her bileşen bağımlı bir mantığa sahip olmamaktan bağımsız olmalıdır. Şans eseri bağımlı bir mantığınız varsa, aralarına bir eşleme mantığı sınıfı yazın. Bu gelecekte size yardımcı olacaktır.

Düzenler, kaynaklar, etkinlikler ve hedefler kullanarak Android UI oluşturma, MVC modelinin bir uygulamasıdır. Bununla ilgili daha fazla bilgi için lütfen aşağıdaki bağlantıya bakın - http://www.cs.otago.ac.nz/cosc346/labs/COSC346-lab2.2up.pdf

pdf için ayna

Android'in MVC kalıbı, Adaptör sınıflarıyla birlikte uygulanmaktadır . Bir denetleyiciyi "adaptör" ile değiştirirler. Adaptör açıklamaları:

Bir Bağdaştırıcı nesnesi, o görünüm için bir BağdaştırıcıGörünümü ve temel veriler arasında bir köprü görevi görür.

Ben sadece bir veritabanından okuyan bir Android uygulaması için bakıyorum, bu yüzden henüz ne kadar iyi çalıştığını bilmiyorum. Bununla birlikte, Qt'nin Model-View-Delegate mimarisine biraz benziyor, ki bu geleneksel bir MVC modelinden bir adım önde. En azından bilgisayarda, Qt'nin deseni oldukça iyi çalışıyor.

Bu yazı eski gibi görünse de, Android için bu alandaki son gelişmeler hakkında bilgi vermek için aşağıdaki ikisini eklemek istiyorum:

android-ciltleme - android görünüm widget'larının veri modeline bağlanmasını sağlayan bir çerçeve sağlar. Android uygulamalarında MVC veya MVVM kalıplarının uygulanmasına yardımcı olur.

roboguice - RoboGuice tahmin çalışmalarını geliştirme sürecinden çıkarır. Görünümünüzü, Kaynağınızı, Sistem Hizmetinizi veya başka bir nesneyi enjekte edin ve RoboGuice'in ayrıntılarla ilgilenmesine izin verin.

Model Görünümü Denetleyicisi (MVC)

Açıklama:

• Yazılım geliştirmede büyük projeleri yürütmemiz gerektiğinde, MVC genellikle projeleri organize etmenin evrensel bir yolu olduğu için kullanılır.
• Yeni geliştiriciler hızlı bir şekilde projeye uyum sağlayabilir
• Büyük projelerin ve çapraz platformun geliştirilmesine de yardımcı olur.

MVC modeli esas olarak şudur:

• Model: Ne gösterilecek. Bu veri kaynağı olabilir (Örn: Sunucu, Uygulamadaki ham veriler)
• Görünüm: Nasıl görüntülenir. Bu xml olabilir. Bu nedenle bir sunum filtresi görevi görür. Bir görünüm modeline (veya model kısmına) eklenir ve sunum için gerekli verileri alır.
• Denetleyici: Kullanıcı girişi gibi olayları işleme. Bu etkinlik

MVC'nin önemli özelliği: Modeli veya Görünümü veya Denetleyiciyi hala diğerini etkilemeyen modifiye edebiliriz

• Görünümdeki rengi, görünümün boyutunu veya görünümün konumunu değiştirdiğimizi varsayalım. Bunu yapmak, modeli veya kontrolörü etkilemez
• Modeli değiştirdiğimizi varsayalım (sunucudan getirilen veriler yerine varlıklardan veri alır) yine de görünümü ve denetleyiciyi etkilemez
• Denetleyiciyi (etkinlikte mantık) değiştirdiğimizi varsayalım, modeli ve görünümü etkilemez

Bence en kullanışlı basitleştirilmiş açıklama burada: http://www.cs.otago.ac.nz/cosc346/labs/COSC346-lab2.2up.pdf

Burada gördüğüm ve okuduğum her şeyden, tüm bunları uygulamak zorlaştırıyor ve android'in diğer kısımlarına iyi uymuyor.

Diğer dinleyicileri uygulamak için bir etkinliğe sahip olmak zaten standart Android yoludur. En zararsız yol, Java Observer'ı slaytların tanımladığı gibi eklemek ve onClick'i ve diğer eylem türlerini hala Aktivitedeki işlevlere gruplandırmaktır.

Android yolu, Etkinliğin her ikisini de yapmasıdır. Bununla mücadele etmek, kodlamayı genişletmeyi veya gelecekteki kodlamayı daha kolay hale getirmez.

2. gönderiye katılıyorum . Bu zaten uygulandı, insanların alışma şekli değil. Aynı dosyada olsun ya da olmasın, zaten ayrılık var. Diğer dillere ve işletim sistemlerine uyması için ekstra bir ayırma oluşturmaya gerek yoktur.

Buradaki gönderilerin hiçbirinin soruyu yanıtlamadığını görmek şaşırtıcıydı. Çok genel, belirsiz, yanlış veya android uygulamasına hitap etmiyorlar.

MVC'de, Görünüm katmanı yalnızca kullanıcı arabiriminin (UI) nasıl gösterileceğini bilir. Bunun için herhangi bir veri gerekiyorsa, Model katmanından alır. Ancak Görünüm doğrudan modelden verileri bulmasını istemez, bunu Denetleyici aracılığıyla yapar . Böylece Denetleyici , Görünüm için gerekli verileri sağlamak  üzere Modeli çağırır . Veri hazır olduğunda, Kontrolör bilgilendirir Görünüm veri elde edilmeye hazır olduğunu Modeli . Artık Görünüm , Modelden veri alabilir .

Bu akış aşağıdaki gibi özetlenebilir:

Bu fazlalaştı Görünüm verilerin kullanılabilirliği hakkında bilebilir  Modeli  aracılığıyla ya Kontrolörü olarak da bilinen -  Pasif MVC veya veri gözlemleyerek - Model olup buna gözlenebilirleri kaydederek, Aktif MVC .

Uygulama kısmında, akla gelen ilk şeylerden biri, Görünüm için hangi android bileşeninin kullanılması gerektiğidir ? Activity  veya Fragment ?

Cevap önemli değil ve her ikisi de kullanılabilir. Görünüm UI ile kullanıcı etkileşimi için cihaz ve yanıt verdiğini kullanıcı arayüzü (UI) sunmak gerekir. Her ikisi de Activity  ve bunun Fragment  için gerekli yöntemleri sağlar.

Kullanılan örnek uygulamasında bu makalede ben kullandım Activity için Görünüm tabakasının ama Fragment  aynı zamanda kullanılabilir.

Benim GitHub Repo tam örneği uygulaması 'mvc' dalında bulunabilir burada .

Ayrıca burada bir örnek ile android MVC mimarisinin artılarını ve eksilerini ele .

İlgilenenler için, burada tam bir çalışma uygulaması aracılığıyla android uygulama geliştirme için farklı mimarileri, yani MVC, MVP, MVVM, karşılaştırmak android uygulama mimarisi hakkında bir dizi makale başlattık .

Android'de MVx felaketinden bıktım Son zamanlarda tek yönlü veri akışı sağlayan ve MVC kavramına benzeyen küçük bir kütüphane yaptım: https://github.com/zserge/anvil

Temel olarak, bir bileşene (aktivite, parça ve görünüm grubu) sahipsiniz. İçinde görünüm katmanının yapısını ve stilini tanımlarsınız. Ayrıca verilerin görünümlere nasıl bağlanması gerektiğini de tanımlarsınız. Son olarak, dinleyicileri aynı yere bağlayabilirsiniz.

Daha sonra, verileriniz değiştirildiğinde - global "render ()" yöntemi çağrılır ve görünümleriniz en son verilerle akıllıca güncellenir.

Kod kompaktlığı için içeride her şeye sahip olan bileşene bir örnek (tabii ki Model ve Denetleyici kolayca ayrılabilir). Burada "count" bir model, view () yöntemi bir görünümdür ve "v -> count ++" düğmeyi tıklayan ve modeli güncelleyen bir kontrolördür.

public MyView extends RenderableView {
  public MyView(Context c) {
      super(c);
  }

  private int count = 0;

  public void view() {
    frameLayout(() -> {              // Define your view hierarchy
      size(FILL, WRAP);
      button(() -> {
          textColor(Color.RED);      // Define view style
          text("Clicked " + count);  // Bind data
          onClick(v -> count++);     // Bind listeners
      });
    });
  }

Ayrılmış model ve denetleyici ile şöyle görünecektir:

button(() -> {
   textColor(Color.RED);
   text("Clicked " + mModel.getClickCount());
   onClick(mController::onButtonClicked);
});

Burada her bir düğmeye tıklandığında sayı artacak, daha sonra "render ()" çağırılacak ve düğme metni güncellenecektir.

Kotlin kullanıyorsanız sözdizimi daha hoş olur: http://zserge.com/blog/anvil-kotlin.html . Ayrıca, lambdas içermeyen Java için alternatif sözdizimi vardır.

Kütüphanenin kendisi çok hafiftir, bağımlılığı yoktur, yansıma kullanmaz vb.

(Feragatname: Bu kütüphanenin yazarıyım)

Xamarin ekibinin açıkladığı açıklamaya göre (iOS MVC'de "garip görünüyor, ama bir saniye bekleyin"):

• Model (veri veya uygulama mantığı),
• Görünüm (kullanıcı arayüzü) ve
• Denetleyici (arkadaki kod).

Bunu söyleyebilirim:

Android'deki model basitçe parçalanabilir bir nesnedir. Görünüm XML mizanpajı ve denetleyici (etkinlik + parçası) şeklindedir.

* Bu sadece benim fikrim, herhangi bir kaynak veya kitaptan değil.

Uygulanan bir MVC mimarisi yoktur, ancak bir MVP (model-görünüm-sunucu) mimarisini uygulamak için bir dizi kütüphane / örnek bulunmaktadır.

Lütfen şu bağlantıları kontrol edin:

• https://github.com/sockeqwe/mosby

• https://github.com/android10/Android-CleanArchitecture

• https://github.com/antoniolg/androidmvp

Google, bir Android mimarisi MVP'sine bir örnek ekledi:

• https://github.com/googlesamples/android-architecture

Birçok insanın MVC'nin Android'de zaten uygulandığını söylediğini gördüm, ancak bu doğru değil. Android varsayılan olarak hiçbir MVC'yi takip etmez.

Google, iPhone gibi bir MVC uygulamasının kısıtlamalarını zorla uygulayamayacağımdan, projelerinde istedikleri patteren veya tekniği geliştiricilere kadar, küçük veya basit uygulamalarda MVC kullanımı gerekli değildir, ancak uygulama olarak büyür ve karmaşıklaşır ve sonraki yıllarda kodunun değiştirilmesini gerektirir, daha sonra Android'de MVC modeline ihtiyaç vardır.

Kodu değiştirmek için kolay bir yol sağlar ve sorunların azaltılmasına yardımcı olur. MVC'yi Android'de uygulamak istiyorsanız, aşağıdaki bağlantıyı takip edin ve projenizde MVC uygulamasının tadını çıkarın.

http://www.therealjoshua.com/2011/11/android-architecture-part-1-intro/

Ancak günümüzde MVP'nin Android Architectural Pattern ile birlikte geliştiricilerin temiz ve sağlam bir android uygulamaları için kullanması gereken en iyi seçeneklerden biri olduğunu düşünüyorum.

MVC, MVVM veya Sunum Modeli uyguladığımızda Android uygulamasına 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 kaynak kodlu 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 Modeli'ne kaydırır . RoboBinding, kalitesini sağlamak için 300'den fazla JUnit testi ile birlikte gelir.

Anladığım kadarıyla, Android'in MVC modelini işleme şekli şöyle:

Denetleyici olarak hizmet veren bir Etkinliğiniz var. Verileri almak için sorumluluğu olan bir sınıfınız var - model ve sonra görünüm olan View sınıfınız var.

Görünüm hakkında konuşurken çoğu insan sadece xml'de tanımlanan görsel kısmı için düşünür. Görünümün java sınıfında tanımlanan yapıcıları, yöntemleri vb. İle de bir program parçası olduğunu unutmayalım.