Wzór MVC na Androida

497

Czy możliwe jest zaimplementowanie wzorca model-widok-kontroler w Javie dla Androida?

Czy jest to już realizowane za pośrednictwem działań? Czy jest lepszy sposób na wdrożenie wzorca MVC dla Androida?

Mohit Deshpande
źródło
64
Twoje pytanie jest bardzo dobre. Ale moim zdaniem odpowiedź oznaczona jako rozwiązanie jest nieprawidłowa. Może wprowadzić w błąd kilka osób.
Saghar
4
Sprawdź moje 2 posty zaczynające się tutaj Architektura Androida: MV?
Dori,
1
Czy istnieje także dodatkowy zestaw zasad, których należy przestrzegać, aby przestrzegać MVC, czy też rozwój Androida jest już dostosowany do MVC ze względu na aktywność, XML i zasoby?
Flame of udun
3
@Dori, naprawiam twój link: Architektura Androida: MV?
Andreybeta
Ten artykuł dokładnie pasuje do tego, czego szukasz, MVC w Androidzie
Ali Nem

Odpowiedzi:

239

W Androidzie nie masz MVC, ale masz następujące elementy:

  • Interfejs użytkownika definiuje się w różnych plikach XML według rozdzielczości, sprzętu itp.
  • Swoje zasoby definiujesz w różnych plikach XML według ustawień regionalnych itp.
  • Rozszerzyć clases jak ListActivity , TabActivity i skorzystać z pliku XML przez inflaters .
  • Możesz stworzyć dowolną liczbę klas dla swojej logiki biznesowej.
  • Wiele Utils zostało już napisanych dla Ciebie - DatabaseUtils, Html.
Pentium10
źródło
3
@JDPekham, dlaczego mówisz „Nie możesz zainicjować działania bez rozmowy z układem / widokiem”? Tworzenie instancji działania nie wymaga rozmowy z widokami, w rzeczywistości rozmowa z widokami nie jest w żadnym wypadku częścią instancji działania. MOŻESZ (ale nie musisz) wywoływać różne metody aktywności, które wchodzą w interakcje z twoimi widokami, kiedy i jeśli uznasz to za odpowiednie. Drugie pytanie: zakładając, że działanie ma pełnić rolę kontrolera (uważam, że wielu programistów Androida tak to postrzega), dlaczego nie porozmawiać o swoich poglądach z działania?
8
Dla każdego, kto mówi, że „Android to MVC”, spróbuj wypróbować Backbone.js (tak, js po stronie klienta) przez tydzień, a następnie wróć i powiedz, że „Android to MVC”. W końcu zrozumiesz pytanie i dlaczego ciągle pytamy :)
Mark Peterson
14
„W Androidzie nie masz MVC” ???? W Androidzie, podobnie jak w innych językach, masz MVC, jeśli chcesz MVC.
Lorenzo Barbagli
1
@LorenzoBarbagli Ma na myśli, że Android nie wymusza MVC w aplikacjach z założenia (tak jak iOS). Musisz samodzielnie wdrożyć smak MVC, MVP lub czegoś innego, jeśli chcesz osiągnąć to, co zapewnia MVC - a mianowicie rozdzielić obawy i odizolowany, łatwy do przetestowania Model.
Piovezan
Nie. Zdecydowanie istnieje MVC na Androida, ale bardziej domyślnie. Jest po prostu zaimplementowany w inny sposób, zgodnie z tym, jak wszystko Android porządkuje.
6rchid
229

Nie ma uniwersalnie unikalnego wzoru MVC. MVC to koncepcja, a nie solidne środowisko programistyczne. Możesz wdrożyć własne MVC na dowolnej platformie. Tak długo, jak trzymasz się następującego podstawowego pomysłu, wdrażasz MVC:

  • Model: Co renderować
  • Widok: Jak renderować
  • Kontroler: zdarzenia, dane wejściowe użytkownika

