Dagger 2. Profesjonalne aplikacje dla Androida i Javy - ebook

Rozdział I. Informacje ogólne

1. Czym jest Dagger 2?

Dagger 2 to w pełni statyczny framework do wstrzykiwania zależności (_dependency injection_) w czasie kompilacji dla języków Java i Kotlin, który współpracuje z platformami JavaSE/JavaEE oraz Android. Jest to rozwinięcie wcześniejszej wersji stworzonej przez firmę Square i obecnie utrzymywanej przez Google’a. Dagger 2 nie używa żadnego mechanizmu refleksji ani generowania kodu w czasie wykonywania (_run-time_), ale wykonuje całą analizę w czasie kompilacji i generuje wtedy zwykły kod źródłowy Java. Jest to obecnie najpopularniejsza biblioteka przeznaczona do wstrzykiwania zależności na platformę Android.

2. Czym jest wstrzykiwanie zależności (DI)?

W inżynierii oprogramowania wstrzykiwanie zależności (_dependency injection_, DI) to technika, w której obiekt otrzymuje z zewnątrz inne obiekty, które są mu niezbędne do prawidłowej pracy. Te inne obiekty nazywane są zależnościami. W typowej relacji obiekt, który przyjmuje inny obiekt, nazywany jest klientem (_client_), a przekazany (wstrzykiwany) obiekt nazywany jest usługą (_service_). Technika ta często utożsamiana jest z inną techniką programowania, zwaną odwróceniem kontroli — IoC (_inversion of control_), choć z technicznego punktu widzenia DI stanowi jedną z jej szczególnych (obecnie najpopularniejszych) postaci. Odwrócone kontroli pozwala nam na eliminację niedogodności tworzenia kodu, takich jak:

— Sztywność przy zmianie elementów kodu.

— Wrażliwość kodu na zmiany w części programu.

— Brak mobilności przy wydzielaniu części kodu do ponownego użycia.

Wspomniana technika nazywana jest wzorcem projektowym (_design pattern_). Wzorce projektowe to uniwersalne, sprawdzone w praktyce rozwiązanie często pojawiających się, powtarzalnych problemów projektowych. Pokazują powiązania i zależności pomiędzy klasami oraz obiektami i ułatwiają tworzenie, modyfikację, a także utrzymanie kodu źródłowego.

Celem wstrzykiwania zależności jako wzorca projektowego jest rozdzielenie dwóch funkcji tworzonego kodu, tj. konstrukcyjnej i funkcjonalnej (_constructional and functional_). Kod konstrukcyjny ma za zadanie tworzenie obiektów, natomiast funkcjonalny ich wykorzystanie celem realizacji przeznaczenia programu. Struktura dobrze zorganizowanej aplikacji rozdziela kod konstrukcyjny i funkcjonalny.

3. Czym jest zależność?

Zależność to ogólna sytuacja, która zachodzi w kodzie, gdy klasa odnosi się do innej klasy. Dla przykładu zostanie utworzona pewna klasa. Nie ma znaczenia, jaki jest jej cel i co robi:

public class NetManager{

User user = new User();

Password password = new Password ();

Host host = new Host();

public void doSomething(){

user.doSomething();

password.doSomething();

host.doSomething();

}

}

Odnośnie do powyższego przykładu można powiedzieć, że klasa NetManager zależy od klas User, Password i Host lub że te klasy są zależnościami klasy NetManager. Nie da się utworzyć i korzystać z obiektu tej klasy bez utworzenia instancji klas zależnych.

4. Na czym polega wstrzykiwanie zależności?

Pora wrócić do przykładu klasy NetManager i jednej z jej metod:

NetManager netManager = new NetManager();

netManager.doSomething();

