Y
Size: a a a
2018 September 05
2018 September 10
VC
Здравствуйте, спасибо за классную библиотеку! Я обратил внимание на то, что такие методы как onPause, onStop, onDestroy и т.п. вызываются у делегатов после суперов. Это сделано с какой-то определенной целью?
Спасибо на добром слове ;)
Не совсем понял вопрос. Специально ли сперва супер, потом наш метод? Просто единообразие скорее. Да и не сильно в нашем случае влияет, тк почти все асинхронно меняется в активити. Но сейчас у нас в работе рефакторинг, возможно это и изменится.
А вы как думаете должно быть, и почему?
Не совсем понял вопрос. Специально ли сперва супер, потом наш метод? Просто единообразие скорее. Да и не сильно в нашем случае влияет, тк почти все асинхронно меняется в активити. Но сейчас у нас в работе рефакторинг, возможно это и изменится.
А вы как думаете должно быть, и почему?
DG
Здравствуйте, спасибо за классную библиотеку! Я обратил внимание на то, что такие методы как onPause, onStop, onDestroy и т.п. вызываются у делегатов после суперов. Это сделано с какой-то определенной целью?
Привет! Нет никакой разницы в порядке вызова, сначала супер или после. Так как их вызов синхронный и пока не отработает весь метод onPause/onStop/onDestroy, другая работа в main потоке не возможна. Поэтому не должно быть никаких проблем с биндингом ПМ-ки и что команды от нее вызовутся в некорректном состоянии.
DG
С тех пор я твердо решил сначала за собой все подчищать, а уж потом отдавать управление фреймворку
Не должно быть никаких проблем, но если вам будет спокойнее, то можете написать свой базовый фрагмент или активити, который будет вызывать методы у делегата до вызова супер
DG
Просто когда-то давно сталкивался с проблемой, когда в презентере в onDestroy провожу какие-то манипуляции, в которых участвует контекст, он оказывается в каком-то полурабочем стейте, потому что активити свою работу по его уничтожению уже произвела.
Как я уже написал, что вызов метода синхронный, поэтому после его отработки от ПМ-ки не прилетит команда
DG
Спасибо за ответ!
Попробуйте воспроизвести проблему в RxPM
2018 September 11
VC
Здравствуйте. Подскажите пожалуйста, почему всякие State, Action, Command сами по себе не являются Consumer, а содержат его как свойство?
А это не свойство. Это экстеншн функция, причем протектед в ПМ.
VC
VC
Это для того, чтобы ограничить видимость той части сабжекта, которая позволяет кидать (в случае с Stata, с другими может быть не consumer, а observable) в него данные. Чтобы из вью ты мог подписаться на State, а кинуть в него мог только в ПМ. Иначе было бы не безопасно. Мы бы меняли состояние из вью безнаказанно.
VC
Если бы не эти ограничения, вообще не было бы нужды в State, был бы просто BehaviorSubject.
VC
Если из вью, то можно использовать passTo()
VC
Как раз и сделано, чтобы не использовать accept. Меня тоже передергивало ;)