Pomyśl też o tym w ten sposób: Kiedy programujesz swój model, model nie powinien martwić się renderowaniem (lub kodem specyficznym dla platformy). Model powiedziałby do widoku: nie dbam o to, czy renderujesz w systemie Android, iOS, Windows Phone, właśnie tego potrzebujesz. Widok obsługuje tylko kod renderowania specyficzny dla platformy.

Jest to szczególnie przydatne, gdy używasz Mono do udostępniania modelu w celu tworzenia aplikacji międzyplatformowych.

Ramon Chan
źródło
12
Chociaż jest to prawda i dobrze powiedziane, jest to teoria, a ludzie są praktyczni!
TWiStErRob
1
@TWiStErRob Ale wzorce projektowe to teoretyczne, abstrakcyjne pomysły, które nie mają tylko jednego sposobu na ich realizację. Głos „Nie chcę rozumieć MVC w teorii, po prostu chcę go wdrożyć” brzmi dla mnie tak, jakby mógł spowodować: „Zamierzam umieścić pralkę w mojej kuchni, ponieważ pralki stosują wzór Cleaner ™ i kuchnie tego potrzebują ”.
Łukasz
1
Myślę, że przykłady są bezcenne, ponieważ pokazują, co wymyślili inni ludzie. Można je ulepszyć i uczyć się na ich wysiłkach. Nie trzeba wszystkich wymyślać koła na nowo. W kontekście Androida i jego złożonego cyklu życia występują problemy, które nie zostały rozwiązane we wzorcu projektowym, ale wszyscy się z nimi zmierzą. Właśnie to miałem na myśli.
TWiStErRob
47

Działania, widoki i działania na Androidzie są upartym sposobem pracy z interfejsem użytkownika Androida i są implementacją wzorca model-widok-widokmodel (MVVM) , który jest strukturalnie podobny (w tej samej rodzinie co) widok modelu -kontroler.

Według mojej najlepszej wiedzy nie ma sposobu na wyrwanie się z tego modelu. Prawdopodobnie można to zrobić, ale prawdopodobnie straciłbyś wszystkie korzyści, które ma istniejący model i musiałbyś przepisać własną warstwę interfejsu użytkownika, aby działała.

Derick Bailey
źródło
29

Po pewnym przeszukaniu najbardziej rozsądną odpowiedzią jest:

MVC jest już zaimplementowany w systemie Android jako:

  1. Widok = układ, zasoby i wbudowane klasy, takie jak Buttonpochodne android.view.View.
  2. Kontroler = aktywność
  3. Model = klasy, które implementują logikę aplikacji

(Nawiasem mówiąc, oznacza to brak logiki domeny aplikacji w działaniu).

Najbardziej rozsądną rzeczą dla małego programisty jest przestrzeganie tego wzorca i nie robienie tego, czego Google nie zdecydowało się zrobić.

PS Zauważ, że Aktywność jest czasem restartowana, więc nie ma w niej miejsca na dane modelu (najłatwiejszym sposobem na ponowne uruchomienie jest pominięcie android:configChanges="keyboardHidden|orientation"kodu XML i włączenie urządzenia).

EDYTOWAĆ

Być może mówimy o MVC , ale tak będzie powiedzieć FMVC , Framework - Model - View - Controller . Framework (Android OS) nakłada swój pomysł składnik cyklu życia i związanych z nimi wydarzeń, aw praktyce Controller ( Activity/ Service/ BroadcastReceiver) jest przede wszystkim odpowiedzialny za radzenie sobie z tymi ramami -imposed zdarzeń (takich jak onCreate () ). Czy dane wejściowe użytkownika powinny być przetwarzane osobno? Nawet jeśli tak, nie można go rozdzielić, zdarzenia wprowadzane przez użytkownika również pochodzą z Androida.

W każdym razie, im mniej kodu, który nie jest specyficzny dla Androida, umieścisz w swoim Activity/ Service/ BroadcastReceiver, tym lepiej.