Szybko i prosto otrzymana została instancja klasy gotowa do pracy, a następnie wywołana jedna z jej metod. Pojawia się jednak kilka problemów związanych z takim kodem. W jednym miejscu nastąpiło połączenie kodu konstrukcyjnego, który tworzy obiekt, i funkcjonalnego, który wykonuje jakieś zadanie. To akceptowalna konstrukcja, jeżeli dysponujesz kilkoma obiektami. Jednak jeżeli jest ich kilkaset, kilka tysięcy lub więcej, tracisz możliwość łatwego zarządzania tworzeniem obiektów. Inne utrudnienia związane są z koniecznością dostarczenia parametrów do konstruktorów:

NetManager netManager = new NetManager(user, password, link);

Choć są tylko trzy argumenty, mogą sprawić problemy. Możemy ich nie znać lub nie mieć do nich dostępu (np. do hasła). Ponadto możemy nie mieć dokumentacji klas. Możliwe też, że zamierzamy tworzyć obiekt warunkowo — inny obiekt podczas testowania, a inny w produkcji. Obiekt może wymagać także skomplikowanej konfiguracji przed użyciem. Na przykład:

NetManager netManager = new NetManager(user, password, link);

netManager.startService();

netManager.acceptFormat(NetManager.SOME­FORMAT);

netManager.establishFreq(100);

netManager.initDevice(null);

Rozwiązaniem tych problemów jest wydzielenie tworzenia obiektu i przeniesienie tego procesu w inne miejsce:

NetManager netManager;

netManager.doSomething();

Oczywiście taki kod wywoła wyjątek. Potrzebny jest mechanizm, który stworzy instancję klasy i przypisze (wstrzyknie) ją do referencji. Część z powyższych problemów można wyeliminować przy pomocy wzorca projektowego Factory. W przedstawionym przykładzie wyglądałoby to tak:

static class NetManagerFactory{

public NetManager buildNetManager(String user, String password, String link){

NetManager netManager =

new NetManage­r(user, password, link);

netManager.startService();

netManager.acceptFormat(NetManager.SOME_FORMAT);

netManager.establishFreq(100);

netManager.initDevice(null);

return netManager;

}

}

W takim wypadku utworzenie obiektu prezentowałoby się w ten sposób:

NetManager netManager = NetManager. buildNetManager();

Pewne problemy zostały rozwiązane, inne jednak pozostały. Nadal należy znać lub utworzyć parametry dla obiektu. Nadal samodzielnie utworzono docelowy obiekt.

5. Jaka jest zasadnicza różnica między wstrzykiwaniem zależności a wzorcem Factory?

Powodem, dla którego wstrzykiwanie zależności (DI) i wzorzec Factory są podobne, jest to, że są to dwie implementacje innego wzorca projektowego zwanego odwróceniem kontroli (Inversion of Control, IoC). Mówiąc prościej, to dwa rozwiązania tego samego problemu. Główną różnicę między wzorcem Factory a DI stanowi sposób uzyskiwania obiektu. Jeżeli chodzi o wstrzykiwanie zależności, jak sama nazwa wskazuje, obiekt jest wstrzykiwany lub przekazywany do kodu. W przypadku wzorca Factory w kodzie należy zażądać obiektu ręcznie. Factory jest wykorzystywany, gdy chce się zbudować obiekt, a nie tylko go stworzyć. Zbudowanie oznacza nie tylko utworzenie obiektu, ale także zastosowanie wobec niego pewnej logiki.

Warto zauważyć, że wzorce Factory (lub wzorce Factory Abstract, które są fabrykami zwracającymi nowe fabryki) mogą być napisane w celu dynamicznego dobierania lub łączenia z typem bądź klasą obiektu żądanego w czasie wykonywania (_run-time_). To sprawia, że są bardzo podobne (nawet bardziej niż DI) do wzorca Service Locator, który jest kolejną implementacją IoC.

6. Jak działa wzorzec projektowy Service Locator?

