Многие думают, что используют скоупы, а на самом деле они у них не работают, в итоге смысл в Dagger пропадает

Лишь излишняя сложность создаётся

да ну не нужно это все
сообщай родителю, что нужно перейти на другую вкладку и переходи, а таббар сам навигатору сообщит нужный экран

Окей, мне тогда листнер стоит прокинуть с дочерних фрагментов к главному?

да, тоже видел такие проекты, что все через одно место
впереди куча времени - еще успею убедить 🙂

можно начать с кастинга parentFragment к FeatureTabClickListener и методов onAttach/onDetach

Ну я про это же. Пойду и сделаю лучше так, пасиба

Ну ведь для этого сделали view model. Чтобы взаимодействие между фрагментами делать через них, а не эти касты колбэков как раньше

А у меня же сингл активити и он видит только одну мейн активити в он атаче, а не TabFragment. А onAttachFragment вообще не дергается.

А, я могу же дернуть childFragmentManager.fragments[0], точняк

ее не для этого сделали)

ну как-то нет

Человек наверно про shared vm имел ввиду, хотя я никогда не шарил её между фрагментами

ну это тоже не то

И для этого тоже)

ну как-то тупо получается, что маленькая фича знает детали мира вокруг себя) в целом, насрать, но для чистоты такой вариант не катит

А для чего ещё shared view model, разве не для того чтобы сделать взаимодействие между фрагментами одного активити?

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

https://developer.android.com/topic/libraries/architecture/viewmodel#sharing

Ну даже в доке про это пишется

оно от этого не становится верным
представь такую ситуацию:
- есть какой-то экран (профиль)
- он должен общаться с внешним миром
- для этого ты решаешь использовать SharedViewModel, которая ещё и про другие фрагменты знает
- тебе нужно один и тот же экран профиля использовать в двух местах и передавать какой-то сигнал во внешний мир, но уже другой сущности
- ты завязан на одну единую вью модель
- самое место для костылей и дополнительных условий для обработки каждого из сценариев