18446744073709551615
źródło
3
Aktywność ma bezpośredni dostęp do interfejsu użytkownika, natomiast w MVC kontroler nie powinien wiedzieć o widoku (tylko na odwrót).
Konrad Morawski
2
@KonradMorawski Hmmm .... Zobacz wiedząc o wyświetlaniu rzeczy i o kontrolerze ? Dziecko, powiedzmy, Buttonwiedzy o kontrolerze ? Wydaje się bardziej logiczne, że Widoki wiedzą tylko o wyświetlaniu rzeczy. Biorąc pod uwagę, że Model wie tylko o naturze danych, dlatego potrzebny jest Kontroler : coś musi wiedzieć zarówno o Modelu, jak i Widoku .
18446744073709551615
4
Oczywiście widok musi wiedzieć o kontrolerze, aby delegować zdarzenia do kontrolera. Kontroler podąża za nim do modelu i informuje View, jakie były wyniki (aby mógł go wyświetlić). Kontroler nie zawyża widoku (podczas gdy Aktywność), nie powinien też wiedzieć o przyciskach, polach tekstowych, listach itp. (Podczas gdy Aktywność wie).
Konrad Morawski
1
Service
Wydaje
1
Słyszałeś kiedyś o obserwatorach? Najlepsza separacja, jaką dotychczas znaleziono, to gdy 1. kontroler ma tylko instancję modelu, 2. model nie ma wiedzy o kontrolerze lub widoku, ale widok może zarejestrować się jako obserwator modelu (więc model trochę wie o widoku, ale nie wie, kto to jest, a on nie przejmuje się) - kiedy model jest gotowy z ładowaniem danych, powiadamia wszystkich obserwatorów (zwykle 1) i 3. widok ma tylko instancję modelu do wyciągnięcia z niego danych. W ten sposób istnieją tylko 2 zależności dla wszystkich środowisk MVC. Myślę, że 2 to minimum, więc powinien to być najlepszy układ.
Srneczek
18

Nie ma jednego wzoru MVC, którego można by przestrzegać. MVC po prostu stwierdza mniej więcej, że nie należy mieszać danych i widoku, tak że np. Widoki są odpowiedzialne za przechowywanie danych lub klasy, które przetwarzają dane, bezpośrednio wpływają na widok.

Niemniej jednak sposób, w jaki Android radzi sobie z klasami i zasobami, czasami jesteś nawet zmuszony do przestrzegania wzoru MVC. Moim zdaniem bardziej skomplikowane są działania, które czasem odpowiadają za widok, ale jednocześnie działają jako kontroler w tym samym czasie.

Jeśli zdefiniujesz swoje widoki i układy w plikach XML, załaduj zasoby z folderu res, a jeśli unikniesz mniej więcej mieszania tych rzeczy w kodzie, to i tak postępujesz zgodnie ze wzorem MVC.

RoflcoptrException
źródło
14

Możesz wdrożyć MVC w Androidzie, ale nie jest ono „natywnie obsługiwane” i wymaga trochę wysiłku.

To powiedziawszy, osobiście wolę MVP jako znacznie czystszy wzór architektoniczny dla rozwoju Androida. Mówiąc MVP mam na myśli:

wprowadź opis zdjęcia tutaj

Tutaj zamieściłem też bardziej szczegółową odpowiedź .

Po zabawie różnymi podejściami do implementacji MVC / MVP w Androidzie wpadłem na rozsądny wzorzec architektoniczny, który opisałem w tym poście: MVP i MVC Architectural Patterns w Androidzie .

Wasilij
źródło
14

Najlepszym zasobem, jaki znalazłem do wdrożenia MVC na Androida, jest ten post :

Wykonałem ten sam projekt dla jednego z moich projektów i zadziałało świetnie. Jestem początkującym na Androidzie, więc nie mogę powiedzieć, że to najlepsze rozwiązanie.

Dokonałem jednej modyfikacji: utworzyłem instancję modelu i kontrolera dla każdej aktywności w klasie aplikacji, aby nie były one odtwarzane po zmianie trybu portretowego.