Zarówno wzorzec Service Locator (SL), jak i Dependency Injection (DI) są postaciami innego wzorca — znanego jako Object Access Pattern (OAP) — i stosują zasadę odwrócenia zależności (_dependency inversion principle_). Oba wzorce mają taki sam cel — zwiększenie rozdzielenia kodu konstrukcyjnego od funkcjonalnego dla lepszego testowania, skalowalności i czytelności kodu. Różnica jest taka, że DI to wzorzec statycznego dostępu do obiektów, podczas gdy SL stanowi postać dynamiczną. SL jest wykorzystywany, gdy nie znamy konkretnego dostawcy usługi przed kompilacją. Tymczasem w przypadku DI musimy znać dostawcę obiektów w czasie pisania kodu. SL lepiej pasuje do modułowej konstrukcji niektórych aplikacji, docelowy obiekt bowiem pozyskuje zależności z lokatora (kontenera, rejestru), który pomaga w ich wyszukaniu i pozyskaniu. Nie zostają one wstrzyknięte, ale zlokalizowane:

public class NetManager{

final private User user;

public NetManager(){

this.user = serviceLocator.getObject(User.class);

}

}

7. Jakie są sposoby wstrzykiwania zależności?

Istotą wstrzykiwania zależności jest pozyskanie obiektów z zewnątrz za pomocą jednej z trzech technik:

— Wstrzykiwanie przez konstruktor.

— Wstrzykiwanie przez metodę.

— Wstrzykiwanie przez pole.

Wstrzykiwanie zależności przez konstruktor polega na dostarczeniu zależnego obiektu jako argumentu konstruktora. W przypadku wstrzykiwania przez metodę zależność dostarczamy przez osobną publiczną funkcję. Z kolei wstrzyknięcie przez pole ma miejsce w przypadku dostarczenia obiektu przez zewnętrzny mechanizm do publicznego pola. W poniższym przykładzie obiekt klasy User zostaje dostarczony przez parametr konstruktora, obiekt klasy Password przez parametr metody, a obiekt klasy Host może zostać dostarczony z zewnątrz do publicznego pola:

public class NetManager{

private User user;

private Password password;

public Host host;

public NetManager(User user){

this.user = user;

}

public setPassword(Password password){

this.password = password;

}

public void doSomething(){

use.doSomething();

password.doSomething();

host.doSomething();

}

}

Zalety wstrzyknięcia przez konstruktor to prostota, jasne odzwierciedlenie koniecznych zależności w parametrach, łatwość testowania oraz możliwość finalizacji pola. W przypadku wstrzykiwania przez metodę zależności również są odzwierciedlone w parametrach. Ponadto możliwe jest wywołanie metody po konstruktorze. Wadą wstrzyknięcia przez konstruktor jest brak wskazania, że akurat te obiekty stanowią zależności oraz w jakiej kolejności należy wywołać metody, co może prowadzić do kolizji z metodami wykorzystującymi dane zależności. Jeżeli chodzi o wstrzykiwanie przez pole, to ta technika ma te same wady i zalety, co wstrzykiwanie przez metodę, choć nie wskazuje tak jednoznacznie, co jest zależnością.

8. Jak wygląda wstrzykiwanie zależności za pomocą Daggera 2 w praktyce?

Jedna z metod wstrzykiwania zależności przez pola wygląda mniej więcej tak:

@Inject

NetManager netManager;

Jak łatwo można zauważyć, brakuje tutaj słowa kluczowego „new” oraz pojawiła się anotacja @Inject. Anotacje to elementy kodu, którymi mogą zostać oznaczone klasy, metody, zmienne, parametry czy też moduły. Tak jak w przypadku tagów w dokumentacji Javy — istnieje możliwość odczytania anotacji z plików źródłowych i tym samym rozszerzenia funkcjonalności klas i obiektów. Anotacje dostarczają meta informacji w czasie kompilacji, budowania lub pracy programu.

9. Czym zajmuje się anotacja @Inject?

