честно говоря статью уже не скину, надо поискать, но такой подход видел не раз.

Парни, подскажите
Есть приложение, разбитое на модули
Модули нижестоящие инжектятся в вышестоящие
В итоге инстансы feature хранятся в BaseApp
Так получается, что средний слой, feature, должен на каждый раз представлять инстанс объекта feature, собирая его, используя зависимость репозитория
Вопрос: корректно ли заводить компонент на генерацию это инстанса feature, или можно обойтись обычным
`newInstance() = Feature(RepositoryDI.featureRepository)`
?

Переформулирую вопрос:
Оверхед ли поднимать граф компонента целиком (хоть и небольшой) для получения инстанса объекта каждый раз при входе на экран?

да, оверхед. И не совсем понятно зачем это нужно. Даггер очень хорошо работает с мультимодульной архитектурой

Спасибо за ответ
Продолжу курить статьи на тему
Пока не совсем ясно, как инстанциировать инстанс фичи для верхнего слоя, когда верхний слой ничего не знает о зависимостях нижнего
То есть инит должен происходить в слое фичи, верно?

ну я не очень понимаю что ты хочешь сделать, сорри. Нужно нарисовать зависимость модулей и все такое

Да, сейчас сделаю для наглядности

Вопрос: как заинитить объекты Feature и где?
Так как только фичи знают о своих репозиториях, то логично в фичах это и делать
И как раз там этот граф-on-demand и появляется

ну я так понимаю Feature 1 ( и т.д) - это отдельные модули. У них конечно же будет свой даггер и все такое. Еще вероятней всего у них есть точка входа (например активити какаято). Так вот ты у себя в Application, где будет граф, добавляешь модуль из Feature 1 и оно дальше само все заинициализирует. Я использовал Dagger-Android.

вообще дофига статей на эту тему - https://medium.com/@luigi.papino/dagger2-for-modular-architecture-332e1250a85f или https://medium.com/androiddevelopers/dependency-injection-in-a-multi-module-project-1a09511c14b7

Категорически благодарю за ссылки

Дело в том, что если делегировать всю генерацию в application, то падала ошибка при сборке и сообщением о том, что интерфейс репозитория не обнаружен. Из-за чего и начал махинации с графом в фичах

ну чтото похоже не правильно делал. Так сложно сказать. Но схема рабочая, сам такую пользовал

Больше спасибо за ответы
Буду дальше продолжать исследование

У меня довольно нубский вопрос. Если я делаю инжект класса А то все ок, но стоит мне добавить к этому классу интерфейс Б, как даггер начинает просить провайд метод для этого интерфейса. Почему так, что с этим сделать?

И все же не получается сделать автоматическую сборку вышестоящим модулем нижестоящим
Вот эта реализация с поднятием графа каждый раз при создании объекта
Буду рад конструктивной критике
https://github.com/GeniusRUS/multimodule

не совсем понятно зачем тебе именно такой сетап? почему модули не лежат там где сама фича?

Если модуль положить там же, где фича, возникаает вопрос:
Нужна ли тогда зависимость :repository в :app? Получется, для сборки она не требуется, так как с :repository работает только :feature_random_joke. Но если ее убрать и вынести модуль сборки :feature_random_joke в слой фичи, то при сборке будет падать как раз та ошибка, про которую я упоминал: e: error: cannot access IFeatureRandomJokeRepository и сборка крашнется. Т.е. как я понимаю, модуль осуществляющий сборку (:app) не имеет в себе зависимости :repository и поэтому те классы, которые ему достаются для сборщика из модуля фичи, он не видит. Верно?

Зависимость нужна, именно для даггера.

Логично, спасибо

Народ привет, подскажите пж делаю ./gradlew clean build и получаю вот такую ерунду