Fixed
Status Update
No update yet.
Comments
[Deleted User] <[Deleted User]>
Hi Ed, Thank you so much for these suggestions. I've been reviewing them and merging them in. Hopefully it should be live. I've included a thank you note too in the article.
il...@google.com
Great! Thanks a lot, I'll look for the live updates soon!
ap...@google.com
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
il...@google.com
We've reverted the above change in https://android-review.googlesource.com/954182 since it is no longer needed - we've fixed setMaxLifecycle() to work with and without setReorderingAllowed(true) in https://android-review.googlesource.com/954024
This will be available in the next release of Fragments.
This will be available in the next release of Fragments.
Description
Version used: 1.1.0-alpha07
Devices/Android versions reproduced on: AVD Pixel 3XL running API 28
**Description**
If I use the `RESUME_ONLY_CURRENT_FRAGMENT` flag, as in
```FragmentStatePagerAdapter(supportFragmentManager, RESUME_ONLY_CURRENT_FRAGMENT)```
then...
**Expected**
Only the currently visible Fragment should be brought to RESUMED state, the immediate neighboring Fragments should be capped at STARTED.
**Actual**
The current and neighboring fragments are always `resumed`, then `paused`, then the current one is `resumed` again.
**Extra Info**
See screen recording that captures this behavior.