Architektura aplikacji AndroidŁUKASZ ANDRZEJEWSKI

Prowadzący

u Łukasz Andrzejewskiu Trener

u Programista

u Kontaktu l.andrzejewski@sages.com.pl

u http://pl.linkedin.com/in/lukaszandrzejewski

u https://github.com/landrzejewski

Agenda

u Dlaczego architektura jest ważna?u Złożoność aplikacji mobilnychu Czysta architekturau Model View Presenteru Model View ViewModelu Fluxu Is about intent, not frameworks

Dlaczego architektura jest ważna?

u Określa komponenty składowe aplikacji, ich rolę oraz wzajemne relacje

u Ułatwia u skalowanie

u testowanie

u rozwój / utrzymanie

u ponowne wykorzystanie kodu

u zrozumienie działania aplikacji

Złożoność aplikacji mobilnych

u Wybrane, niebiznesowe aspekty, które należy uwzględnić podczas budowania aplikacji na platformie Androidu kompatybilność wsteczna

u złożoność API

u różnorodność komponentów (cykl życia, przeznaczenie)

u zarządzanie stanem i jego synchronizacja (lokalnie, z serwerem)

u wielowątkowość

u oszczędzanie zasobów (pamięć, procesor, sieć)

u integracja z bibliotekami zewnętrznymi

…

Architektura na platformie Android

u Nie ma oficjalnych rekomendacji / wzorcówu W sieci można znaleźć przykłady wykorzystujące różne podejściau Wielu programistów lekceważy problem (na szczęście to się zmienia)

Architektura Android - „klasycznie”

u Podział aplikacji nau Model - realizuje dostęp do danych (baza, REST API)u Widok - prezentuje interfejs, odpowiada za interakcje z użytkownikiem,

często zawiera fragmenty logiki biznesoweju Problemy

u Duża odpowiedzialność na poziomie warstwy widoku (aktywności i fragmenty stają się bardzo duże i trudne w utrzymaniu)

u Testy jednostkowe są praktycznie niemożliwe (logika jest zaszyta na poziomie aktywności i fragmentów)

u Trudności z ponownym wykorzystaniem koduu Niska jakość (duplikacja, zły podział odpowiedzialności, callback hell itd.)

u Zdarza się, że część kodu jest przenoszona do klas pomocniczych(tzw. helperów), ale to nie rozwiązuje wszystkich problemów

Czysta architektura(według Uncle Bob)

The Dependency Rule

Nothing in an inner circle can knowanything at all about something in anouter circle. In particular, the name ofsomething declared in an outer circlemust not be mentioned by the code inthe an inner circle. That includes,functions, classes. variables, or any othernamed software entity.

https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html

Warstwy

u Mają charakter umowny (może być ich więcej)u Ważny jest kierunek występujących zależności (do wewnątrz) u Zaproponowany podział obejmuje

u Entities - obiekty i struktury danych definiujące reguły biznesowe

u Use Cases - logika biznesowa specyficzna dla danej aplikacji

u Interface Adapters - zbiór adapterów zapewniających konwersję danych pomiędzy Entities i Use Cases, a elementami zewnętrznyminp. warstwą prezentacji, usługami

u Frameworks and Drivers - warstwa złożona z narzędzi i frameworków np. baza danych

Model View Presenter (MVP)

u Wzorzec architektoniczny związany z warstwą prezentacjiu Pochodna wzorca Model View Controlleru Dzieli aplikację na

u Model - realizuje logikę biznesową i dostęp do danych

u Presenter - działa na poziomie modelu oraz widoku (dostarcza dane i przygotowuje je do wyświetlenia)

u View - pasywnie wyświetla dane, przekierowuje informacje o zdarzeniach do prezentera

Model View ViewModel

u Wzorzec architektoniczny związany z warstwą prezentacjiu Pochodna wzorca Model View Controlleru Dzieli aplikację na

u Model - realizuje logikę biznesową i dostęp do danych

u View - definiuje strukturę, rozkład i wygląd widoku

