#dagger2 — Public Fediverse posts

Как нарезать Android-монолит с помощью compile-time плагинов?

Привет на связи Федотов Михаил и Абдульманов Эдуард, мы технические лидеры Android разработки в Альфа-Банке и занимаемся приложением для физических лиц. В этой статье вспомним наш опыт разбиения большого монолитного android приложения на мини-приложения срезки, занимались мы этим уже довольно давно, но тема все равно актуальная. Переход к таким мини-приложениям позволяет ускорить конфигурацию Gradle и уменьшить время компиляции проекта как локально так и на CI. Думаю это будет полезно тем кто интересуется архитектурой android приложений, KSP, Dagger, а также тем у кого крупное многомодульное приложение и есть проблемы с производительностью работы Gradle в проекте.

https://habr.com/ru/companies/alfa/articles/1002998/

#ksp #dagger2 #архитектура #compiletime #performance #inversion_of_control

Почему я перешел на Dagger Components (вместо Dagger Android)

Всем привет, меня зовут Анатолий Спитченко, я Android-разработчик в ПСБ. В этой статье расскажу про свои эксперименты с Dagger. Наткнувшись в проекте на огромный модуль Application (11,5 Мб), я стал искать альтернативы обертке Dagger Android. Поэкспериментировал с продвигаемым Google Dagger Hilt, а также с более старым подходом — Dagger Components. Последний, как ни странно, позволяет немного сократить Application и в целом имеет больше плюсов, чем минусов. Подробности под катом.

https://habr.com/ru/companies/psb/articles/979988/

#android #java #dagger #разработка_приложений #разработка_под_android #разработка_мобильных_приложений #kotlin #gradle #dagger2 #dependency_injection

Компактный runtime-DI для Java: JSR-330, Class-File API и миграция за 2 дня

Когда начинал разработку системы многомерного анализа данных временных рядов Dimension-UI , для внедрения зависимостей в исходном коде решил использовать Dagger 2. Практический опыт показал, что для приложений с большим количеством динамически создаваемых объектов инверсия зависимостей, реализованная в Dagger 2, не подходит. Да, создание графа зависимостей в compile-time — это, во-первых, очень быстро, и, во-вторых, удобно: получаешь сообщения об ошибках конфигурации уже при компиляции. Но накладные расходы на сопровождение всего этого хозяйства – прямо скажем, это боль. Чтобы реализовать scope-зависимости, приходится писать и поддерживать много инфраструктурного кода внутри объектов, куда мы внедряем зависимости. В Dagger 2 такая реализация, во-первых, «загрязняет» код, а во-вторых, серьезно осложняет тестирование. Изолировать методы удобным способом не получается: в тестах нужно писать очень много кода, чтобы прокинуть необходимый контекст и корректно мокировать внешние зависимости. Я туда просто не полез — покрывал unit- и UI-тестами только базовую функциональность, где были Singleton-зависимости. Даже с одними Singleton’ами приходится поднимать отдельную тестовую инфраструктуру для запуска приложения в тестовом режиме. Это не просто неудобно — это очень затратно по времени. Если сравнить усилия, которые надо потратить на реализацию тестирования подобного функционала в Spring и Dagger… Сравнение будет не в пользу Dagger. В целом я начал думать о переходе на runtime-генерацию графа зависимостей.

https://habr.com/ru/articles/962326/

#java #dagger2 #dependency_injection #dependency_inversion #DimensionDI #DimensionUI #spring_ioc #guice #рефакторинг