Jak wspomniano wcześniej, przy tworzeniu kodu problemem może być tworzenie obiektu, przekazywanie mu parametrów oraz jego konfiguracja. Poniższa anotacja robi to wszystko automatycznie:

@Inject

NetManager netManager;

Pomimo braku słowa kluczowego „new” pole netManager nie jest pustą referencją i nie wywoła wyjątku NullPointerException przy próbie użycia. Wskazuje na skonfigurowany, w pełni legalny, gotowy do użycia obiekt. Oczywiste jest, że gdzieś w kodzie ta referencja musi zostać zainicjowana przez przypisanie jej obiektu danej klasy. Sama anotacja jedynie wskazuje, do jakiego pola ma to nastąpić.

10. Jakie są zalety wykorzystania Daggera 2 do wstrzykiwania zależności?

Dagger 2 jako framework do wstrzykiwania zależności posiada wiele zalet:

— Upraszcza dostęp do współdzielonych instancji obiektu.

— Zapewnia łatwą konfigurację złożonych zależności. Istnieje niejawna kolejność, w jakiej często tworzone są obiekty. Dagger 2 przechodzi przez graf zależności i generuje kod, który jest łatwy do zrozumienia i śledzenia, a jednocześnie chroni przed pisaniem dużej ilości standardowego kodu, który normalnie należałoby pisać ręcznie, aby uzyskać referencje i przekazać je do innych obiektów jako zależności.

— Pomaga również uprościć zmiany kodu (refaktoryzację), ponieważ pozwala skupić się na tym, jakie moduły zbudować, zamiast na kolejności, w jakiej należy je tworzyć.

— Ułatwia testy jednostkowe i integracyjne, ponieważ tworzony jest graf zależności, w którym możesz łatwo wymieniać moduły.

— Kontroluje cykl życia obiektu. Nie tylko umożliwia łatwe zarządzanie instancjami, które mogą trwać cały cykl życia aplikacji, ale również pozwala na definiowanie instancji o krótszych okresach istnienia (np. związanych z sesją użytkownika, cyklem życia działania itp.).

— Umożliwia wykorzystanie mechanizmu lokalnych singletonów.

— Ma niewielki rozmiar.

— Opiera się o generator kodu, co ułatwia debugowanie.

11. Jakie są wady Daggera 2?

Dagger 2 nie uniknął oczywiście pewnych wad. Zaliczyć do nich można przede wszystkim wysoki poziom złożoności biblioteki i stromą krzywą nauki. Do tego dochodzi skromna dokumentacja, brak dobrych praktyk i zbyt dużo zaimplementowanych funkcji. Jeżeli chodzi o konkretne wady, to w dużym skrócie można powiedzieć, że po pierwsze Dagger 2 nie wstrzykuje obiektów do pól automatycznie, po drugie nie wstrzykuje obiektów w prywatne pola, a po trzecie — jeżeli Dagger 2 ma wstrzyknąć obiekt w pole, należy najpierw zdefiniować odpowiednią metodę w interfejsie oznaczonym anotacją @Component, która zwraca odpowiedni obiekt.

12. Jakie są konkurencyjne frameworki zajmujące się wstrzykiwaniem zależności?

Głównymi konkurentami dla frameworka Dagger 2 są Spring, Guice, a w mniejszym stopniu Koin. Spring to stosunkowo ciężki framework z wieloma integracjami, językiem konfiguracji XML i wstrzykiwaniem dokonywanym run-time / refleksyjnie. Aplikacje korzystające już ze Springa mogą używać struktury wstrzykiwania zależności Spring przy niewielkim nakładzie pracy. Guice to stosunkowo lekki framework z mniejszą liczbą integracji, konfiguracją instancji i wstrzykiwaniem dokonywanym run-time / refleksyjnie. Korzystając z powiązań Javy, uzyskuje się kontrolę typu podczas kompilacji i autouzupełnianie przy integracji w IDE. Z kolei Koin to prosty, potężny framework do wstrzykiwania zależności dla języka Kotlin. Napisany w czystym Kotlinie bez proxy, bez generowania kodu, bez refleksji.

