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?
java
android
design-patterns
model-view-controller
Mohit Deshpande
źródło
źródło
Odpowiedzi:
W Androidzie nie masz MVC, ale masz następujące elementy:
źródło
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:
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.
źródło
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.
źródło
Po pewnym przeszukaniu najbardziej rozsądną odpowiedzią jest:
MVC jest już zaimplementowany w systemie Android jako:
Button
pochodneandroid.view.View
.(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.źródło
Button
wiedzy 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 .Service
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.
źródło
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 .
źródło
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.
źródło
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)
źródło
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
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.
źródło
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
źródło
Wzorzec MVC Androida jest (w pewnym sensie) zaimplementowany wraz z klasami adapterów . Zastępują one kontroler „adapterem”. Opis stanów adaptera:
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.
źródło
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.
źródło
Kontroler widoku modelu (MVC)
Opis:
Wzór MVC jest zasadniczo taki:
Ważna cecha MVC: Możemy modyfikować albo model, albo widok albo kontroler, nadal nie wpływając na pozostałe
źródło
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.
źródło
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
czyFragment
?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
iFragment
dostarczenia wymaganych metod tego.W przykładowej aplikacji używanej w tym artykule użyłem
Activity
dla View warstwie, aleFragment
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.
źródło
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.
Przy oddzielnym modelu i kontrolerze wyglądałoby to tak:
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)
źródło
Zgodnie z wyjaśnieniem, które wyjaśnił zespół Xamarin (na iOS MVC „Wiem, że to dziwne, ale poczekaj chwilę”):
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.
źródło
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:
źródło
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.
źródło
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ść.
źródło
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.
źródło