Т.е. условно ты больше не вызываешь руками у родительского компонента "дай мне подкомпонент", а ты его инжектишь чтоли

Это dagger-android скорее всего.

Я больше про использование module.subcomponent вне рамок dagger-android

Вообще мне не очень ясна картина с подкомпонентами, т.к. они в основном для разграничения по времени жизни от корневого и поэтому должны быть созданы и уничтожены чем-то, в итоге это чем-то будет являться непосредственными классами самого приложения/логики. В итоге получаем, что логика приложения должна знать про DI для нормальной работы этого DI чтоли

Я понимаю, что с андроидом своя беда, там конструкторы активностей и фрагментов недоступны, и как-то приходится компоненты самому рулить, но это не только на андроиде видится

Т.е. получается отказаться от подкомпонентов, использовать квалификаторы и только Component.dependencies, а где не нужен синглтон на всю жизнь процесса, то инжектить Disposable ресурсы как-нибудь, механизм жизни которых регулируется самой логикой приложения

Подкомпоненты впервую очередь нужны, чтобы решить проблему с видимостью зависимостей родительских компонентов. Если делать через dependencies, то чтобы получить зависимость свыше ее надо прописать в интерфейсе. В сабкомпонентах этой проблемы нет.

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

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

Ладно, это уже просто пища для размышления. Подумаю поищу еще информации

Не знаю ни одного прозрачного ди(

Hilt и Dagger-android как раз на это претендуют)

dagger-android не смог, хилт очень хочу попробовать)

Хилт выглядит очень приятно прям.
Думаю завезти в рабочий проект в отдельной веточке

всем привет. кто-то прикручивал hilt к workmanager? Вроде всё делаю по гайду:

class SendNotifyWorker @WorkerInject constructor(
    @Assisted private val context: Context,
    @Assisted private val workerParameters: WorkerParameters,
    private val getEventByIdInteractor: GetEventByIdInteractor,
    private val notificationHelper: NotificationHelper
) : Worker(context, workerParameters) {

@HiltAndroidApp
class AndroidApp : Application(), Configuration.Provider {
    @Inject
    lateinit var workerFactory: HiltWorkerFactory
.................
 override fun getWorkManagerConfiguration() =
        Configuration.Builder()
            .setWorkerFactory(workerFactory)
            .build()

получаю исключение:

2020-07-27 10:10:00.970 21826-21933/com.lamp.planner E/WM-WorkerFactory: Could not instantiate com.lamp.planner.presentation.background.workmanager.SendNotifyWorker
    java.lang.NoSuchMethodException: <init> [class android.content.Context, class androidx.work.WorkerParameters]

т.е. он ищет конструктор с двумя параметрами. Посмотрел HiltWorkerFactory, там про inject доп. параметров вообще ничего нет:

if (factoryProvider == null) {
            return null;
        }
        return factoryProvider.get().create(appContext, workerParameters);

Ребят, привет. Есть ли смысл вообще провайдить активити? Мне просто нужно в моем холдере адаптера получить активити, а холдер создается в адаптере, а адаптер в активити. Прокидывать активити думаю вообще не варик, тем более у меня 4 холдера. Как поступить лучше?

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

Имхо странный кейс/решение

Хорошо, опишу немного подругому. Мне надо вызвать runOnUiThread в холдере для биндинга большого кол ва вьюх.

Иначе у меня чуток фризит