Сами обсерверы не трогайте. Если внутри уже делается что-то неспецифичное для активити/фрагмента, то дергайте методы извне. Ещё обсерверы, которые не делают работы с View, могут быть в ViewModel. Хотя, теоретически, могут быть где угодно.
Кроме того что хотел разгрузить Фрагмент от множественных подписок возникла и такая ситуация: - есть фрагмент Логин который подписан на множество сетевых запросов (4) и по их завершении выдает или ошибку или пускает к контенту. - реализую автологин, т.е. все это нужно делать на пару шагов раньше, в другом (Launch) фрагменте.
Вопрос - дублировать код (не хотелось бы) или все же вынести логику в отдельный класс и пробрасывать в него LifecycleOwner фрагмента?
Дублирующий код можно в общую ViewModel положить. Запросы пусть совершаются там же(если запросы очень сложные и их много, то можно из VM дергать методы в других классах). Фрагменты пусть слушают какую-нибудь одну-две результирующие LiveData/StateFlow/SharedFlow
Всем привет! Может кто сталкивался? Нудно перевести проект на compose, но постепенно, у меня пол проекта будет на xml-ках а половина на compose, у меня в проекте есть koin и viewModel. Когда я импортирую зависимости viewModel для койн и композ, у меня в модулях койна происходит конфликт имен