Na tle wymienionych Dagger 2 to bardzo lekki framework z bardzo małą liczbą integracji, konfiguracją za pomocą interfejsu/anotacji Java oraz powiązaniami generowanymi w czasie kompilacji. Aspekt generowania kodu sprawia, że Dagger jest ogólnie bardzo wydajny, szczególnie w środowiskach mobilnych i o ograniczonych zasobach.

13. Jaka jest relacja Daggera 2 do Daggera 1?

Dagger 2 nie stanowi prostego rozwinięcia swojego poprzednika. W ramach Daggera 2 dokonano wielu zmian, które pod wieloma względami uczyniły tę bibliotekę niekompatybilną z wcześniejszą wersją i nader odmienną, jeżeli chodzi o założenia konstrukcyjne. Chociaż projekty Dagger 1 i Dagger 2 są do siebie podobne pod wieloma względami, jeden nie zastępuje drugiego.

Wszystkie metody wstrzykiwania obsługiwane przez framework Dagger 1 (przez pole i konstruktor) nadal są obsługiwane przez Daggera 2, ale Dagger 2 obsługuje również wstrzykiwanie przez metodę. Dagger 2 nie obsługuje wstrzykiwania statycznego. Jednak podstawową różnicę między platformami programistycznymi Dagger 1 i Dagger 2 stanowi mechanizm, za pomocą którego budowany jest pełny graf zależności (o tym, czym jest graf, napisano w innym rozdziale). W Daggerze 1 graf zostaje utworzony przez mechanizm refleksji w ObjectGraph, a w Daggerze 2 jest to zrobione przez anotację @Component, czyli typ zdefiniowany przez użytkownika, którego implementacja jest generowana w czasie kompilacji.

Dagger 2 znany jest również jako Google Dagger z racji przejęcia prowadzenia projektu przez firmę Google. Wraz z nową wersją wprowadzono konkretne zmiany:

— Wszystkie analizy kodu mają miejsce podczas kompilacji.

— Wprowadzono anotacje zakresowe.

— Usunięto refleksję.

— Wprowadzono wstrzykiwanie przez metodę.

— Usunięto tworzenie grafu run-time.

— Istnieje mniej konfiguracji przy tworzeniu modułów.

— Kod jest szybszy i łatwiejszy w użyciu.

Dagger 1 oficjalnie uznano za przestarzały (15 września 2016 r.) i nie jest już aktywnie rozwijany. Zaleca się migrację do Daggera 2.

14. Na jakiej licencji działa Dagger 2?

Dagger 2 działa na licencji Apache License w wersji 2.0. W dużym skrócie pozwala ona na używanie, modyfikowanie i redystrybucję programu w postaci źródłowej lub binarnej bez obowiązku udostępnienia kodu źródłowego. Oznacza to, że kod na tej licencji można włączyć do zamkniętych programów — pod warunkiem zachowania zgodności z warunkami tej licencji.

15. Czy można liczyć na utrzymanie Daggera 2 i jego dalszy rozwój?

Dagger 2 jest aktywnie utrzymywany przez zespół Google’a, ten sam, który pracuje nad biblioteką Guava. Dlatego też można spodziewać się długiego życia tej biblioteki. Podczas konferencji Android Dev Summit w 2019 r. przedstawiciele Google’a zaprezentowali opinię na temat budowania aplikacji na platformę Android, zgodnie z którą wykorzystanie Daggera 2 dla średnich i dużych projektów stanowi rekomendowany sposób tworzenia kodu na Androida. Dla małych projektów rekomenduje się platformę Dagger 2 lub wzorzec Service Locator. Intensywnie rozwijana jest także część bibliotek przeznaczonych wyłącznie dla Androida, zwłaszcza wraz z inauguracją pakietu Hilt.

