Первоначальный шаг для создания области для вашего конкретного варианта использования
Как рекомендует команда Android, если ваше приложение содержит три или меньше экранов, вы можете обойтись без DI. Но при наличии более трех экранов всегда рекомендуется использовать DI.
Dagger - лучший выбор для реализации DI в приложениях Android до сих пор. Но это изменится, поскольку команда Android решила создать новую библиотеку DI поверх Dagger, известную как Hilt. Все об этом можно прочитать здесь.
Если быть точным, Hilt - это андроид-версия Dagger. Проблема в том, что это все еще на ранних стадиях. Он имеет несколько ограничений, таких как ограниченное количество областей видимости, например, при использовании вложенных фрагментов.
Что такое объем?
Когда дело доходит до реализации DI, область действия - это не что иное, как ограничение конкретного ресурса конкретным временем жизни контейнера. Прицелы могут быть очень мощными, но дорогими.
Они могут экономить память, высвобождая ненужные ресурсы по окончании срока службы контейнера. С другой стороны, они могут не использовать системные ресурсы, если мы не будем осторожны при оценке зависимостей.
Чтобы понять это еще лучше, давайте рассмотрим простой пример: привязка объекта Apple к времени жизни объекта Fruits означает, что у него всегда будет один и тот же экземпляр Apple.
Прицел в рукоять
В Hilt мы можем привязать зависимости и ресурсы к контейнерам и компонентам с помощью аннотаций. Проблема в том, что у него всего несколько аннотаций к области видимости. Взгляни:
Например, у вас есть класс под названием DataManager в приложении, в котором вы поддерживаете состояние пользователя и другие детали, которые вам нужны на протяжении текущего сеанса. Это означает, что нам нужен тот же экземпляр DataManager вне приложения. Этого можно добиться с помощью ApplicationComponent (контейнера, поддерживаемого жизненным циклом приложения). Это гарантирует, что мы получим тот же экземпляр DataManager.
Примечание. По умолчанию привязки в Hilt без области действия . Они не являются частью какого-либо компонента, и к ним можно получить доступ на протяжении всего проекта. Каждый раз при запросе будет предоставляться другой экземпляр этого типа. Когда вы ограничиваете привязку к компоненту, он ограничивает, где эта привязка может быть использована и какие зависимости может иметь тип.
Работа с Android
В Android мы можем реализовать область видимости, используя преимущества фреймворка. В этом разделе мы можем увидеть, как реализовать область видимости в Android и как она отображается в Hilt.
Чтобы лучше понять это, давайте рассмотрим общий вариант использования, когда нам нужно ограничить адаптер определенным компонентом действия. Мы можем обойтись без помощи любой библиотеки DI. Взгляни:
class SampleActivity : AppCompatActivity() {
private val moviesAdapter = MoviesAdapter()
...
}
В приведенном выше фрагменте кода moviesAdapter переменная ограничена жизненным циклом SampleActivity. Каждый раз, когда мы запрашиваем moviesAdapter, будет возвращен один и тот же экземпляр.
Мы можем добиться этого с помощью Hilt, используя простую аннотацию - ActivityScoped над классом адаптера. Взгляни:
Но здесь возникает проблема: при изменении конфигурации активности создается новый экземпляр адаптера, потому что мы связываем адаптер с жизненным циклом активности. Тот же результат с Android и подходом Hilt.
Определение объема с помощью ViewModel
Лучшее решение для moviesAdapter, чтобы выжить при изменениях конфигурации, - это использовать модель представления архитектурных компонентов. Самое важное, что нам нужно иметь в виду, это то, что модель представления переживет изменения конфигурации.
Без использования какой-либо библиотеки DI мы можем поддерживать адаптер в рабочем состоянии, перемещая его в модель представления. Взгляни:
Мы воспользовались системой и переместили объявление адаптера из активности в модель представления, чтобы она пережила изменения конфигурации.
Мы можем сделать то же самое, применив аннотацию Hilt ActivityRetainedScoped к классу MoviesAdapter. Взгляни:
Определение объема с рукояткой и ViewModel
Преимущество определения области с помощью Hilt состоит в том, что типы с областью видимости используются в иерархии компонентов Hilt из коробки, тогда как сила подхода ViewModel заключается в ручном доступе к типам с областью действия из ViewModel. Преимущество определения области видимости с помощью ViewModel состоит в том, что вы можете иметь ViewModels для любых LifecycleOwner объектов в вашем приложении.
Вывод
Мы видели, как ограничить ресурс конкретным контейнером без какой-либо библиотеки DI. Обзор, который мы сделали в этой статье, может быть реализован с помощью Hilt прямо из коробки, но этот подход должен дать вам представление о том, как создавать объемы вашего костюма, поскольку Hilt предоставляет ограниченное количество областей.
Как уже говорилось, определение объема - дорогостоящая операция, если вы выполните ее безупречно, она снизит производительность, иначе она может истощить системные ресурсы и потенциально повлиять на производительность приложения. Так что будьте внимательны при определении объема ресурсов в своем приложении.
Бонус
Чтобы узнать больше о внедрении зависимостей, прочтите следующие статьи.
- « Внедрение зависимостей в Android с помощью Dagger2 »
- « Hilt - Новая библиотека внедрения зависимостей для Android »
- « Koin - Kotlin Native Dependency Injection Library »
- « Koin - библиотека для внедрения собственных зависимостей Kotlin (часть 2) »
Чтобы узнать больше об адаптерах в Android, прочтите следующие статьи:
- « Создание реактивного и гетерогенного адаптера в Котлине »
- « Эволюция адаптеров в Android »
- « Как последовательно объединить адаптеры в Android »
- « Android RecyclerView с закрытыми классами Kotlin »
На этом пока все, надеюсь, вы узнали что-то полезное, спасибо за чтение.
Если есть сомнения, напишите мне в твиттер.
