Wzór MVC na Androida

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?

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.

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.

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.

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.

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.

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:

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 .

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.

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)

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

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.

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

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.

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.

Kontroler widoku modelu (MVC)

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

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.

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:

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.

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)

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.

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

Proszę sprawdzić te linki:

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

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

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

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

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

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.

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ść.

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.