AC
replace уводит лайфсайкл в стейт Created, а add оставляет в Resumed
Size: a a a
2020 October 14
AC
вопрос был в том, что у первого экрана отработает какая-то логика(в колбеке резатла), при том, что второй экран еще не закрыли?
AC
другой момент в том, что слушатели хранятся в мапе, т.е. там именно set а не add, т.е. любой вызов сеттера перезапишет старый слушатель
AC
но типа это легко хендлится тем, что реквестКи делается уникальным, например:
1) Экран Альбом
2) Экран Трека
перед открытием второго экрана вешается слушатель с ключем типа "song" + "songId"
1) Экран Альбом
2) Экран Трека
перед открытием второго экрана вешается слушатель с ключем типа "song" + "songId"
AC
плюс нужно удалить слушатель по возвращению, с чем не должно возникнуть проблем
KT
Я вам про реплейс экранов говорю, а не про метод реплейс в реализации андроидного менеджера.
KT
Это разные вещи. Я про стек, а там про разрушение вьюшки.
AC
Только интересно, что будет если я отправлю результат, но не закрою экран, а тот кто слушает результат, откроет сверху еще экран...не увидел тут ничего про стек/реплейс
Кто пробовал?
Или подобное поведение остается на откуп разработчикам?
AC
Это разные вещи. Я про стек, а там про разрушение вьюшки.
это смотря какой лайфсайкл передать, если вьюшный, то одно, а если самого фрагмента, то другое. Последний живет столько же сколько и презентер/ВМ
AC
в кейсе с полной заменой стека умрут все старые презентеры/ВМ,
AC
для более глобального слушателя можно свою реализацию Lifecycle подложить
AC
кста напомню, что обычные юзеры подразумевают, что у приложения один рутовый фрагментМенеджер в мейн активити, где вся навигация пляшет вокруг него одного. А врапперы типа ScopeFragment, где у каждого по своему чайлдФМенеджеру, это уже экзотика, которую желательно отдельно указывать в вопросе.
KT
Все равно не понимаю о чем вы.
AC
Все равно не понимаю о чем вы.
что будет если я отправлю результат, но не закрою экранзакрытие/не закрытие экрана никак не связано с доставкой результата. Все зависит от стейта слушателя, если Started+ то обработает сразу, иначе отложит на потом (обсервер стейта доставит, когда будет Started+, если такой вообще наступит)
а тот кто слушает результат, откроет сверху еще экранКак и в первом абзаце, все зависит от того, что произойдет со стейтом "того, кто слушает", будет ли он уничтожен или нет.
KT
Ок, вы про фрагменты и слушателя внутри фрагментов.
Для меня (и Чичероне) этой проблемы не стоит, так как вью модели живы, даже когда экран в бек стеке. Кроме случая после смерти процесса, но это отдельная история
Для меня (и Чичероне) этой проблемы не стоит, так как вью модели живы, даже когда экран в бек стеке. Кроме случая после смерти процесса, но это отдельная история
KT
Релиз на Котлине. Такие дела.
А еще можно теперь управлять стратегией переключения экранов (add/replace)
А еще использовать FragmentFactory.
А еще можно теперь управлять стратегией переключения экранов (add/replace)
А еще использовать FragmentFactory.
AP
Свершилось таки)
AP
Котлин!
AC
Если такая проблема не стоит перед чичероне, тогда в чем заключался ваш вопрос?
AC
фрагмент тоже живой, когда он в бекстеке (created + attached стейты)