VC
Я в последнее время занимаюсь поддержкой древней аппки с датабиндингом, а по ночам реву в подушку
Size: a a a
2019 August 07
DG
Чем больше думаю, тем чаще прихожу к мысли, что bind/unbind да и вообще любое упоминание жц фрагмента или активити внутри пмки не нужно. И что это сугубо личное дело вьюшки: когда ей жить, когда паузиться-резюмиться, а когда умирать. И что лайвдата в этом плане все правильно делает, заботясь исключительно о количестве живых подписчиков. Все остальное - это исключительные кейсы и должны решаться по месту и через композицию, но никак не с помощью имплементации жц в базовых классах. Что думаете?
Лайвдата как раз сильно завязана на жц для обнуления обзерверов и емитит данные только после onStart, хотя подписаться можно в onCreate.
DG
DG
Верно
Как это протеворечит моим словам, что подписываемся в onCreate, а значение начинаем получать только после onStart?
DG
Ну сама лайвдата не завязана, а завязаны слушатели, она же живёт себе спокойно во вьюмодели и не тужит
Так или иначе, чтобы вовремя отписываться и емитить данные только в активном состоянии нужно знать о жц. Для этого при подписке на лайвдату в метод observe передается LifecycleOwner. Далее лайвдадата все делает сама и removeObserver при дестрое вызывать не требуется.
2019 August 08
DG
Ну у нас так сделать не получится. Во-первых, жц нужен для работы Command, снаружи никак не сделать, во-вторых, нужно правильно обрабатывать кейс, когда парент пм-ка детачит чайлд пм-ку.
DG
Ну вот я пришёл к выводу, что command не нужна, а отношение парентов и чайлдов - это следствие наличия жц в пмке, что тоже как бы и не надо)
Тебе не нужна command, а другим нужна. А жц в пм-ке нужен, хотябы в минимальном наличии onDestroy - релизить ресурсы надо.
DG
Для этого есть свой onCleared
Где есть?
DG
А команда другим для каких целей нужна?
показать тост, запустить анимацию, перемещение камеры на карте, сделать транзакцию фрага, кинуть навигационное сообщение