u ViewModel - udostępnia model danych (w postaci przygotowanej specjalnie dla widoku) i realizuje logikę związaną z prezentacją

RxAndroid

u Implementacja biblioteki Reactive Extensionsu Umożliwia tworzenie aplikacji sterowanych zdarzeniamiu Jest to rozszerzenie koncepcji wzorca obserwatora

u obserwujemy sekwencje zdarzeń (kliknięcie, nowe dane z serwera, zmiana statusu itd.)

u sekwencje mogą być kombinowane / filtrowane / mapowane z użyciem operatorów

u wszystko w programie jest wynikiem reakcji na zdarzenie (nie ma potrzeby przechowywania stanu)

u Zaletyu Oderwanie od szczegółów niskopoziomowych takich jak wielowątkowość czy

synchronizacja stanu

u Alternatywa dla wielokrotnie zagnieżdżanych funkcji typu callback

u Automatyczna synchronizacja stanu modelu i widoku (bindowanie)

http://reactivex.io

Architektura Flux

u Używana przez twórców Facebook’a do budowy aplikacji webowych

u Daje się przenieść na poziom Androida i innych platformu Założenia

u Jednokierunkowy przepływ danych (bardzo ważne)

u Podział aplikacji na warstwyu View - stanowi interfejs aplikacji, tworzy Akcje w wyniku interakcji z użytkownikiem

u Dispatcher - odpowiada za przetwarzanie Akcji i dostarczenie ich do magazynów

u Store - zarządza stanem (np. danego modułu aplikacji) , reaguje na Akcje, w zależności od aktualnego stanu uruchamia logikę biznesową i informuje przez eventy o jego zmianie, co z kolei powoduje odświeżenie widoku

u Akcja - zwykły obiekt, najczęściej zawiera typ i dane związane ze zdarzeniem

https://facebook.github.io/flux/docs/overview.html

Flux na Android (w uproszczeniu)

u View - aktywności i fragmenty

u Dispatcher - event bus

u Action - zwykły obiekt

u Store - dedykowana klasa / implementacja

Flux na Android - Store

u Emituje tylko jeden typ zdarzenia changeu Udostępnia API pozwalające na pobranie stanu aplikacji (dzięki

czemu możliwa jest aktualizacja widoku)u Nie jest tożsamy z repozytorium - odpowiada za podejmowanie

działań w odpowiedzi na zdarzenia oraz śledzenie stanu aplikacji

Flux na Android - operacje asynchroniczne

u Działania asynchroniczne powinny być inicjowane z poziomu producenta Akcji

u Po otrzymaniu rezultatu kreator przekazuje go w ramach utworzonej akcji do Dispatchera, a ten do Store

u W konsekwencjiu Store działa synchronicznie (łatwa i zrozumiała

logika, proste testowanie)

u Wszystkie Akcje są uruchamiane z jednego miejsca (proste szukanie błędów)

https://github.com/lgvalle/android-flux-todo-app

Warsztat

u Budowa aplikacji w oparciu o różne architektury

Uncle Bob: Architecture is about intent, not frameworks

u Nie ma jednej, idealnej architekturyu Dla danej aplikacji trzeba podjąć indywidualną decyzję - każde z

podejść może mieć plusy i minusy

https://github.com/ziem/android-architecture-resources

Chcesz wiedzieć więcej?

u Szkolenia pozwalają na indywidualną pracę z każdym uczestnikiemu pracujemy w grupach 4-8 osobowych

u program może być dostosowany do oczekiwań grupy

u rozwiązujemy i odpowiadamy na indywidualne pytania uczestników

u mamy dużo więcej czasu :)

Szkolenia dedykowane dla Ciebie

u Interesuje Cię tematyka warsztatu?u Zapoznaj się z programami szkoleń:

u Tworzenie aplikacji na platformie Android

u Zaawansowane tworzenie aplikacji na platformie Android

u Inżynieria odwrotna i techniki zabezpieczania aplikacji na platformie Android

u Tworzenie aplikacji Android w języku Kotlin

Wspierają nas