В этом завершающем уроке обсудим, что нам удалось узнать. А в конце урока я оставлю список полезных ссылок для дальнейшего изучения темы мультимодульности и даггера.

Урок 1
Мы выяснили, что классы разных модулей не видят друг друга, пока мы не добавим зависимости. Причем зависимость можно создать только в одну сторону.

Урок 2
При использовании даггера перед нами стоит выбор, где создавать даггер-модуль и компонент. Ситуации и проекты бывают разные, но для начала можно исходить из того, что даггер-модуль создаем в том же модуле, где и создаваемый объект. А компонент - в том модуле, где находится объект, в который выполняется инджект.

Урок 3
Чтобы лучше понимать действия даггера, мы создали и использовали свою реализацию компонента. Внутри все оказалось несложно. Компонент создает модули и использует их для создания объектов.

Урок 4
Компонент при создании объекта Database из модуля data использовал объект App из модуля app. Хотя зависимость между этими модулями прописана в другую сторону. Секрет в том, что Database не знал, что получил App. Он думал, что работает с Context.

Урок 5
Когда компонент создает объект, он должен знать класс не только этого объекта, но и всех других, который используются в процессе создания. В нашем примере, чтобы создать объект Database из модуля data, компонент был должен знать и про FileManager из модуля core.

Урок 6
Фрагменту из модуля task понадобилось использовать компонент из модуля app, хотя модуль app зависит от task. Снова у нас использование объекта вопреки направлению зависимости. Чтобы решить проблему, мы создали интерфейсы в модуле task и обернули в них классы в модуле app. После этого в модуле task мы смогли работать с этими объектами.

Уроки 7, 8, 9
Мы рассмотрели три варианта конфигурации компонента

Конфигурация компонента

Первый вариант (урок 7)

App компонент из модуля app используется для инджекта во фрагмент в модуле task

Этот вариант дает нам следующие минусы:
- только Application scope
- App компонент знает и умеет слишком много (при большом количестве фрагментов)
- модуль app должен знать все модули, которые потребуются для создания объектов
- размер сгенерированного класса компонента получится огромным (при большом количестве фрагментов/объектов)

Второй вариант (урок 8)

Создаем сабкомпонент в модуле task и используем его для инджекта во фрагмент в модуле task. Родителем сабкомпонента является App компонент.

Этот вариант исправляет первые два минуса из четырех:
+ мы получаем более гибкий scope, сабкомпонент можно привязать к времени жизни фрагмента
+ с App компонента убрали методы инджекта во фрагменты, он стал значительно проще (при большом количестве фрагментов/объектов)

Третий вариант (урок 9)

Создаем отдельный компонент в модуле task и используем его для инджекта во фрагмент в модуле task. App компонент используем, как dependency.

Этот вариант исправляет два оставшихся минуса:
+ модуль app теперь может не знать про модули, которые используются только в модуле task
+ размер сгенерированного класса компонента стал значительно меньше (при большом количестве фрагментов/объектов)

Ссылки

Надеюсь после этого материала вы стали лучше понимать, как можно использовать даггер в мультимодульном проекте. Если есть желание копать тему дальше, то вот вам список ссылок для дальнейшего изучения темы:

Репозиторий с подборкой ссылок

Еще раз про многомодульность Android-приложений

Модульность и DI в современном Android-приложении. Большой туториал от Яндекса

Многомодульность в Android и Dagger: пошаговый пример

Многомодульный BDSM: стоит ли внедрять Gradle модули и какие типы модулей бывают?

Иерархия модулей: как выстроить связи между модулями в Android

Android Dagger with a MultiModule structure

Multi-module navigation with Dagger2

Scalable Navigation in multi-module projects