Какие знаешь Dagger-компоненты?

Компоненты в Dagger 2

В Dagger 2, современной и наиболее распространенной версии фреймворка для dependency injection на Android, компоненты являются центральным элементом, связывающим поставщиков зависимостей (модули) с классами, которые их запрашивают. Они выступают в роли графа зависимостей и отвечают за инжектирование.

Основные типы компонентов

1. Компоненты (Components)

Это интерфейсы или абстрактные классы, которые Dagger реализует автоматически. Они определяют, какие зависимости могут быть предоставлены и в какие классы их можно инжектировать.

Ключевые аннотации и параметры:

• @Component: Основная аннотация для создания компонента. Указывает на модули и зависимости от других компонентов.
• modules: Параметр для указания списка модулей, которые снабжают компонент зависимостями.
• dependencies: Параметр для указания родительских компонентов, от которых данный компонент может запрашивать зависимости (способ композиции компонентов).

Пример простого компонента:

@Component(modules = [StorageModule::class, NetworkModule::class])
interface ApplicationComponent {
    // Методы для инжектирования в классы
    fun inject(activity: MainActivity)
    fun inject(fragment: DetailsFragment)

    // Методы для предоставления зависимостей "наружу" (например, для других компонентов)
    fun repository(): Repository
}

2. Субкомпоненты (Subcomponents)

Это компоненты, которые наследуют и расширяют граф зависимостей своего родительского компонента. Они являются частью родительского компонента и видят все его зависимости. Это основной способ организации скоупов (областей видимости) в Dagger.

Ключевые особенности:

• Объявляются с аннотацией @Subcomponent.
• Не имеют параметров dependencies. Вместо этого они объявляются во "вложенном" интерфейсе родительского компонента с помощью фабрики или билдера.
• Имеют свой собственный жизненный цикл, который короче или равен жизненному циклу родителя.

Пример субкомпонента для экрана:

@Subcomponent(modules = [ViewModelModule::class])
interface ActivitySubcomponent {
    fun inject(activity: MainActivity)

    @Subcomponent.Factory
    interface Factory {
        fun create(): ActivitySubcomponent
    }
}

// Родительский компонент должен объявить фабрику для создания субкомпонента
@Component(modules = [...])
interface ApplicationComponent {
    fun activityComponentFactory(): ActivitySubcomponent.Factory
}

Специализированные компоненты (на основе скоупов)

На практике компоненты часто организуют по скоупам (scope), что позволяет управлять временем жизни объектов. На Android это обычно соответствует жизненному циклу частей приложения.

• @Singleton / Компонент уровня приложения (ApplicationComponent): Существует все время жизни приложения. Обычно создается в классе Application. Содержит глобальные синглтоны: Retrofit, OkHttpClient, Database, SharedPreferences.
• Компонент уровня активности (ActivityComponent) (часто как субкомпонент): Существует, пока жива Activity. Может иметь свою аннотацию скоупа, например, @ActivityScope. Содержит зависимости, общие для всех Fragment внутри этой Activity.
• Компонент уровня фрагмента (FragmentComponent) (часто как субкомпонент от ActivityComponent): Существует вместе с Fragment. Может иметь скоуп @FragmentScope. Инжектит зависимости, специфичные для данного фрагмента.
• Компонент уровня ViewModel: Может использоваться для инжектирования зависимостей в ViewModel с помощью ViewModelProvider.Factory.

Концепции, связанные с компонентами

1. Скоупы (@Scope): Аннотации (например, @Singleton, @ActivityScope), которые привязывают время жизни объекта к времени жизни компонента. Объект, созданный в скоупированном компоненте, будет существовать, пока существует сам компонент, и будет переиспользоваться при повторных запросах внутри этого компонента.

2. Модули (@Module): Классы, которые "сообщают" компоненту, как создавать те или иные объекты. Используют методы с аннотациями @Provides, @Binds и @IntoSet/@IntoMap.

3. Интерфейсы доступа (Провайдеры): Методы в компоненте, возвращающие зависимость (как fun repository(): Repository в первом примере). Полезны для получения зависимостей, когда инжектирование через поля невозможно (например, в Service или ContentProvider).

Сравнение подходов: dependencies vs subcomponents

Эволюция в Dagger-Hilt

С появлением Hilt (обертка над Dagger для Android) ручное создание и связывание компонентов было значительно упрощено. Hilt предоставляет предопределенный набор стандартных компонентов, привязанных к жизненному циклу Android:

• @Singleton / ApplicationComponent
• @ActivityRetainedScoped / ActivityRetainedComponent
• @ActivityScoped / ActivityComponent
• @ViewModelScoped / ViewModelComponent
• @FragmentScoped / FragmentComponent
• @ViewScoped / ViewComponent
• и другие.

Разработчик лишь аннотирует свои классы (@AndroidEntryPoint) и модули (@InstallIn), указывая, в какой стандартный компонент их установить, а всю кодогенерацию и создание графа Hilt берет на себя.

Итог: Понимание компонентов — это понимание того, как организован граф зависимостей, как управляется время жизни объектов и как разные части приложения получают доступ к общим или приватным зависимостям. От правильной организации компонентов напрямую зависит поддерживаемость, тестируемость и производительность приложения.