16. Gdzie można znaleźć kod źródłowy Daggera 2?

Dagger 2 posiada ogólnie dostępny kod na GitHubie pod tym adresem:

https://github.com/google/dagger

17. Gdzie można znaleźć dokumentację Daggera 2?

Tutaj dostępny jest mały tutorial i FAQ po angielsku:

https://dagger.dev/users-guide

Pełna dokumentacja dla wersji 2.32 znajduje się tutaj:

https://dagger.dev/api/2.32/overview-summary.htmlRozdział II. Instalacja

1. Jak zainstalować Daggera 2 w Javie dla Androida?

W celu instalacji wykorzystaj środowisko Android Studio. Na początku należy utworzyć nowy projekt o nazwie Dagger Android:

FILE -> NEW -> NEW PROJECT

Następnie wynależy wybrać templatkę o nazwie Empty Activity. Przyda się startowa klasa Activity, ale nie musi mieć żadnych szczególnych elementów graficznych. Po wygenerowaniu projektu powinno się otrzymać klasę MainActivity, a w niej metodę onCreate. W projekcie w sekcji Gradle Scripts znajduje się plik build.gradle. Wybierzemy ten z modułu app i edytuj go. W sekcji:

dependencies{…}

Należy dodać następujące wpisy:

implementation „com. google. dagger: dagger-android:2.32”

implementation „com. google. dagger: dagger-android-support:2.32”

anotationProcessor „com. google. dagger: dagger-android-processor:2.32”

anotationProcessor „com. google. dagger: dagger-compiler:2.32”

Następnie należy wymusić pobranie bibliotek:

FILE -> SYNC PROJECT WITH GRADLE FILES

W oknie (konsoli) Build powinna pojawić się następująca informacja:

BUILD SUCCESSFUL in Xm XXs

2. Jak zainstalować Daggera 2 w Kotlinie dla Androida?

Konfiguracja bibliotek dla języka Kotlin różni się trochę od tej dla Javy. Przede wszystkim w pliku build.gradle należy dodać plugin dla Kotlina:

apply plugin: „kotlin-kapt”

Plugin ten musi zostać dodany w odpowiednim miejscu:

apply plugin: 'com.android. application”

apply plugin: „kotlin-android”

apply plugin: „kotlin-kapt”

apply plugin: „kotlin-android-extensions”

W sekcji dependencies trzeba dodać następujące wpisy:

implementation „com. google. dagger: dagger-android:2.32”

implementation „com. google. dagger: dagger-android-support: 2.32”

kapt „com. google. dagger: dagger-android-processor: 2.32”

kapt „com. google. dagger: dagger-compiler: 2.32”

compileOnly „com. google. dagger: dagger:2.31.2”

compileOnly 'javax.anotation: jsr250-api:1.0”

implementation 'javax.inject:javax.inject:1”

compileOnly 'javax.anotation:javax.anotation-api:1.3.2”

3. Jak sprawdzić w środowisku Android Studio, czy instalacja Daggera 2 jest poprawna?

Aby przetestować, czy Dagger 2 został poprawnie zainstalowany, należy stworzyć mały projekt. W tym momencie nie jest istotne, co znaczą jego poszczególne elementy. Zacząć powinniśmy od utworzenia klasy, którą będziemy wstrzykiwać:

public class NetManager{

public void sayHello() {

System.out.println(„NetComponent says Hello”);

}

}

Następnie należy utworzyć zwykły interfejs o dowolnej nazwie, na przykład NetComponent:

import dagger.Component;

@Component(modules={NetModule.class})

public interface NetComponent{

NetManager provideNetManager();

}

Jak widać, nad nazwą interfejsu dodana została anotacja @Component wraz z parametrem wskazującym na klasę NetModule, którą zaraz utworzymy. Nie będzie możliwe jej użycie bez zaimportowania pakietu „dagger.Component”.

