изи, как прогулка в парке, единственная ремарка в документации, что не дружит с динамическими фичами, но это сам по себе редкий зверь.
Мне тоже интересно. Я бы хотел посмотреть на проект с Hilt и фича-модулями, где фича-модули декларируют свои зависимости, а их фичи-контейнеры их предоставляют. Причём в фича-модулях могут быть свои internal классы, которые надо собрать в граф используя зависимости передаваемы из вне. Модули контейнеров зависят от модулей фичей.
Привет! А у тебя часто возникала необходимость в таких кейсах, а ещё лучше ситуации, когда это помогало в дальнейшем развитии проекта? На моём опыте за 6 при мне инверсия зависимостей помогла один раз когда мы с ObjectBox на рум переезжали. И то, там всё довольно базово было.
Ну и понятно про Баду и 700 модулей, но я скорее про 90% остальных проектов до 300к строк кода.
а есть пример посмотреть с такими фича модулями? Это про разделение фичи на api и impl модуль или что-то другое?
Api/impl - это уже следующий уровень разделения. В начале делим на фичи, потом фичи на слои (опционально), потом какую-то фичу или слой фичи можно поделить на api/impl, чтобы ускорить сборку.
я отвечал @ArkaNN1985, на его коммент о разделении на фича модуль и фича контейнер
Это я говорил про то, что хотел бы посмотреть Хилт в работе с фича-модулями, когда дочерние модули декларируют свои зависимости сами. А их предки (то, где эти фичи используются), при создании дочерних фич передают им зависимости. При этом, зависимости могут быть как обычные классы, находящиеся в самом фича-модуле, так и простые интерфейсы, которые предок волен реализовать как хочет. Таким образом, для подключения фичи в любое место, достаточно только удовлетворить все зависимости через конструктор.
Спасибо за лекции Android Academy 😏
Только сейчас заметил сообщение. Я что-то даже смутился, потому что я это использую просто постоянно. Ну т.е. это просто обычное дело - сделать фича-модуль у которого единственная точка входа (например условный класс ProfileFeature(...)). И вот этот класс надо создать и передать зависимости из другого модуля, который зваивист от Profile. Зависимости могут быть всякие разные, например: interface ProfileRepository { ... } class ProfileFeature( val userId: Long, val repository: ProfileRepository, val onFinished: () -> Unit, val onFriendSelected: (userId: Long) -> Unit, ) { ... } Ведь даже просто передать коллбек для навигации- это уже по сути IoC.
Я далеко не эксперт, но вроде именно поэтому hilt не годится для многомодульных проектов, так как он построен на субкомпонентах. Т.е там нельзя указывать зависимости или я, что-то не знаю 🤔.
По-в этому то я и написал изначально, что хотел бы посмотреть на Hilt в таком проекте. Я его никогда не использвал и глубоко не разбирался, но у меня тоже есть такие подозрезния. Знаю, что это точно работает с обычным даггером, хоть и больше кода приходится писать, по сравнению с обычным ручным DI. 😀
Обсуждают сегодня