Hervé Donner
źródło
8
byłoby wspaniale uzyskać podsumowanie na wypadek, gdyby pewnego dnia artykuł został usunięty.
pqsk
12

Zgadzam się z JDPeckham i uważam, że sam XML nie wystarcza do wdrożenia części interfejsu użytkownika aplikacji.

Jeśli jednak weźmiesz pod uwagę działanie jako część widoku, wdrożenie MVC jest dość proste. Możesz zastąpić aplikację (zwróconą przez getApplication () w działaniu) i tutaj możesz utworzyć kontroler, który przetrwa przez cały okres użytkowania aplikacji.

(Alternatywnie możesz użyć wzorca singletonu, jak sugeruje dokumentacja aplikacji)

kaczka do pisania
źródło
12

Architektura MVC na Androida Lepiej podążać za każdym MVP zamiast MVC w Androidzie . Ale nadal zgodnie z odpowiedzią na pytanie może to być rozwiązanie

Wpisz opis zdjęcia tutaj

Opis i wytyczne

     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

NOTATKA 1:

Oto kawałek magii, który możesz zrobić. Po sklasyfikowaniu fragmentu kodu napisz podstawową klasę interfejsu, taką jak IEntity i IService. Zadeklaruj wspólne metody. Teraz utwórz abstrakcyjną klasę BaseService i zadeklaruj własny zestaw metod oraz rozdziel kod.

UWAGA 2: Jeśli Twoja aktywność przedstawia wiele modeli, zamiast pisać kod / logikę w działaniu, lepiej podzielić widoki na fragmenty. To jest lepsze. Jeśli więc w przyszłości będzie potrzebny więcej modelu, aby wyświetlić go w widoku, dodaj jeszcze jeden fragment.

UWAGA 3: Oddzielenie kodu jest bardzo ważne. Każdy komponent architektury powinien być niezależny i nie mieć zależnej logiki. Jeśli przypadkiem masz logikę zależną, napisz między nimi klasę logiki mapowania. Pomoże Ci to w przyszłości.

DropAndTrap
źródło
11

Tworzenie interfejsu użytkownika Android przy użyciu układów, zasobów, działań i zamiarów jest implementacją wzorca MVC. Więcej informacji na ten temat można znaleźć pod następującym linkiem - http://www.cs.otago.ac.nz/cosc346/labs/COSC346-lab2.2up.pdf

lustro do pliku pdf

Arunabh Das
źródło
7
link jest zerwany, proszę pana
Rat-a-tat-a-tat Ratatouille,
2
Wygląda na to, że ten plik COSC346-lab2.2up.pdf nie zawiera pełnych szczegółów.
James
9

Wzorzec MVC Androida jest (w pewnym sensie) zaimplementowany wraz z klasami adapterów . Zastępują one kontroler „adapterem”. Opis stanów adaptera:

Obiekt Adapter działa jako pomost między AdapterView a danymi bazowymi dla tego widoku.

Właśnie patrzę na to dla aplikacji na Androida, która czyta z bazy danych, więc nie wiem jeszcze, jak dobrze to działa. Wygląda jednak trochę podobnie do architektury Model-View-Delegate Qt, która, jak twierdzą, jest krokiem w górę od tradycyjnego wzorca MVC. Przynajmniej na PC wzór Qt działa całkiem dobrze.

Ben
źródło
9

Chociaż ten post wydaje się stary, chciałbym dodać następujące dwa, aby poinformować o najnowszym rozwoju w tym obszarze dla Androida:

Android-binding - Udostępnianie frameworku umożliwiającego powiązanie widgetów widoku Androida z modelem danych. Pomaga implementować wzorce MVC lub MVVM w aplikacjach na Androida.

roboguice - RoboGuice eliminuje zgadywanie z rozwoju. Wstrzyknij swój widok, zasób, usługę systemową lub inny obiekt i pozwól RoboGuice zająć się szczegółami.