Stworzymy teraz klasę o nazwie NetModule i oznaczymy ją anotacją @Module. Następnie umieścimy w niej metodę oznaczoną anotacją @Provides, która zwraca utworzony obiekt NetManager:

import dagger.Module;

import dagger.Provides;

@Module

public class NetModule{

@Provides

NetManager providesNetManager(){

return new NetManager();

}

}

W klasie NetComponent w metodzie inject() zmienimy parametr na startową klasę MainActivity:

public void inject(MainActivity mainActivity);

Na koniec w MainActivity w metodzie onCreate pod:

super. onCreate(savedInstanceState);

należy dodać następujący kod:

NetComponent netComponent DaggerNetComponent.create();

netComponent.inject(this);

netManager.sayHello();

Natomiast nad metodą onCreate() należy dodać pole netManager:

@Inject

NetManager netManager;

Jak łatwo można zauważyć, pojawiła się klasa DaggerNetComponent. Jej znaczenie zostanie wyjaśnione później. W tym momencie należy tylko wiedzieć, że ta klasa jest generowana automatycznie w czasie komplikacji. Niestety, w czasie pisania kodu Android Studio nie rozpoznaje klasy, dlatego na początku edytor będzie sygnalizował błąd nieznanej klasy. Żeby ją wygenerować, należy skompilować kod. W tym celu z górnego menu wybieramy:

BUILD -> CLEAN

i następnie:

BUILD -> REBUILD

Po tym kod powinien się poprawnie skompilować. Rezultatem kompilacji będzie utworzenie pliku DaggerNetComponent. Zostanie on umieszczony w katalogu projektu:

app\build\generated\sources\debug\out\com\dagger

Pamiętać należy jednak, że wygenerowanie klasy nie dodaje automatycznie ścieżki import dla klasy w miejscu jej użycia.

4. Jak zainstalować Daggera 2 poza środowiskiem Android?

W celu utworzenia projektu Dagger 2 posłużymy się narzędziami IntelliJ i Gradle. Należy założyć, że są one poprawnie zainstalowane i skonfigurowane. W IntelliJ utworzymy nowy projekt Java o nazwie DaggerSE.

FILE -> NEW -> PROJECT -> JAVA

W utworzonym katalogu o nazwie DaggerSE znajduje się plik build.gradle. Edytuj go. W sekcji:

dependencies{…}

należy dodać następujące wpisy:

implementation „com. google. dagger: dagger:2.32”

anotationProcessor „com. google. dagger: dagger-compiler:2.32”

W chwili pisania najnowszą wersją była ta oznaczona numerem 2.32. Aby sprawdzić, jaka jest najnowsza wersja w momencie czytania tej książki, można wejść na stronę:

https://github.com/google/dagger

i poszukać ikony „maven central”. Przy niej będzie numer najnowszej wersji.

https://mvnrepository.com/artifact/com.google.dagger/dagger

Niestety, IntelliJ nie oferuje bezproblemowego wsparcia dla Daggera 2. Wynika to głównie z budowy tego frameworka, który wykonuje wiele czynności w czasie kompilacji, tworząc też własne pliki klas. Dlatego też potrzebna jest dodatkowa konfiguracja środowiska programistycznego. Najpierw musimy włączyć przetwarzanie anotacji. W tym celu wybieramy:

FILE -> SETTINGS

Następnie wybieramy:

BUILD, EXECUTION DEPLOYMENT -> COMPILERS -> ANOTATIONS PROCESSORS

i zaznaczamy:

ENABLE ANOTATIONS PROCESSING

Na końcu należy zrestartować IntelliJ:

FILE -> INVALIDATE CACHES/RESTART

Należy pamiętać o synchronizacji narzędzia Gradle, które powinno pobrać wszystkie konieczne pliki. W ten sposób dokonane zostało przygotowanie do pracy.

5. Jak przetestować w środowisku IntelliJ, czy instalacja jest poprawna?

