Fixed
Status Update
No update yet.
Comments
so...@gmail.com
Thanks for the report - do you have any reproduction steps?
so...@gmail.com
Nevermind, this has been fixed and will be available in an upcoming release.
so...@gmail.com
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?
il...@google.com
il...@google.com
ap...@google.com
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.
il...@google.com
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).
ch...@gmail.com
This is still not fixed. Steps to reproduce:
- Be on the initial Fragment (FragmentA)
- Press device back button (the back press will be consumed but nothing appears to happen)
- Click on a view that will cause an attempt to navigate to FragmentB
- Crash
- Be on the initial Fragment (FragmentA)
- Press device back button (the back press will be consumed but nothing appears to happen)
- Click on a view that will cause an attempt to navigate to FragmentB
- Crash
il...@google.com
Re #7 - please file a new bug with a sample project that reproduces your issue.
pi...@gmail.com
Sim, eu tambem verifiquei os codigos do bug, eu achei o defeito e corrigi
Publiquei aqui:
https://pimentelservicos.app.br
Publiquei aqui:
pi...@gmail.com
Comment has been deleted.
Description
Version used: 1.0.0-alpha11
I'm seeing some strange behaviour when pressing back button and transistion back to a fragment from a fragment of the same id.
My app uses some generic fragment structures that are driven by args passed in, as such there are places like:
FragmentA -> FragmentB -> FragmentB -> FragmentC
However if the back button is pressed on the second instance of FragmentB, FragmentA is replaced in the navhost while the navgraph correctly displays in the toolbar. Forward navigation from this point however is missing from the navgraph and results in an IllegalStateException with the action 'not found' in the graph, unless the back button is pressed again (pushing the navgraph destination back to FragmentA)
Is this intended behaviour? If so is there a way to declare FragmentB as 'stackable'?