ОА
Size: a a a
ОА
QH
ОА
QH
ОА
A
ОА
А
container
посредством replace
сеттится фрагмент со сплешом. Сплеш забирает данные с апи, кеширует их и даёт команду на отображение фрагмента с контентом, который сеттится аналогично через replace
.java.lang.IllegalStateException: FragmentManager is already executing transactions
Я это пофиксил. Я пользуюсь своим на коленке написанным навигатором, который который сеттит фрагменты используя commitNow()
. Апка перестала падать, когда я заменил commitNow()
на commitAllowingStateLoss()
.commitNow()
- синхронный, а commitAllowingStateLoss()
- ассинхронный. Но мне это не говорит ни о чём. В теории, мб есть какая - то связь с тем что приложение свёрнуто и тем что вызов был именно синхронный, но чёт сомнения одолевают. В доках ничего явно не сказано на этот счёт.private void ensureExecReady(boolean allowStateLoss) {
if (mExecutingActions) {
throw new IllegalStateException("FragmentManager is already executing
transactions");
}
Логика там вроде как примерно такая: запускается транзакция, флаг сеттится в true
, транзакция завершается, флаг сеттится в false
. Это предположение, т.к отдебажить это я не могу - дебаггер слетает когда я апку сворачиваю, а то что я успеваю отдебажить - это ад, там этот флаг 100500 раз дёргается, нифига не понятно.fun replaceNewFragment(screen: Screen, animationType: AnimationType? = null) {
fragmentManager
.beginTransaction()
.setCustomAnimations(R.anim.anim1,R.anim.anim2)
.replace(container, screen.getFragment(), screen.getTag())
.commitNow()
}
А
VP
А
С
A
QH
l
SO
commitNow()
- синхронный, а commitAllowingStateLoss()
- ассинхронный.SO
container
посредством replace
сеттится фрагмент со сплешом. Сплеш забирает данные с апи, кеширует их и даёт команду на отображение фрагмента с контентом, который сеттится аналогично через replace
.java.lang.IllegalStateException: FragmentManager is already executing transactions
Я это пофиксил. Я пользуюсь своим на коленке написанным навигатором, который который сеттит фрагменты используя commitNow()
. Апка перестала падать, когда я заменил commitNow()
на commitAllowingStateLoss()
.commitNow()
- синхронный, а commitAllowingStateLoss()
- ассинхронный. Но мне это не говорит ни о чём. В теории, мб есть какая - то связь с тем что приложение свёрнуто и тем что вызов был именно синхронный, но чёт сомнения одолевают. В доках ничего явно не сказано на этот счёт.private void ensureExecReady(boolean allowStateLoss) {
if (mExecutingActions) {
throw new IllegalStateException("FragmentManager is already executing
transactions");
}
Логика там вроде как примерно такая: запускается транзакция, флаг сеттится в true
, транзакция завершается, флаг сеттится в false
. Это предположение, т.к отдебажить это я не могу - дебаггер слетает когда я апку сворачиваю, а то что я успеваю отдебажить - это ад, там этот флаг 100500 раз дёргается, нифига не понятно.fun replaceNewFragment(screen: Screen, animationType: AnimationType? = null) {
fragmentManager
.beginTransaction()
.setCustomAnimations(R.anim.anim1,R.anim.anim2)
.replace(container, screen.getFragment(), screen.getTag())
.commitNow()
}
ОА
А
commitNow()
- синхронный, а commitAllowingStateLoss()
- ассинхронный.