Fixed
Status Update
Comments
ka...@gmail.com <ka...@gmail.com> #2
il...@google.com <il...@google.com>
ap...@google.com <ap...@google.com> #3
I suspect that we're just not setting the default state to be capped at STARTED and you'd see the same oscillation with setUserVisibleHint(). We should just fix it for both cases though
jb...@google.com <jb...@google.com> #4
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 97519ce890a194fd21c47696996f90ac00920868
Author: jbwoods <jbwoods@google.com>
Date: Mon Apr 29 13:18:22 2019
Allow reordering when calling setMaxLifecycle in FragmentPagerAdapter
When FragmentPagerAdapter (or FragmentStatePagerAdapter) call
instantiateItem(), instead of the new added Fragment just being capped
at the STARTED state, it first goes to RESUMED, then returns to the
STARTED state.
This is caused because setMaxLifecycle is split into 2 separate Ops (a
set maxLifecycleState and an unset maxLifecycleState). These Ops are executed
separately and both change the Fragment state. There is no need to unset
the maxLifecycleState of a Fragment when it is first added, so the unset
Ops becomes redundant. Setting allow reordering to true allows the
FragmentManager to remove the redundant unset Op. This means new
Fragments are correctly capped at STARTED, without the need to go to
RESUMED first.
Test: confirmed in test app
Bug: 131557151
Change-Id: I92feb1eeb3cbb0156d2d59eb698547fd5f061e85
M fragment/src/main/java/androidx/fragment/app/FragmentPagerAdapter.java
M fragment/src/main/java/androidx/fragment/app/FragmentStatePagerAdapter.java
https://android-review.googlesource.com/953918
https://goto.google.com/android-sha1/97519ce890a194fd21c47696996f90ac00920868
Branch: androidx-master-dev
commit 97519ce890a194fd21c47696996f90ac00920868
Author: jbwoods <jbwoods@google.com>
Date: Mon Apr 29 13:18:22 2019
Allow reordering when calling setMaxLifecycle in FragmentPagerAdapter
When FragmentPagerAdapter (or FragmentStatePagerAdapter) call
instantiateItem(), instead of the new added Fragment just being capped
at the STARTED state, it first goes to RESUMED, then returns to the
STARTED state.
This is caused because setMaxLifecycle is split into 2 separate Ops (a
set maxLifecycleState and an unset maxLifecycleState). These Ops are executed
separately and both change the Fragment state. There is no need to unset
the maxLifecycleState of a Fragment when it is first added, so the unset
Ops becomes redundant. Setting allow reordering to true allows the
FragmentManager to remove the redundant unset Op. This means new
Fragments are correctly capped at STARTED, without the need to go to
RESUMED first.
Test: confirmed in test app
Bug: 131557151
Change-Id: I92feb1eeb3cbb0156d2d59eb698547fd5f061e85
M fragment/src/main/java/androidx/fragment/app/FragmentPagerAdapter.java
M fragment/src/main/java/androidx/fragment/app/FragmentStatePagerAdapter.java
Description
Component used: Fragment Version used: 1.3.3 Devices/Android versions reproduced on: Emulator Android 10
Currently there is a crash trying to get parcelable from result after process restoration.
Setup:
MainActivity
,FirstFragment
andSecondFragment
.FirstFragment
toSecondFragment
.FirstFragment
callsgetParentFragmentManager().setFragmentResultListener()
inonViewCreated()
and listens for result.getParentFragmentManager().setResult()
on submit button click. Submit button does only that and doesn't navigate back toFirstFragment
.Bundle
viaputParcelable()
. We send backExampleClass
which implementsParcelable
using@kotlinx.parcelize.Parcelize
.Steps to reproduce:
SecondFragment
.FirstFragment
receives result inFragmentResultListener#onFragmentResult
and callsresult.getParcelable()
.android.os.BadParcelableException
There two ways to avoid crash:
result.setClassLoader(context.classLoader)
beforeresult.getParcelable()
.Is this something that should be fixed on Fragment or platform side?
What is the preferred workaround for the app developers in the meantime?