NM
Александр
Оч надеюсь что нет, ибо если он спалит что я тут спрашиваю, мне пiзда)
Рест ин пеперрони
Size: a a a
2020 January 09
ОА
Ой да не пох?
А
Ой да не пох?
Аще пох.
MO
Да че ты переживаешь
Всегда есть @mobile_jobs
Всегда есть @mobile_jobs
ОА
Ору в голосину
А
практически полный ответ на твой вопрос можешь найти здесь:
https://medium.com/inloopx/demystifying-androids-commitallowingstateloss-cb9011a544cc
https://medium.com/inloopx/demystifying-androids-commitallowingstateloss-cb9011a544cc
Кстати, в конце этой статьи есть хороший такой инсайт:
Я так понимаю, транзакция после
Always first analyse why the transaction is being executed after onStop().Я так понимаю, транзакция после
onStop() - это по дефолту плохо?ОА
Александр
Кстати, в конце этой статьи есть хороший такой инсайт:
Я так понимаю, транзакция после
Always first analyse why the transaction is being executed after onStop().Я так понимаю, транзакция после
onStop() - это по дефолту плохо?После онресторинстанс
А
Да че ты переживаешь
Всегда есть @mobile_jobs
Всегда есть @mobile_jobs
Вообще не переживаю, я погрузчик умею водить ;)
ОА
Свет клином на ИТ не сошёлся
А
После онресторинстанс
Ну блин, а ежели юзер свернул апку, а у него там через какое - то время случился какой - то ивент, который тригернул
Типо, правильнее будет передумать подход, и сделать так, чтобы транзакция не вызывалась, а вью просто была в курсе, что по возвращению к приложению надо бы где - нибудь в
commit()?Типо, правильнее будет передумать подход, и сделать так, чтобы транзакция не вызывалась, а вью просто была в курсе, что по возвращению к приложению надо бы где - нибудь в
onResume() совершить транзакцию?Y
Свет клином на ИТ не сошёлся
Ты про архитектуру?
ОА
Ты про архитектуру?
Уаахахахах
А
У него не сходится чёт там
ОА
Александр
Ну блин, а ежели юзер свернул апку, а у него там через какое - то время случился какой - то ивент, который тригернул
Типо, правильнее будет передумать подход, и сделать так, чтобы транзакция не вызывалась, а вью просто была в курсе, что по возвращению к приложению надо бы где - нибудь в
commit()?Типо, правильнее будет передумать подход, и сделать так, чтобы транзакция не вызывалась, а вью просто была в курсе, что по возвращению к приложению надо бы где - нибудь в
onResume() совершить транзакцию?После онрезюм делай свои транзакции
ОА
Или в активити есть метод онпострезюм
А
После онрезюм делай свои транзакции
Ну да, logic.
Это шо мне со сплешом то делать.
Получается, после того как фрагмент завершит тянуть данные с сервера, нужно проверить в каком состоянии фрагмент, и если будет что - то типо paused/stopped(хз, я тупой и не знаю состояния фрагмента), бахнуть какой - нибудь флаг, чтобы в onResume() был совершен переход. Да?
Это шо мне со сплешом то делать.
Получается, после того как фрагмент завершит тянуть данные с сервера, нужно проверить в каком состоянии фрагмент, и если будет что - то типо paused/stopped(хз, я тупой и не знаю состояния фрагмента), бахнуть какой - нибудь флаг, чтобы в onResume() был совершен переход. Да?
А
И везде так делать, где есть навигация.
Жость.
Жость.
ОА
Александр
Ну да, logic.
Это шо мне со сплешом то делать.
Получается, после того как фрагмент завершит тянуть данные с сервера, нужно проверить в каком состоянии фрагмент, и если будет что - то типо paused/stopped(хз, я тупой и не знаю состояния фрагмента), бахнуть какой - нибудь флаг, чтобы в onResume() был совершен переход. Да?
Это шо мне со сплешом то делать.
Получается, после того как фрагмент завершит тянуть данные с сервера, нужно проверить в каком состоянии фрагмент, и если будет что - то типо paused/stopped(хз, я тупой и не знаю состояния фрагмента), бахнуть какой - нибудь флаг, чтобы в onResume() был совершен переход. Да?
Ливдата
ОА
Гуголь все придумал
ОА
Бери и юзай