Еще раз про многомодульность Android-приложений

[LAVElek]

Мы у себя в проекте для управления жизненным циклом компонента используем удобную библиотеку ComponentsManager.

[Phansier]

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

[LAVElek]

Там есть пара моментов, которые автор обещал доработать. Но пока они сильно не мешают работать.

[xoxol_89]

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

[LAVElek]

На данный момент проблемы нету. У нас в основном компонент привязывается к жизненному циклу активити или фрагмента. Нам как раз не хватает, чтобы к одному жизненному циклу можно было бы привязать несколько компонентов.

[foxspa]

Данную проблему можно решить с применением подхода, описанного здесь: habr.com/ru/post/536106
В данном случае, нужно чтобы у активити был свой компонент и к нему можно привязать сколько угодно других компонентов. Когда компонент активити умрёт, то и все привязанные к нему компоненты тоже освободятся (помрут, если не используются где-то ещё).
Случай с активити описан в указанной статье. Обратите внимание на особенности работы с компонентом активити.

[artofmainstreams]

Есть ли прирост в производительности в данном подходе от того, что предлагал Евгений Мацюк? В каком случае стоит переходить на этот?

[Phansier]

Улучшения, по сравнению с подходом Евгения, были связаны больше с решением выявленных архитектурных недостатков и появившимися возможностями Kotlin. Как мне кажется, производительность будет больше зависеть от конкретной реализации и используемого DI-фреймворка.
Этот подход полностью совместим с предыдущим, поэтому переходить можно постепенно при добавлении новых модулей.

[xoxol_89]

Мой подход был целиком для Java.
C Котлином часть вещей упростилась. Ну и плюс опыт, конечно же.

[Dimchel]

Насколько я понял: зависимости всех модулей прогоняются через один AppComponent, что при большом проекте с большим количеством фиче-модулей приведет этот файл к разрастанию до бесконечных размеров. Это приведет к снижению производительности. Сейчас наоборот идет тенденция отходить от даггеровских god-компонентов.

[Phansier]

Совсем необязательно связывать модули через один AppComponent. В примере так сделано только потому, что там всего три маленьких фиче-модуля.
При масштабировании, если фичи достаточно хорошо изолируются по зависимостям, их склейку можно разбивать по разным Dagger-компонентам внутри app-модуля.

[Dimchel]

К сожалению, в реальном мире всегда есть логическая связанность у фичей. Хотелось бы увидеть решение для более сложных проектов. Решали ли вы в касперском эту проблему?

[Phansier]

Мы пока делаем для каждого фиче-модуля отдельный Dagger-модуль в app. Разделение AppComponent у нас в планах после вынесения всех фиче-модулей из монолита.

[Prokky]

Какое примерное количество всех модулей у вас в проекте? И какое количество feature из них?

[Phansier]

Сейчас около 27 модулей, из них 18 feature-модуля.

[Prokky]

В таком случае понятно, почему вы пока не столкнулись с жирным год компонентом. У нас более 190 модулей при около 130 фичевых, поэтому мы изначально решали проблему вынося все связки из app, но наткнулись на проблемы, которые у вас решены :)

[FirsofMaxim]

Спасибо за статью, я столкнулся с трудностью управления зависимостями между Feature модулями, когда делал мульти-модульный проект по "предыдущей" статье, и сам пришел к Module-injector.

[Phansier]

Это интерфейс-маркер. Такой же, как, например, Serializable. Он способствует читаемости кода.

[Phansier]

Модуль принимает на вход Dependencies и выставляет свой контракт в виде API.
Если в его API два или более классов (хотя лучше использовать в API только интерфейсы) можно использовать композицию, например:

interface SomeFeatureApi : BaseAPI {
    fun firstInteractor(): FirstInteractor
    fun secondInteractor(): SecondInteractor
}

Если же используем интерфейсы, то можно просто отнаследовать FeatureApi от них, например:

interface SomeFeatureApi : BaseAPI, FirstInteractor, SecondInteractor 

[foxspa]

Альтернативный способ склейки модулей описан тут:
habr.com/ru/post/536106

[Georrg]

@Phansier , спасибо за статью - мы как раз в процессе рефакторинга. Скажите, как вы подключаете вьюмодели в фича модулях? Фабрика уходит в коммон и подключается в каждый модуль в отдельности? Откуда тогда локально брать мапу viewModel-провайдеров? А если подключиние строго в app-module - прокидываете объект фабрики в модуль? Очень интересно в общем, т.к. ломаю над этим голову второй день. В ваших классных примерах viewModel-и почему-то не представлены.