Fixed
Status Update
No update yet.
Comments
il...@google.com
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.
ha...@gmail.com
il...@google.com
Great! Thanks a lot, I'll look for the live updates soon!
il...@google.com
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit a4806ba69d611dcc36b794870e9dc80981371ec9
Author: Ian Lake <ilake@google.com>
Date: Tue Jun 11 13:14:42 2019
Fix pop when calling setPrimary before replace
When popping a FragmentTransaction, the operations
you apply are undone in reverse ordering. This means
that when you call setPrimaryNavigationFragment()
before replace(), the replace() is undone first, causing
the current Fragment to be removed from the
FragmentManager before the code for undoing
setPrimaryNavigationFragment runs.
We now ensure that performPrimaryNavigationFragmentChanged
is only called if the Fragment is still attached.
Test: new replacePrimaryNavAfterSetPrimary test passes
Fixes: 134673465
Change-Id: I1a126c265c2350ed4e7d437fb68df29376ff5fcf
M fragment/fragment/src/androidTest/java/androidx/fragment/app/PrimaryNavFragmentTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManagerImpl.java
https://android-review.googlesource.com/980591
https://goto.google.com/android-sha1/a4806ba69d611dcc36b794870e9dc80981371ec9
Branch: androidx-master-dev
commit a4806ba69d611dcc36b794870e9dc80981371ec9
Author: Ian Lake <ilake@google.com>
Date: Tue Jun 11 13:14:42 2019
Fix pop when calling setPrimary before replace
When popping a FragmentTransaction, the operations
you apply are undone in reverse ordering. This means
that when you call setPrimaryNavigationFragment()
before replace(), the replace() is undone first, causing
the current Fragment to be removed from the
FragmentManager before the code for undoing
setPrimaryNavigationFragment runs.
We now ensure that performPrimaryNavigationFragmentChanged
is only called if the Fragment is still attached.
Test: new replacePrimaryNavAfterSetPrimary test passes
Fixes: 134673465
Change-Id: I1a126c265c2350ed4e7d437fb68df29376ff5fcf
M fragment/fragment/src/androidTest/java/androidx/fragment/app/PrimaryNavFragmentTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManagerImpl.java
il...@google.com
This is fixed internally and will be in the next release of Fragments.
an...@google.com
il...@google.com
While this was released as part of Fragments 1.2.0-alpha01 (https://developer.android.com/jetpack/androidx/releases/fragment#1.2.0-alpha01 ), we've decided to cherry pick this back to Fragments 1.1.0-rc04 as well.
Description
Version used: 1.1.0-beta01
For any given fragment backstack, if the fragment to be popped off the backstack is the current primary navigation fragment, this results in a NullPointerException on that popped fragment's FragmentManager receiving notification that the primary navigation fragment changed. Because that fragment is being removed, it no longer has a host nor a reference to that host's FragmentManager. Specifically, this happens at androidx.fragment.app.Fragment.performPrimaryNavigationFragmentChanged, line 2662 (mFragmentManager is null).
Example:
fragmentManager.beginTransaction()
.add(containerId, FragmentA())
.commit()
Current backstack:
A (not primary)
Transaction adding a new fragment that is to be a primary nav fragment:
val fragmentB = FragmentB()
fragmentManager.beginTransaction()
.addToBackStack(null)
.setPrimaryNavigationFragment(fragmentB)
.replace(containerId, fragmentB)
.commit()
Current backstack:
A -> B (primary)
If activity.onBackPress() or fragmentManager.popBackStack() is called, as B is being popped, the FragmentManager's primary nav fragment is set to null, and B (that is now removed) notifies its host FragmentManager of this change (which B no longer has a host because it was removed).