Dagger 2 - typowy przykład

Od jakiegoś czasu próbuję ogarnąć różne wzorce, ORM'y i biblioteki.
Ze wszystkim idzie ok, natomiast paradoksalnie najłatwiejszego, Daggera nie jestem w stanie pojąć.
Przykłady oferowane w internetowych poradnikach sa dla mnie totalnie niezrozumiałe.

Czy ktoś jest w stanie pokazać mi typowy przykład użycia Daggera w aplikacji Androidowej?
Typowy czyli nie jakiś banalny, ale zawsze używany, bez którego byłoby po prostu więcej zbędnego kodu.
No chyba, że zawsze używane są banalne :)

Projekty w których brałam udział nie posiadały tej biblioteki.
Dodam jeszcze, że wtrzykiwanie zależności, czyli wstrzykiwanie obiektów przez konstruktor rozumiem, a przynajmniej tak mi się wydaje :)

Dagger2 wbrew pozorom to wcale nie jest łatwy framework. To że jest mniej kodu dla Ciebie, nie znaczy że tak faktycznie jest. Kiedy spojrzy się na klasy generowane, to jak działają komponenty, moduły wprowadza w osłupienie. Ja korzystam z daggera na codzień i jest to dla mnie kobyła, której nie jestem w stanie ogarnąć do końca i pewnie nawet w połowie. Oczywiście, podstawowe rzeczy znam, wiem jak użyć i jak działa, ale jeśli zagłębić się w to, to nie jest tak różowo.

Jako przykład podam tutaj:
https://github.com/hammad-tariq/mvp-architecture-kotlin-dagger-2-retrofit-android/tree/master/app/src/main/java/com/es/developine/di

taki standardowe wykorzystanie daggera. Można do tego jeszcze dołożyć wstrzykiwanie jakiś prezenterów do Activity (bo w Androidzie da się to zrobić) plus jakieś serwisy, ale to wszystko na tej samej zasadzie się robi.

Chyba najbardziej wyłapkowany przykład jaki znalazłam:

//        Mannual DI
//        Starks starks = new Starks();
//        Boltons boltons = new Boltons();
//        War war = new War(starks,boltons);
//        war.prepare();
//        war.report();

//      Using Dagger 2
        BattleComponent component = DaggerBattleComponent.create();
        War war = component.getWar();
        war.prepare();
        war.report();

no i do tego musimy dodać 2 linijki w gradlu + zrobić component z interfejsem - wielki mi skrót.

Ja mam takie uproszczenie w stosunku do "ich" manual DI:

      War war = new War(new Starks(), new Boltons());
        war.prepareForWar();
        war.reportForWar();

w czym to jest gorsze ?

W niczym nie jest gorsze to, co napisałaś. Mogą się pojawić natomiast dwa problemy. Po pierwsze jak chcesz współdzielić np. instancję klasy War pomiędzy dwiema aktywnościami, skoro nie masz dostępu do konstruktora poniżej SDK 28? Tak swoją drogą to ten przykład, który wkleiłaś jest ok, żeby pokazać jak użyć Daggera, ale beznadziejny, żeby pokazać po co.

Druga sprawa jest taka, że w typowej aplikacji takich zależności może być setki jak nie tysiące. Ręczne zarządzanie tym stanie się na pewnym etapie zbyt czasochłonne.

Pytanie do Ciebie - czy wiesz jak Dagger działa? Może musisz najpierw zbadać ten aspekt.

Wklejam link do małej aplikacji z użyciem Daggera, która ostatnio pisałem na weekend. https://github.com/MiSikora/LuckyStrike

Jestem w procesie nauki jak działa Dagger.
A co do jednej instacji dla dwóch aktywności, w czym gorszy będzie singleton ?

No właśnie to powinien być singleton (albo jedna instancja o odpowiednim zasięgu istnienia). Tylko teraz pytanie jak chcesz utworzyć tę jedną instancję i przekazać ją do aktywności, zakładając że ten singleton też będzie miał swoje zależności. A te zależności będą miały swoje zależności i niektóre też powinny być singletonami z jakichś tam względów. Przykładowo.

public final class MyActivity {
  Presenter presenter;
}

final class Presenter {
  private final DataDao dataDao; // Tworzone na podstawie bazy SQL.
  private final WebService webService; // Tworzone za pomocą Retrofita.

  Presenter(DataDao dataDato, WebService webService) {
    this.dataDao = dataDao;
    this.webService = webService;
  }
}

Masz aktywność, która otrzymuje prezenter. Prezenter nie musi być singletonem, bo nie jest stanowym obiektem ani nie jest kosztowne utworzenie go. Prezenter potrzebuje jakiś DataDao i WebService. WebService nie musi być singletonem, ale lepiej, żeby był, bo utworzenie go kosztuje dużo zasobów. DataDao to lekki wrapper dający dostęp do bazy danych w bezpieczny sposób. Nie musi być on singletonem, ale baza danych jak najbardziej powinna (kosztowne utworzenie i nie ma sensu tworzyć kilku z punktu widzenia działania aplikacji). Teraz dodajmy do tego, że inna aktywność ma swój własny prezenter, też korzysta z DataDao i innego serwisu też tworzonego przez Retrofita. No to musimy mieć jedną instancję Retrofita gdzieś w aplikacji. I tak dalej.

Można sobie z tym poradzić pisząc własne fabryki i dbając o odpowiedni zasięg obiektów. I powinno się tak to robić. Tylko, że to jest bardzo żmudne, łatwo zrobić czeski błąd przy pisaniu takiego kodu i taki kod sam w sobie nie ma za dużo wartości. Tutaj przychodzi z pomocą Dagger, bo w trakcie kompilacji generuje za Ciebie kod, który będzie optymalny. Sam pisze te fabryki i Twoje zadania sprowadza się tylko do odpowiedniego zbudowania grafu powiązań między klasami. Dodatkowo Dagger ma dużo innych mechanizmów dostarczania zależności, których pisanie ręcznie w razie potrzeby skutkowałoby koszmarną ilością ręcznie pisanego kodu. Jeżeli nie przemawia to do Ciebie, to spróbuj napisać na Androidzie kod bez Daggera, który będzie dostarczał kilka zależności jak z mojego przykładu. Wymaganie jest takie, żebym klasy mógł łatwo przetestować i żeby kod nie był zatamowany przez to, że na sztywno ma powrzucane zależności. Zobaczysz wtedy, jak dużo bezsensownego kodu musiałabyś napisać, żeby to dobrze działało.

Z lekkich rzeczy mogę bardzo polecić pierwsze 5 minut poniższej prezentacji. Pozostałe też są warte uwagi, ale są bardziej specyficzne dla Daggera i jak go optymalizować.

Jest też sporo fajnych prezentacji od Jake'a Whartona, Gregorego Kicka, Rona Shapiro i kilku innych osób, ale nie chcę ich polecać, bo skupiają się głównie na zaletach albo wnętrznościach Daggera, co nie jest aż tak ważne.