Намери подобно съдържание

🤯Вышел Dagger 2.57 и из полезных изменений там... НИЧЕГО. Просто работают под капотом. Может над поддержкой KSP, может еще над чем Вам нужен Dagger? #dagger#di

Разработчик из Ozon делится опытом, как организовали с помощью фич языка Kotlin хранилище Dagger-компонентов, доступное из любого модуля, управляющее их жизненным циклом и забравшее другую рутину на себя. #android#dagger#di

Как найти неиспользуемые зависимости в Dagger Component (EN,11м) С помощью Dagger SPI автор написал анализатор графа Dagger c целью поиска неиспользуемых зависимостей и описал подход в статье. Также подход можно использовать для визуализации графа зависимостей, считать разные метрики графа и пр. 🐱Исходный код на GitHub 🔗Альтернативная ссылка #dagger#di#opensource

🤯Не нужно делать инжект всех зависимостей в конструктор Встретил код в проекте: class MyViewModel( ... private val sendDataUseCase: SendDataUseCase, ... ): ViewModel() { // Вызывается, когда пользователь в UI нажмёт на "Send" fun onSendClicked(...) { viewModelScope.launch { sendDataUseCase.invoke(...) // либо sendDataUseCase(...) } } } sendDataUseCase не нужен сразу при создании объекта, а нужен только если пользователь нажмёт на кнопку "Send" в UI, что может и не произойти. Так как эта зависимость нужна в конструкторе, то при получении в DI будет сразу происходить создание этой зависимости, что приводит к ненужной нагрузке. Я рекомендую делать отложенное получение зависимостей с помощью механизма Provider или Lazy. Первый будет ходить за зависимостью в граф каждый раз, а второй - при первом обращении и сохранит её. // При использовании Dagger или Hilt class MyViewModel( ... private val sendDataUseCase: javax.inject.Provider<SendDataUseCase>, // или dagger.Lazy ... ): ViewModel() { fun onSendClicked(...) { viewModelScope.launch { sendDataUseCase.get() .invoke(...) } } } Если вы используете Koin на момент написания поста (актуальная версия 4.0), делать отложенный инжект в конструктор возможности нет: // При использовании Koin class MyViewModel(): ViewModel() { // отложенное получение зависимости в Koin private val sendDataUseCase: SendDataUseCase by inject() fun onSendClicked(...) { viewModelScope.launch { // аналог Provider - получение зависимости каждый раз из графа val sendDataUseCase: SendDataUseCase = getKoin().get() sendDataUseCase.invoke(...) } } } Результат оптимизации ✅ более быстрый старт экранов (зависит от сложности графов) ✅ уменьшение расхода памяти ❌ KOIN потеря явной зависимости в конструкторе. Мне бы очень хотелось увидеть аналог Provider и Lazy в Koin через конструктор, но пока приходится делать свои обертки 😔 #dagger#di#лучшиепрактики

🤯Dagger Hilt блокирует переход на AGP 9.0 UPD. 21 января вышел Dagger 2.59 с поддержкой AGP Android Gradle Plugin 9.0 официально зафиксировал новый стабильный конфигурационный API (вышла стабильная версия с релизом AS Otter FD 3) — это одно из самых значимых изменений в инфраструктуре Android и Kotlin Multiplatform за последние годы. Цели понятны и правильные лучше работа с кэшем и общая скорость сборок. Подробнее про все изменения я писал в отдельном посте Google несколько релизов подряд аккуратно готовил экосистему к этому переходу, заранее добавив новый API и дав время авторам плагинов адаптироваться. Но на практике всё упирается в плагины. Я столкнулся с тем, что Gradle-плагин Dagger Hilt до сих пор использует старую модель конфигурации и несовместим с новым DSL из AGP 9.0. В результате проект нельзя перевести на новую версию без отключения Hilt или включения режим совместимости. Иронично, что именно официальный инструмент от Google сейчас становится блокером для обновления. Да, в AGP оставили compatibility-флаги, позволяющие продолжать сборку по старым правилам. Это спасает проекты от немедленного падения, но полностью отключает все ключевые преимущества AGP 9.0 — configuration cache, ускоренную конфигурацию и новую модель плагинов. 💬 Вы уже пробовали миграцию на AGP 9.0? Что блокирует? Делитесь в комментариях мнением. UPD. По заявлениям подписчиков также есть проблемы в работе KAPT и KSP #Android#AndroidDev#Gradle#Dagger#Hilt

🤖 Если вы искали альтернативу Dagger/Hilt, но с поддержкой Kotlin Multiplatform, то как раз вышла свежая версия Koin Annotations, которая значительно упрощает миграцию! #dagger#hilt#koin

🤖Альтернативный способ обработке one-off событий из ViewModel (EN, 10м) В статье рассказывается в чем сложность с обработкой одноразовых событий, которые надо передать из ViewModel в UI. Автор рассматривает способ через callback интерфейс в конструкторе ViewModel @HiltViewModel class MyViewModel @Inject constructor( // inject the interface private val toastMessages: ToastMessages, ) : ViewModel() { fun doSomething() { viewModelScope.launch { try { // execute async operation here } catch (e: CustomException) { // initiate a one-off event toastMessages.showToast(e.localizedMessage) } } } } 🔗 Альтернативная ссылка на статью #android#viewmodel#dagger#hilt

‼️Не тяните зависимости из графа сразу! Одна из частых ошибок при использовании DI — получать все зависимости из графа сразу (например, в конструкторе класса). Так делать не стоит 😬 Получение зависимости из графа — это каскадный процесс, и он должен выполняться только в момент использования. Поэтому я всегда рекомендую инжектить зависимости для Dagger/Hilt через Lazy (не путайте с kotlin.Lazy) или Provider. class ViewModel @Inject constructor( // Зависимость получается из графа сразу при создании private val useCase: DataUseCase, // Получаем зависимость из графа каждый раз при обращении Provider.get() private val useCaseFactory: Provider<DataUseCase>, // Получаем зависимость из графа при первом обращении // и затем она кэшируется в Lazy объекте private val useCaseLazy: Lazy<DataUseCase>, ) 💡 Чтобы перейти на Lazy без боли в существующем коде — можно использовать делегаты свойств в Kotlin: // Вариант использования без Lazy class ViewModel @Inject constructor( private val useCase: DataUseCase ) // Миграция на Lazy без потери API совместимости class ViewModel @Inject constructor( useCaseFactory: Lazy<DataUseCase>, ) { private val useCase: DataUseCase by useCaseFactory } И небольшой хелпер, чтобы это работало красиво 👇 // Функция расширения для использования property делегата operator fun <T> Lazy<T>.getValue(thisRef: T, property: KProperty<*>): T = get() Таким образом, вы снижаете нагрузку на DI граф, откладываете инициализацию и избегаете ненужных каскадов при старте компонентов. #di#dagger#hilt#лучшиепрактики

🚀Cash App перевел Android-приложение на Metro — новый DI фреймворк для Kotlin Команда Cash App (Block) успешно мигрировала своё Android-приложение с Anvil/Dagger на Metro — современный фреймворк для dependency injection, разработанный Zac Sweers. Metro — это compile-time DI фреймворк, вдохновленный Dagger и Anvil, но реализованный как Kotlin compiler plugin. Он Kotlin-first, поддерживает K2 и работает значительно быстрее традиционных решений. Вобрал в себя всё лучшее от Dagger, Anvil и Kotlin-Inject Почему перешли на Metro? - Скорость сборки — ускорение инкрементальных сборок на ~60% - Поддержка Kotlin K2 — возможность использовать новейший компилятор Kotlin - Упрощение стека — отказ от kapt и Java-ориентированных инструментов - Современный подход — Kotlin-first дизайн и улучшенный DX - Более строгая валидация DI-графа - Улучшена безопасность типов (нуллабельность) - Поддержка KMP 📊 Результаты по скорости сборки: - Инкрементальные сборки → ускорение на 58-60% - Чистые сборки → ускорение на 17% - ABI-изменения → сборка за 11.9s вместо 28.8s Миграция 1500 модулей проводилась постепенно с двойной поддержкой двух DI фреймворков для безопасного перехода. В зависимости от настройки Gradle менялся DI и генерация кода. Впервые вижу подход, когда был описан граф для 2 разных DI с целью постепенной миграции. Миграцию с Koin на Metro так не сделать, но вот с Koin Annotations на Metro вполне может получится. #DI#KMP#Dagger#Metro#Android#AndroidDev#Anvil