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.
ch...@google.com
Great! Thanks a lot, I'll look for the live updates soon!
il...@google.com
Moving this to the Fragment component since this is not related to Navigation - the same thing occurs when using fragment transactions directly when using setReorderingAllowed(true).
il...@google.com
an...@gmail.com
Is there any update on this issue? It's been reported in March.
jb...@google.com
li...@gmail.com
Is there any progress or workaround?
This issue may trigger many chain reactions, e.g. LiveData observer's onChange never be called.
il...@google.com
Re #7 - this is being actively worked on in the
il...@google.com
A postponed fragment will never reach onResume() (part of the contract of a postponed fragment is that it can only go up to STARTED), so the example project needed to be changed to use onStart().
That being said, this has been fixed internally and will be avilable in Fragment 1.3.0-alpha08.
Note: this fix relies on using the
Description
Version used: 2.0.0
The fragment I use as my startDestination uses postponeEnterTransition() and startPostponedEnterTransition() for transition purposes. When my app is opened though, that fragment is never actually visible.
This is because the Fragment does *not* receive onStart() or onResume(), so my data source is never setup, so I do not call scheduleStartPostponedTransitions(). The last lifecycle callback I get is onViewCreated().
If I remove the call to postponeEnterTransition() then everything works as normal, except my transitions.