Mahendra Liya
źródło
9

Kontroler widoku modelu (MVC)

wprowadź opis zdjęcia tutaj


Opis:

  • Kiedy musimy opracowywać duże projekty przy tworzeniu oprogramowania, MVC jest powszechnie stosowane, ponieważ jest to uniwersalny sposób organizowania projektów.
  • Nowi programiści mogą szybko dostosować się do projektu
  • Pomaga w rozwoju dużych projektów i platform.

Wzór MVC jest zasadniczo taki:

  • Model: Co wyświetlić. Może to być źródło danych (np. Serwer, surowe dane w aplikacji)
  • Widok: jak to jest wyświetlane. Może to być xml. Działa zatem jako filtr prezentacji. Widok jest dołączony do jego modelu (lub części modelu) i pobiera dane niezbędne do prezentacji.
  • Kontroler: obsługa zdarzeń takich jak dane wejściowe użytkownika. To będzie aktywność

Ważna cecha MVC: Możemy modyfikować albo model, albo widok albo kontroler, nadal nie wpływając na pozostałe

  • Powiedzmy, że zmieniamy kolor w widoku, rozmiar widoku lub pozycję widoku. W ten sposób nie wpłynie to na model ani kontroler
  • Powiedzmy, że zmieniamy model (zamiast danych pobieranych z serwera pobieramy dane z zasobów), to nie wpłynie to na widok i kontroler
  • Powiedzmy, że zmienimy kontroler (logika w działaniu), nie wpłynie to na model i widok
Devrath
źródło
2
Użyłem tylko kontrolera jako przewodnika dla sposobu wyświetlania / modelowania informacji o przekaźniku. Jestem ciekawy, jak masz model i widok w bezpośrednim kontakcie ze sobą. Czy masz źródło lub przykład tej implementacji?
Jacksonkr,
7

Myślę, że najbardziej przydatne uproszczone wyjaśnienie znajduje się tutaj: http://www.cs.otago.ac.nz/cosc346/labs/COSC346-lab2.2up.pdf

Ze wszystkiego, co tu widziałem i czytałem, wdrażanie tych wszystkich rzeczy utrudnia i nie pasuje dobrze do innych części Androida.

Posiadanie działania implementującego innych słuchaczy jest już standardowym sposobem na Androida. Najbardziej nieszkodliwym sposobem byłoby dodanie Java Observera, tak jak slajdy opisują i grupują onClick i inne typy akcji w funkcje, które są nadal w działaniu.

W Androidzie działanie polega na obu tych działaniach. Walka z nim tak naprawdę nie ułatwia rozszerzania ani robienia przyszłych kodowań.

Zgadzam się z drugim postem . To jest już zaimplementowane, ale nie tak, jak ludzie są przyzwyczajeni. Niezależnie od tego, czy znajduje się w tym samym pliku, czy nie, istnieje już separacja. Nie ma potrzeby tworzenia dodatkowej separacji, aby dopasować ją do innych języków i systemów operacyjnych.

Edmund Chang
źródło
6
Podany link jest uszkodzony.
mmBs
6

Zaskakujące było, że żaden z postów tutaj nie odpowiedział na pytanie. Są albo zbyt ogólne, niejasne, niepoprawne, albo nie dotyczą implementacji w Androidzie.

W MVC warstwa widoku wie tylko, jak wyświetlić interfejs użytkownika (UI). Jeśli do tego potrzebne są jakieś dane, pobiera je z warstwy Model . Ale widok NIE prosi bezpośrednio modelu o znalezienie danych, robi to poprzez kontroler . Tak więc kontroler  wywołuje model, aby podać wymagane dane do widoku . Gdy dane są gotowe, Administrator informuje Widok, że dane są gotowe do pobrania z Modelu . Teraz widok może uzyskać dane z modelu .

Ten przepływ można podsumować jak poniżej:

wprowadź opis zdjęcia tutaj

