You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
`MVI` (ang. `Model-View-Intent`) (wzorzec architektoniczny) usprawnia proces tworzenia i rozwijania aplikacji pisanych przy użyciu programowania reaktywnego poprzez wyróżnienie podziału odpowiedzialności pomiędzy trzy podmioty: widoku (`View`), modelu (`Model`) i intencji (`Intent`). Wzorzec ten jest w pewnym sensie pochodną `MVP` i `MVVM` dostosowaną do `programowania reaktywnego`. Eliminuje użycie metod zwrotnych (`callback`) oraz znacznie redukuje ilość metod wejście/wyjście (`input/output`). Jest także odpowiedzią na pojawiający się problem synchronizacji i rozbieżności przyjmowanych stanów przez warstwę widoku i logiki biznesowej wynikający z faktu iż stan jest sterowany przez warstwę `Presenter` lub `ViewModel`. W efekcie może prowadzić to do nieoczekiwanych zachowań i trudności w ich przewidzeniu oraz utrudnić debugowanie. `MVI` opiera się cyklicznym i jednokierunkowym przepływie oraz na istnieniu jednego niezmiennego (`immutable`) stanu wspólnego dla wszystkich warstw jako jedynego źródła prawdy. Rolę reprezentanta stanu przyjmuje model, który definiuje możliwe stany na podstawie wartości przechowywanych danych. `Model` nie jest zatem kontenerem danych i łącznikiem do logiki biznesowej lecz instancją stanu, który może zawierać pewne informacje jednoznacznie go definiujące. `Warstwa widoku` obserwuje akcje użytkownika i zdarzenia systemu w efekcie których nadaje intencję dla wywołanego zdarzenia, a także nasłuchuje i reaguje na zmianę stanu modelu. Widok nie musi zatem znać zarówno odbiorcy jak i nadawcy strumienia danych. `Intencja` przeważnie nie jest osobną warstwą lecz reprezentantem przyszłej akcji zmieniającej stan modelu.
14
+
`MVI` (`Model-View-Intent`) usprawnia proces tworzenia i rozwijania aplikacji pisanych przy użyciu programowania reaktywnego poprzez wyróżnienie podziału odpowiedzialności pomiędzy trzy podmioty: widoku (`View`), modelu (`Model`) i intencji (`Intent`). Wzorzec ten jest w pewnym sensie pochodną `MVP` i `MVVM` dostosowaną do `programowania reaktywnego`. Eliminuje użycie metod zwrotnych (`callback`) oraz znacznie redukuje ilość metod wejście/wyjście (`input/output`). Jest także odpowiedzią na pojawiający się problem synchronizacji i rozbieżności przyjmowanych stanów przez warstwę widoku i logiki biznesowej wynikający z faktu iż stan jest sterowany przez warstwę `Presenter` lub `ViewModel`. W efekcie może prowadzić to do nieoczekiwanych zachowań i trudności w ich przewidzeniu oraz utrudnić debugowanie. `MVI` opiera się cyklicznym i jednokierunkowym przepływie oraz na istnieniu jednego niezmiennego (`immutable`) stanu wspólnego dla wszystkich warstw jako jedynego źródła prawdy. Rolę reprezentanta stanu przyjmuje model, który definiuje możliwe stany na podstawie wartości przechowywanych danych. `Model` nie jest zatem kontenerem danych i łącznikiem do logiki biznesowej lecz instancją stanu, który może zawierać pewne informacje jednoznacznie go definiujące. `Warstwa widoku` obserwuje akcje użytkownika i zdarzenia systemu w efekcie których nadaje intencję dla wywołanego zdarzenia, a także nasłuchuje i reaguje na zmianę stanu modelu. Widok nie musi zatem znać zarówno odbiorcy jak i nadawcy strumienia danych. `Intencja` przeważnie nie jest osobną warstwą lecz reprezentantem przyszłej akcji zmieniającej stan modelu.
15
15
16
16
## Ograniczenia
17
17
Wykorzystanie wzorca `MVI` jest propozycją na reaktywną architekture aplikacji co jednocześnie definuje jego charakterystykę oraz ogranicza jego zastosowanie. W przeciwieństwie do `MVP` i `MVVM` nie może być użyty w oderwaniu od programowania reaktywnego ponieważ stanowi jego implementacje dla architektury systemu. Pomimo iż programowanie reaktywne może być realizowane bez użycia dodatkowych zewnętrznych zależności przeważnie jednak jest implementowane z wykorzystaniem zewnętrznej biblioteki np. `RxJava` co dodatkowo wiąże `MVI` z zależnościami. Wymaga od programisty znajomości mechanizmów tworzenia aplikacji w sposób reaktywny. Ponadto nie eliminuje problemu zmiany konfiguracji czy wycieku pamięci.
@@ -22,7 +22,7 @@ Podobnie jak w przypadku innych wzorców architektonicznych zastosowanie `MVI` m
22
22
## Implementacja
23
23
Realizacja wzorca `MVI` może przypominać tą znaną z `MVP`, różnica polega jednak na implementacji i interakcji komponentów. Na podstawie klasy `Model` będącej kontenerem danych opisujących stan, definiowane są finalne klasy stanów o wspólnym rodzicu `PartialState`. Warstwa widoku `ViewImpl` implementuje interfejs `View` dostarczając zachowania obsługi otrzymanych stanów w metodzie `render` oraz emisji intencji w odpowiedzi na akcje użytkownika. Klasa `Presenter` odpowiada za odbieranie i przetwarzanie intencji z widoku oraz delegowanie ich do logiki biznesowej. W odpowiedzi na otrzymany stan tworzy nowy niezmienny obiekt modelu w metodzie `reduce`, który trafia do widoku.
Poniższy listing przedstawia realizację wzorca `MVI` z pominięciem zależności `Android` oraz zastosowaniem `RxJava` w celu realizacji programowania reaktywnego.
`MVC` (ang. `Model-View-Controller`) (wzorzec architektoniczny) ułatwia organizowanie struktury aplikacji poprzez podział odpowiedzialności na trzy rozdzielne warstwy: widoku (`View`), kontrolera (`Controller`) oraz modelu (`Model`). `Warstwa widoku` odpowiedzialna jest za sposób prezentacji danych z modelu w interfejsie użytkownika. `Warstwa kontrolera` obsługuje zdarzenia systemu oraz interakcję użytkownika poprzez delegowanie zadań do modelu oraz powiadamianie widoku o bieżącym stanie. Natomiast `warstwa modelu` odpowiada za logikę biznesową tzn. za przetwarzanie, przechowywanie i sposób dostarczania danych. Dzięki separacji odpowiedzialności kod staje się bardziej uporządkowany i elastyczny na modyfikacje (zmiana jednej warstwy nie musi pociągać za sobą zmiany kodu w pozostałych warstwach), a warstwa modelu jest zdolna do przeprowadzenia testów. `MVC` jest bardziej pojęciem konceptualnym niż zbiorem formalnych reguł implementacji.
14
+
`MVC` (`Model-View-Controller`) ułatwia organizowanie struktury aplikacji poprzez podział odpowiedzialności na trzy rozdzielne warstwy: widoku (`View`), kontrolera (`Controller`) oraz modelu (`Model`). `Warstwa widoku` odpowiedzialna jest za sposób prezentacji danych z modelu w interfejsie użytkownika. `Warstwa kontrolera` obsługuje zdarzenia systemu oraz interakcję użytkownika poprzez delegowanie zadań do modelu oraz powiadamianie widoku o bieżącym stanie. Natomiast `warstwa modelu` odpowiada za logikę biznesową tzn. za przetwarzanie, przechowywanie i sposób dostarczania danych. Dzięki separacji odpowiedzialności kod staje się bardziej uporządkowany i elastyczny na modyfikacje (zmiana jednej warstwy nie musi pociągać za sobą zmiany kodu w pozostałych warstwach), a warstwa modelu jest zdolna do przeprowadzenia testów. `MVC` jest bardziej pojęciem konceptualnym niż zbiorem formalnych reguł implementacji.
15
15
16
16
## Ograniczenia
17
17
Ze względu na specyfikę architektury systemu `Android` (cykl życia `Aktywności` i jej odpowiedzialności) warstwy `View` oraz `Controller` są często implementowane w `Aktywności` przez co nie ma między nimi wyraźnej rozdzielności. Z tego powodu zdolna do przeprowadzenia niezależnych testów jest tylko warstwa `Modelu`. Implementacja może zostać usprawniona (zgodnie z ideą wzorca) poprzez przeniesienie warstwy `View` do oddzielnej klasy i pozostawieniu `Aktywności` odpowiedzialności warstwy `Controller`. Jednakże takie rozwiązanie jest tylko połowiczne. Wprowadza sztuczny klasowy podział separacji warstw `View` oraz `Controller`, ponieważ `Aktywność` ciągle jest odpowiedzialna za inicjalizacje widoków w warstwie `View`, które są powiązane z jej cyklem życia. Co więcej warstwa `View` oraz `Controller` są zależne od klas Androidowych i mają dostęp do klasy `Model`, co nadal wpływa na podział odpowiedzialności i możliwości niezależnego testowania. Rozwiązaniem tego problemu może być zastosowanie wzorca `MVP`.
@@ -22,7 +22,7 @@ Wzorzec `MVC` można wykorzystać w małych projektach o niewielkiej ilości ekr
22
22
## Implementacja
23
23
Klasa `View` inicjalizuje widok oraz realizuje zachowania obiektów widoku, zmiany ich właściwości oraz stanów. `View` przechowuje referencje do modelu z którego czerpie niezbędne dane do obsługi obiektów widoku. Klasa `Controller` nadzoruje poprawną obsługę procesów między interakcją użytkownika i systemem. Przechwytuje zdarzenia oraz akcje użytkownika i systemu, deleguje wykonanie zadania do modelu, a następnie powiadamia widok o stanie żądanej akcji. Klasa `Model` implementuje logikę systemu, a także zarządza danymi.
`MVP` (ang. `Model-View-Presenter`) (wzorzec architektoniczny) usprawnia proces tworzenia ekranów aplikacji poprzez podział odpowiedzialności na trzy rozdzielne warstwy: widoku (`View`), prezentera (`Presenter`) oraz modelu (`Model`). `Warstwa widoku` odpowiedzialna jest za przechwytywanie interakcji użytkownika i odsyłanie zdarzeń do prezentera, a także za sposób prezentowania danych oraz stanu systemu i wykonywanych operacji w interfejsie graficznym. `Warstwa prezentera` obsługuje żądania podjęcia akcji na rzecz widoku poprzez proces sprawdzania stanu systemu, walidacji danych, tworzenia zapytań do modelu, a także informowanie widoku o aktualnym stanie zadania. `Warstwa modelu` zajmuje się logiką biznesową, przetwarzaniem, przechowywaniem oraz dostarczaniem żądanych danych do prezentera. Dzięki zastosowanemu podziałowi odpowiedzialności kod staje się uporządkowany, czytelny, otwarty na modyfikacje, łatwiejszy do debugowania, przeprowadzenia testów oraz ułatwia zespołom jednoczesną pracę nad jednym ekranem. `MVP` jest przede wszystkim konceptem, nie zbiorem sztywnych reguł implementacji.
14
+
`MVP` (`Model-View-Presenter`) usprawnia proces tworzenia ekranów aplikacji poprzez podział odpowiedzialności na trzy rozdzielne warstwy: widoku (`View`), prezentera (`Presenter`) oraz modelu (`Model`). `Warstwa widoku` odpowiedzialna jest za przechwytywanie interakcji użytkownika i odsyłanie zdarzeń do prezentera, a także za sposób prezentowania danych oraz stanu systemu i wykonywanych operacji w interfejsie graficznym. `Warstwa prezentera` obsługuje żądania podjęcia akcji na rzecz widoku poprzez proces sprawdzania stanu systemu, walidacji danych, tworzenia zapytań do modelu, a także informowanie widoku o aktualnym stanie zadania. `Warstwa modelu` zajmuje się logiką biznesową, przetwarzaniem, przechowywaniem oraz dostarczaniem żądanych danych do prezentera. Dzięki zastosowanemu podziałowi odpowiedzialności kod staje się uporządkowany, czytelny, otwarty na modyfikacje, łatwiejszy do debugowania, przeprowadzenia testów oraz ułatwia zespołom jednoczesną pracę nad jednym ekranem. `MVP` jest przede wszystkim konceptem, nie zbiorem sztywnych reguł implementacji.
15
15
16
16
## Ograniczenia
17
17
Ze względu na cykl życia `Aktywności`, `Fragmentu` czy innych komponentów interfejsu użytkownika może pojawić się wyciek pamięci referencji do nieistniejącego już widoku w prezenterze. Należy zatem zadbać o odpowiednią obsługę metod cyklu życia. Co więcej odtworzenie stanu prezentera (np. po obrocie ekranu) jest mocno utrudnione. Pomimo zalet płynących z abstrakcji, implementacja wzorca `MVP` wymaga stworzenia wielu dodatkowych klas i interfejsów (nierzadko o podobnej zawartości) co wiążę się często z nadmiarowym kodem. Ponadto istnieje zagrożenie, że klasa prezentera może stać się `superklasą`. Jako alternatywę warto rozważyć zastosowanie wzorca `MVVM`.
@@ -22,7 +22,7 @@ Wzorzec `MVP` wykorzystywany jest przede wszystkim w celu zlikwidowania problemu
22
22
## Implementacja
23
23
Zgodnie z podstawowymi założeniami wzorca warstwa widoku `ViewImpl` implementuje interfejs `View` oraz inicjalizuje instancje prezentera do którego deleguje wykonanie zadań. Klasa `PresenterImpl` jest dedykowana dla klasy widoku przez co sama w sobie jest swego rodzaju abstrakcją, dlatego nie ma wymogu, aby dodatkowo implementowała ona interfejs. Klasa `PresenterImpl` posiada referencje do widoku i modelu dla których pełni rolę pośrednika w komunikacji. `Warstwa prezentera` jest wolna od zależności klas Androidowych. Klasa `Model` dostarcza implementację zachowania modyfikacji i pobierania danych.
Poniższy listing przedstawia realizacje wzorca `MVP` spełniającą minimalne założenia implementacji wraz podstawowym podziałem na warstwy. Rozpoczęcie działania następuje w widoku.
0 commit comments