Żeby przyspieszyć test, wykorzystamy klasy utworzone wcześniej, tj. klasy NetManager, NetModule, NetComponent. Pliki z tymi klasami należy skopiować do niniejszego projektu. W klasie NetComponent należy zmienić tylko parametr na startową klasę Dagger:

public void inject(Dagger dagger);

Stworzymy też klasę, w której umieścimy referencję do NetManagera. Należy opatrzyć ją anotacją @Inject. Następnie wygenerujemy obiekt DaggerNetComponent, z którego wywołamy metodę sayHello():

import javax.inject.Inject;

public class Dagger{

@Inject

NetManager netManager;

public Dagger (){

NetComponent netComponent=

DaggerNetComponent.create();

netComponent.inject(this);

netManager.sayHello();

}

}

Teraz pora na klasę początkową:

public class Main{

public static void main(String args){

Dagger dagger=new Dagger();

}

}

W klasie Dagger ponownie pojawiła się klasa DaggerNetComponent. W czasie pisania kodu IntelliJ nie rozpoznaje klasy, dlatego na początku edytor będzie pokazywał błąd. Żeby ją wygenerować, należy skompilować kod. W tym celu z górnego menu wybierzemy:

BUILD -> REBUILD

Po tym działaniu kod powinien się poprawnie skompilować. Rezultatem kompilacji będzie utworzenie pliku DaggerNetComponent. Zostanie on umieszczony w katalogu projektu:

Project\build\generated\sources\anotationProcessor\java\main\dagger

Pamiętać należy jednak, że wygenerowanie klasy nie dodaje automatycznie ścieżki import dla klasy w miejscu jej użycia.

6. Jakie błędy najczęściej można napotkać podczas instalacji Daggera 2?

Większość błędów, które można napotkać, wynika z błędów przy napisaniu samego kodu. Niektóre wynikają z braku pobrania potrzebnych bibliotek wskutek nieprzeprowadzenia synchronizacji przez Gradle’a. Poniżej znajdują się najpopularniejsze komunikaty błędów wraz możliwymi przyczynami:

— COMPONENT CANNOT BE RESOLVED TO A TYPE.

Błąd pojawia się w związku z interfejsem oznaczonym anotacją Component. Wynika z braku ścieżki import lub jej nierozpoznania wskutek braku synchronizacji Gradle’a.

— MODULE IS NOT AN ANOTATION TYPE.

Błąd pojawia się w związku z klasą oznaczoną anotacją @Module. Przyczyny jak wyżej.

— COM. DAGGER. XXX CANNOT BE PROVIDED WITHOUT AN @INJECT CONSTRUCTOR OR AN @PROVIDES-ANOTATED METHOD.

Błąd najczęściej występuje dopiero podczas pracy z Daggerem 2, gdy nie oznaczymy konstruktora anotacją @Inject lub nie zapewnimy w module metody z anotacją @Provides. Wystąpi też, gdy w interfejsie oznaczonym anotacją @Component brak parametru o nazwie module wskazującego na klasę modułu.

— CANNOT RESOLVE SYMBOL DAGGERNETCOMPONENT.

Błąd występuje zawsze po stworzeniu kodu implementującego interfejs komponentu, ale przed kompilacją. Jeżeli występuje po kompilacji, oznacza wadliwe dodanie bibliotek lub nieoczyszczenie projektu ze starej kompilacji.

— DAGGER.INTERNAL.CODEGEN. COMPONENTPROCESSOR WAS UNABLE TO PROCESS THIS CLASS BECAUSE NOT ALL OF ITS DEPENDENCIES COULD BE RESOLVED. CHECK FOR COMPILATION ERRORS OR A CIRCULAR DEPENDENCY WITH GENERATED CODE.

Pochodny błąd wadliwej instalacji Daggera 2. Występuje najczęściej wtedy, gdy Dagger nie generuje wszystkich potrzebnych klas.