Warto zauważyć, że widok może wiedzieć o dostępności danych w  Modelu  albo przez kontroler - znany również jako  Pasywny MVC - lub obserwując dane w Modelu , rejestrując w nim obserwowalne, czyli Active MVC .

Jeśli chodzi o implementację, jedną z pierwszych rzeczy, które przychodzą na myśl, jest to, który komponent Androida powinien zostać użyty w Widoku ? Activity  czy Fragment ?

Odpowiedź jest taka, że ​​nie ma to znaczenia i oba mogą być używane. Zobacz powinien być w stanie przedstawić interfejs użytkownika (UI) na urządzeniu lub napisania odpowiedzi na interakcję użytkownika z interfejsu użytkownika. Zarówno Activity  i Fragment  dostarczenia wymaganych metod tego.

W przykładowej aplikacji używanej w tym artykule użyłem Activity dla View warstwie, ale Fragment  może być również używany.

Kompletną przykładową aplikację można znaleźć w gałęzi „mvc” mojego repozytorium GitHub tutaj .

Miałem również do czynienia z zaletami i wadami architektury MVC w Androidzie na przykładzie tutaj .

Dla zainteresowanych rozpocząłem serię artykułów na temat architektury aplikacji na Androida , w których porównuję różne architektury, tj. MVC, MVP, MVVM, dla rozwoju aplikacji na Androida za pośrednictwem kompletnej działającej aplikacji.

Ali Nem
źródło
Wziąłem kurs architektury, w którym instruktor stwierdza, że ​​działania i fragmenty nie powinny być używane jako widoki, a tak naprawdę powinny być kontrolerami, a widoki powinny być osobnymi plikami. Czy masz jakieś zdanie lub uzasadnienie, dlaczego tak nie powinno być?
brandonx,
Nie sądzę, żeby instruktor był w tym dokładny. Wybór działania lub fragmentu jako kontrolera oznacza przekazanie kontekstu do kontrolera. Z drugiej strony widok potrzebuje również kontekstu do rysowania na ekranie. W ten sposób, tj. Przekazując kontekst do kontrolera, aplikacja jest podatna na wyciek pamięci i uważam, że kontroler nie powinien przenosić stanu.
Ali Nem
5

Zmęczony katastrofą MVx na Androidzie stworzyłem niedawno małą bibliotekę, która zapewnia jednokierunkowy przepływ danych i jest podobna do koncepcji MVC: https://github.com/zserge/anvil

Zasadniczo masz komponent (aktywność, fragment i grupę widoków). Wewnątrz określasz strukturę i styl warstwy widoku. Ty również określasz, w jaki sposób dane powinny być powiązane z widokami. Wreszcie możesz powiązać słuchaczy w tym samym miejscu.

Następnie, po zmianie danych - zostanie wywołana globalna metoda „render ()”, a twoje widoki zostaną inteligentnie zaktualizowane o najnowsze dane.

Oto przykład komponentu, który ma wszystko w środku dla zwięzłości kodu (oczywiście Model i Kontroler można łatwo oddzielić). Tutaj „count” to model, metoda view () to widok, a „v -> count ++” to kontroler, który nasłuchuje kliknięć przycisku i aktualizuje model.

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
      });
    });
  }

Przy oddzielnym modelu i kontrolerze wyglądałoby to tak:

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

Tutaj na każdym kliknięciu przycisku liczba zostanie zwiększona, następnie zostanie wywołane „render ()”, a tekst przycisku zostanie zaktualizowany.

Składnia staje się przyjemniejsza, jeśli używasz Kotlin: http://zserge.com/blog/anvil-kotlin.html . Istnieje także alternatywna składnia Java bez lambd.

Sama biblioteka jest bardzo lekka, nie ma zależności, nie używa odbicia itp.

(Oświadczenie: Jestem autorem tej biblioteki)

zserge
źródło
4

