1.
Architektura
aplikacji Android
ŁUKASZ ANDRZEJEWSKI

2.
Prowadzący
u Łukasz Andrzejewski
u Trener
u Programista
u Kontakt
u l.andrzejewski@sages.com.pl
u http://pl.linkedin.com/in/lukaszandrzejewski
u https://github.com/landrzejewski

3.
Agenda
u Dlaczego architektura jest ważna?
u Złożoność aplikacji mobilnych
u Czysta architektura
u Model View Presenter
u Model View ViewModel
u Flux
u Is about intent, not frameworks

4.
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

5.
Złożoność aplikacji mobilnych
u Wybrane, niebiznesowe aspekty, które należy uwzględnić podczas
budowania aplikacji na platformie Android
u 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
…

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

7.
Architektura Android - „klasycznie”
u Podział aplikacji na
u Model - realizuje dostęp do danych (baza, REST API)
u Widok - prezentuje interfejs, odpowiada za interakcje z użytkownikiem,
często zawiera fragmenty logiki biznesowej
u 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 kodu
u 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

8.
Czysta architektura
(według Uncle Bob)
The Dependency Rule
Nothing in an inner circle can know
anything at all about something in an
outer circle. In particular, the name of
something declared in an outer circle
must not be mentioned by the code in
the an inner circle. That includes,
functions, classes. variables, or any other
named software entity.
https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html

9.
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ętrznymi
np. warstwą prezentacji, usługami
u Frameworks and Drivers - warstwa złożona z narzędzi i frameworków
np. baza danych

10.
Model View Presenter (MVP)
u Wzorzec architektoniczny związany z warstwą prezentacji
u Pochodna wzorca Model View Controller
u 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

11.
Model View ViewModel
u Wzorzec architektoniczny związany z warstwą prezentacji
u Pochodna wzorca Model View Controller
u 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ą

12.
RxAndroid
u Implementacja biblioteki Reactive Extensions
u Umożliwia tworzenie aplikacji sterowanych zdarzeniami
u 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 Zalety
u 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

13.
Architektura Flux
u Używana przez twórców Facebook’a do budowy aplikacji webowych
u Daje się przenieść na poziom Androida i innych platform
u Założenia
u Jednokierunkowy przepływ danych (bardzo ważne)
u Podział aplikacji na warstwy
u 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

14.
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

15.
Flux na Android - Store
u Emituje tylko jeden typ zdarzenia change
u 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

16.
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 konsekwencji
u 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

17.
Warsztat
u Budowa aplikacji w oparciu o różne architektury

18.
Uncle Bob: Architecture is about
intent, not frameworks
u Nie ma jednej, idealnej architektury
u Dla danej aplikacji trzeba podjąć indywidualną decyzję - każde z
podejść może mieć plusy i minusy
https://github.com/ziem/android-architecture-resources

19.
Chcesz wiedzieć więcej?
u Szkolenia pozwalają na indywidualną pracę z każdym uczestnikiem
u 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 :)

20.
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

21.
Wspierają nas