флоу/визарда на несколько экранов. Пока что встречал только ручной вариант, где нужно самому обнулять(set null) скоуп в каждом "брейк сценарии" т.е. там где юзер окончательно покидает флоу. Выглядит достаточно рутинно и "способствует багам".
Подумываю над каким-нибудь countRef механизмом, но из-за особенностей андроида пазл пока не складывается. Не понятно как добиться того, чтобы в некоторых кейсах новый экран/скоуп биндил зависимости(увеличивал countRef) раньше, чем предыдущий декрементил их.
Архитектура на фрагментах, обычно транзакции предсказуемы(достаточно понимать add, replace, addToBackStack), но иногда они могут менять поведение/оптимизироваться (setReorderingAllowed). Согласно докам - если было закомиченно(pendingTransactions) несколько действий(переходов), то некоторые шаги могут вообще опускаться (пропуская вызовы колбеков жц опущенных фрагментов)
храни компоненты в retained фрагментах в менеджере флоу фрагмента
“How to store scoped Dagger Components in Android applications” by Alexander Sitnikov https://link.medium.com/DcJtZ31oK3 Возможно заинтересует. Вообще тема действительно достойная обсуждения и нерешенная)
Обсуждают сегодня