Kurs Android (22)

Autor: Damian Chodorek • Opublikowany: 16 września 2016 • Kategoria: android, kursy

Wzorzec architektoniczny VIPER.

W poprzedniej lekcji poznałeś podstawowy i jeden z popularniejszych wzorców architektonicznych, z którego korzystają programiści Androida: Model-View-Presenter. Zanim przystąpisz do tej lekcji, powinieneś go poznać.

MVP nie jest idealny. Często kod, który nie pasuje ani do warstwy widoku, ani modelu, zostaje wrzucony do prezentera. To może sprawić, że prezenter stanie się god object, czyli obiektem, który posiada dużo niepowiązanego kodu i który łamie zasadę SRP. VIPER jest rozwiązaniem tego problemu, ponieważ dokonuje on jeszcze większego podziału odpowiedzialności.

Wzorzec VIPER

VIPER to wzorzec często stosowany przez deweloperów iOSa. Nie znaczy to, że nie jest on dobrym rozwiązaniem również na Androida. Składa się z następujących warstw.

  • View – warstwa widoku, która w zasadzie została opisana w poprzedniej lekcji. Widok to klasa odpowiedzialna bezpośrednio za UI. Zajmuje się jego stworzeniem, animacjami, przechwytywaniem akcji użytkownika. Widok zawiera prezentera, któremu przekazuje wspomniane akcje.
  • Interactor – interaktor to warstwa odpowiedzialna za komunikację ze źródłem danych. We wzorcu MVP, odpowiadał za to prezenter. W VIPERze prezenter posiada interaktora, który pobiera dane ze źródła i zwraca je do niego. Interaktor dla prezentera jest więc swego rodzaju Data Access Object. Wszelka logika związana z danymi, jest wykonywana w warstwie interaktora, np. połączenie danych z bazy danych i z sieci w jedną całość.
  • Presenter – prezenter, podobnie jak widok, został szczegółowo opisany w poprzedniej lekcji. Prezenter odbiera akcje od widoku, reaguje na nie, a następnie mówi widokowi, co ma zrobić. Prezenter steruje więc widokiem. Ponadto, zawiera on interaktor do pobierania danych oraz router, który opisałem poniżej.
  • Entity – czyli nasz model danych. Entity to przeważnie POJO, które nie zawierają żadnej logiki. Encje reprezentują jakieś obiekty ze świata rzeczywistego lub wyobrażonego i są przekazywane między różnymi warstwami. Interaktor pobiera encje ze źródła danych lub konwertuje dane z innej postaci właśnie do encji. Następnie przekazuje je do prezentera, a ten z kolei do widoku, który, przy pomocy adapterów, konwertuje je do elementów UI.
  • Router – podobnie jak interaktor, router należy do prezentera. Router służy do komunikacji z systemem, np. rozpoczyna inne aktywności, uruchamia serwisy, ustawia alarmy.

Jak widzisz VIPER spowodował że prezenter, znany z MVP, został rozbudowany o dwa obiekty: router, interaktor. Podział odpowiedzialności jest jeszcze większy, a co za tym idzie, istnieje mniejsza szansa, że nasz prezenter stanie się god object.

Powyższy schemat jest bardzo poglądowym pokazaniem zależności pomiędzy warstwami. Zauważ, że warstwa Entity to nie tylko encje, ale również źródło danych, które je udostępnia, np DbManager, ApiManager lub inny DAO.

Zalety VIPERa

  • Duży podział odpowiedzialności zmniejsza prawdopodobieństwo powstawania bugów.
  • Kod jest czystszy, bardziej czytelny i łatwiej go testować.
  • Gdy projekt będzie długo rozwijany i często modyfikowany, VIPER zapobiegnie pogarszaniu się jakości kodu.
  • Przy danej funkcjonalności może pracować wielu programistów równolegle. Podział odpowiedzialności sprawia, że jedna osoba pisze widok, inna prezenter, inna interaktor, router, itd. W ten sposób, nad jednym ekranem w aplikacji może pracować kilka osób. Podział jest większy niż w MVP.

Zalety VIPERa są widoczne w dłuższej perspektywie. Dla krótkich i prostych projektów może być on przesadą. Zauważ, że składa się on z 5 warstw, co wiąże się z powstaniem wielu klas i interfejsów.

Moviper

Moviper to biblioteka pomagająca zaimplementować wzorzec VIPER. Opiera się na bibliotece do MVP – Mosby, o której wspomniałem w poprzedniej lekcji. W skład biblioteki wchodzi również generator szablonów. Cała nasza praca sprowadza się do nadania nazwy modułowi, a generator wygeneruje nam wszystkie klasy i interfejsy VIPERa wraz z odpowiednimi zależnościami. Naszym zadaniem będzie jedynie implementacja metod specyficznych dla naszej aplikacji. Zanim zaczniesz korzystać z Movipera, zapoznaj się z biblioteką Mosby. Poniżej linki.

Kolejna część już wkrótce.

1 komentarz

  • Eryk napisał(a):

    Cześć, Damianie, mógłbyś poświecić kilka odcinków kursów na temat Loaderów?

  • Dodaj komentarz

    Twój adres e-mail nie zostanie opublikowany.