В данной статье рассматривается использование специализированного модуля Dagger 2 под android и подразумевается, что у вас есть наличие базовых знаний по Dagger 2. В Dagger 2.10 был представлен новый модуль специально для Android. Данный модуль поставляется как дополнение, состоящий из дополнительной библиотеки и компилятора.
В версии 2.11 были некоторые небольшие изменения, в частности некоторые классы, были переименованы, поэтому будет использоваться именно эта версия. Рассмотрим некоторые особенности Dagger 2, которые будут применяться в примерах.  У нас появилась возможность писать статические @Provides методы: Основное отличие статического @Provides метода от обычного в том, что он дергается компонентом напрямую, а не через инстанс модуля. Статические @Provides методы можно использовать как в абстрактном, так и в обычном классе модуля. Статические методы могут быть scope и unscope.  Dagger 2 позволяет нам предоставлять зависимости без наличия @Provides методов. Это достигается путем наличия @Inject над конструктором у класса, который нам необходимо создать. Рассмотрим пример: При таком подходе мы можем писать в качестве типа конкретный класс, мы не можем запросить зависимость по интерфейсу NewsRepository. Dagger 2 не сможет найти нужную реализацию для данного интерфейса. Для того чтобы обойти это ограничение, нам необходим @Binds, для того чтобы забайндить(привязать) реализацию к интерфейсу. Особенности @Binds: Пример: Теперь мы можем смело писать следующее: Модули представленные в виде абстрактных классов имеют следующие особенности:  При использовании @Binds + @Inject над конструктором у нас нет необходимости писать и реализовать полностью @Provides методы.  Если в модуле методы только для байндинга (@Binds), то имеет смысл сделать этот модуль в виде интерфейса: Типичное android приложение использующая Dagger 2 выглядит примерно так: Также могут быть получение саб компонентов для разных скоупов (например Activity scope, Fragment scope).  Отсюда вытекают такие проблемы: Эту проблему решает новый модуль для android.  Нельзя просто подключить зависимости только относящиеся к android. Они идут как дополнение. Как известно аннотацией @Scope и её наследниками помечаются методы в модулях, а также компоненты/сабкомпоенты, которые предоставляют необходимые нам зависимости.
@Scope определяет время жизни создаваемых(представляемых) объектов, тем самым представляют эффективное управление памятью. Рассмотрим пример структуры приложения по скоупам: В данном примере под Facade подразумевается аналог UseCase/Interactor. Приложение имеет структуру состоящую из 3х скопов для демонстрации как это можно применить с помощью нового модуля Dagger 2. Также здесь рассмотрен вариант с использованием исключительно с аннотацией @ContributesAndroidInjector. Приступаем к реализации: 1. Определим наш главный модуль. В данный модуль было добавлено следующее: 2. MainActivityModule При использовании AndroidInector, нам будет доступен инстанс активити, т.к. данная активити является частью графа.Происходит это потому, что мы вызываем AndroidInjection.inject(this), тем самым передаем инстанс активити (см. ниже).  Пример получение инстанса активити в качестве зависимости. 3. Напишем наш root компонент, который будет содержать наш AppModule, а также единственный инжект в Application. 4. Необходимо реализовать интерфейс HasActivityInjector в Application и заинжектить диспечер AndroidInector’ов. DispatchingAndroidInjector нужен для поиска AndroidInector для конкретного Activity. 5. Теперь мы можем всем этим воспользоватся Как мы видим здесь нет никаких компонентов и сабкомпонентов, но при этом у нас есть возможность получение зависимостей с разными скоупами. К тому же у нас есть роутер, для создания которого необходим(в качестве зависимости) сам инстанс активити. Конструкцию AndroidInjection.inject(this) можно вынести в базовый класс и так же все будет работать. Как это работает? При вызове AndroidInjection.inject(this), Dagger 2 получается доступ к Application который реализует интерфейс HasActivityInjector, где через диспетчер находит нужный AndroidInector (сабкомпонент активити) по классу активити и затем производит инициализацию зависимостей с нужным скоупом. 6. Перейдем к реализации @FragemntScope. Нам необходимо обновить наш MainActivityModule: Мы добавили аналогичную конструкцию AndroidInject для фрагмента, как мы делали для активити.
Таким образом для нас будет сгенерирован AndroidInject (сабкомпонент) для конкретного фрагмента с скоупом @FragmentScope. Нам будут доступны зависимости @Singleton, @ActivityScope которые указаны в данном модуле и те что указаны в качестве модулей для данного фрагмента. 7. Добавим базовую активити и реализацию интерфейса HasSupportFragmentInjector. По аналогии с Application, активити у нас будет выступать диспетчером AndroidInjector, который будет нам предоставлять нужный нам для фрагмента AndroidInjector (сабкомпонент). 8. MyFragmentModule Точно так же, как с активити, мы используем AndroidInjection (AndroidSupportInjection, если используем библиотеку поддержки), нам доступен инстанс фрагмента, т.к. он является частью графа, мы можем передавать ее в качестве зависимости, а также забайндить на какой нибудь интерфейс. Пример презентера: 9. Инджектим в фрагмент Конструкцию AndroidSupportInjection можно вынести в базовый класс. По моему мнению, новый модуль android-dagger предоставляет более правильное предоставление зависимостей для android. Мы можем вынести в базовые классы методы инъекции, получили более удобное разделение по скоупам, нам не надо пробрасывать сабкомпоненты и у нас стали доступны в графе зависимости объекты активити и фрагмента, которые мы можем использовать в качестве внешней зависимости, например в presenter'e. Пример на GitHub
Часть 2 Java EE, Android