Fixed
Status Update
Comments
ap...@google.com <ap...@google.com> #2
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.
ap...@google.com <ap...@google.com> #3
Great! Thanks a lot, I'll look for the live updates soon!
jb...@google.com <jb...@google.com> #4
This has been fixed internally and will be available in the Fragment version 1.3.1
release.
ad...@gmail.com <ad...@gmail.com> #5
I am still experiencing this issue in versions 1.3.1, 1.3.2 and 1.3.3 of the fragment library. (The latest version of the fragment library at the time of writing is 1.3.3.)
Given that this issue is closed and marked as fixed, I've created a separate issue
Description
When using the new fragment state manager , if a fragment is inflated after the host activity is RESUMED, via either the deprecated , the fragment never makes it to a RESUMED state.
<fragment>
tag orFragmentContainerView
In the case of the
<fragment>
tag:VIEW_CREATED
and never makes it any furtherfor
FragmentContainerView
:RESUMED
the first time, but on configuration change, the view that inflates the fragment is never attached to the new view hierarchy, so the fragment isRESUMED
but never actually visible.We should address this issue for both components. aosp/1591056 and aosp/1593053 have been implemented for the
<fragment>
tag case. This bug will track theFragmentContainerView
case.