Fixed
Status Update
Comments
ra...@gmail.com <ra...@gmail.com> #2
Thanks for the report - do you have any reproduction steps?
jb...@google.com <jb...@google.com>
cl...@google.com <cl...@google.com> #3
Nevermind, this has been fixed and will be available in an upcoming release.
ap...@google.com <ap...@google.com> #4
An unfortunate side effect of this seems to be that the adapter is set to null before any pending fragment animations are completed.
In my project I add a PreferenceFragmentCompat to the backstack, specifying custom enter and exit animations. Now, when the user presses the back button I call FragmentManager.popBackStack() which in turn starts the custom exit animation.
The problem is that popBackstack() internally calls onDestroyView() on the PreferenceFragmentCompat to be removed. The PreferenceFragmentCompat calls unbindPreferences() which calls getListView().setAdapter(null).
The effect is that the list of preference items is cleared instantly before the exit animation even starts! This causes a white flicker and is clearly noticeable, the preference items disappear, then the view fades out.
Could you prevent setAdapter(null) from being called in this scenario? Maybe unregister the data observer instead?
In my project I add a PreferenceFragmentCompat to the backstack, specifying custom enter and exit animations. Now, when the user presses the back button I call FragmentManager.popBackStack() which in turn starts the custom exit animation.
The problem is that popBackstack() internally calls onDestroyView() on the PreferenceFragmentCompat to be removed. The PreferenceFragmentCompat calls unbindPreferences() which calls getListView().setAdapter(null).
The effect is that the list of preference items is cleared instantly before the exit animation even starts! This causes a white flicker and is clearly noticeable, the preference items disappear, then the view fades out.
Could you prevent setAdapter(null) from being called in this scenario? Maybe unregister the data observer instead?
cl...@google.com <cl...@google.com> #5
Since the
Please file a bug against Fragments the with a sample project that reproduces this issue and we will be happy to take a look at what's going on.
na...@google.com <na...@google.com> #6
I can confirm that using fragment 1.2.2 resolves the issue, thank you!
Without an explicit dependency declaration version 1.1.0 was still used (transient dependency of appcompat 1.1.0).
Without an explicit dependency declaration version 1.1.0 was still used (transient dependency of appcompat 1.1.0).
ra...@gmail.com <ra...@gmail.com> #7
It looks good to me. At least, this specific behaviour seems to be fixed.
Description
Component used: Navigation
Version used: 2.6.0-alpha05
Devices/Android versions reproduced on:
Not relevant, it will happen on all.
If this is a bug in the library, we would appreciate it if you could attach: Sample project to trigger the issue.
I'll add a couple of simple kotlin files instead, just use them with any version after 2.6.0-alpha05 navigation dependency and you'll be able to reproduce it.
MainActivity_rook.kt File
If we add destinations directly on "root" (route passed to NavHost call), then this will be the log of the back stack as we navigate:
MainActivity_no_root.kt File
If we add a navigation graph ("home_graph") as the only direct child of "root" and add destinations on that instead, it will work as expected, we'll see this:
This was a breaking change that could introduce bugs for anyone relying on that "root" sent on the NavHost and popping up to that, since after updating navigation it would instead just pop their last screen.