Zgodnie z wyjaśnieniem, które wyjaśnił zespół Xamarin (na iOS MVC „Wiem, że to dziwne, ale poczekaj chwilę”):

  • Model (logika danych lub aplikacji),
  • Widok (interfejs użytkownika) i
  • Kontroler (kod z tyłu).

Mogę powiedzieć:

Model na Androidzie to po prostu obiekt do paczkowania. Widok jest układem XML, a kontrolerem jest (działanie + jego fragment).

* To tylko moja opinia, nie z żadnego zasobu lub książki.

zaPlayer
źródło
4

Nie ma zaimplementowanej architektury MVC, ale istnieje zestaw bibliotek / przykładów do implementacji architektury MVP (model-widok-prezenter).

Proszę sprawdzić te linki:

Google dodał przykład architektury MVP dla architektury Androida:

carlos.baez
źródło
3

Widziałem, że wiele osób twierdzi, że MVC jest już zaimplementowane w Androidzie, ale to nieprawda. Android domyślnie nie stosuje MVC.

Ponieważ nie robię tego Google, nigdy nie narzucę na siłę ograniczeń implementacji MVC, takich jak iPhone, ale zależy to od programistów, których wzorów lub techniki chcą w swoim projekcie. W małych lub prostych aplikacjach użycie MVC nie jest wymagane, ale jako aplikacja rośnie i komplikuje się i wymaga modyfikacji kodu w późniejszych latach, potem pojawia się potrzeba wzorca MVC w Androidzie.

Zapewnia łatwy sposób modyfikowania kodu, a także pomaga w ograniczeniu problemów. Jeśli chcesz wdrożyć MVC na Androida, skorzystaj z poniższego linku i ciesz się implementacją MVC w swoim projekcie.

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

Ale obecnie myślę, że MVP wraz z Androidem Architectural Pattern to jedna z najlepszych opcji, którą programiści powinni użyć dla czystych i niezawodnych aplikacji na Androida.

Szczęśliwa Rana
źródło
1
Zgoda. Android ma wystarczającą elastyczność, aby się powiesić. Ta aktywność może szybko stać się gigantyczna i skomplikowana, ponieważ obsługuje wszystkie trzy aspekty MVC.
Scott Biggs,
2

Kiedy stosujemy MVC, MVVM lub Model prezentacji w aplikacji na Androida, naprawdę chcemy mieć przejrzysty projekt i, co ważniejsze, testy jednostkowe.

W tej chwili, bez frameworka frameworka, zwykle masz dużo kodu (jak addXXListener (), findViewById () itp.), Co nie dodaje żadnej wartości biznesowej.

Co więcej, musisz przeprowadzić testy jednostkowe Androida zamiast normalnych testów JUnit, których uruchomienie zajmuje wiele lat i sprawia, że ​​testy jednostkowe są nieco niepraktyczne. Z tych powodów kilka lat temu rozpoczęliśmy projekt Open Source, RoboBinding - model prezentacyjny wiążący dane dla platformy Android.

RoboBinding pomaga pisać kod interfejsu użytkownika, który jest łatwiejszy do odczytania, przetestowania i utrzymania. RoboBinding eliminuje potrzebę niepotrzebnego kodu, takiego jak addXXListener , i przesuwa logikę interfejsu użytkownika do Presentation Model, który jest POJO i może być testowany za pomocą normalnych testów JUnit . Sam RoboBinding zawiera ponad 300 testów JUnit, aby zapewnić jego jakość.

Cheng
źródło
1

W moim rozumieniu sposób, w jaki Android obsługuje wzorzec MVC, wygląda następująco:

Masz działanie, które służy jako kontroler. Masz klasę, której obowiązkiem jest uzyskanie danych - model, a następnie masz klasę View, która jest widokiem.

Mówiąc o widoku większość ludzi myśli tylko za jego część wizualną zdefiniowaną w xml. Nie zapominajmy, że widok ma również część programu z jego konstruktorami, metodami itp., Zdefiniowanymi w klasie java.

Rados
źródło