IssueTracker

Jetpack Compose release version: Compose alpha11 Android Studio Build: Arctic Fox Canary 4

There appears to be a number of issues with inflating a fragment by using AndroidViewBinding:

1. If you use FragmentContainerView, the fragment appears the first time the container is inflated, but later times it does not appear.

2. If you use <fragment>, the fragment appears the first time the fragment is inflated, but will crash if you try to re-inflate the same layout a second time. Rotating your screen or otherwise recreating the Activity will reset it so that the first inflation works

3. In both cases, removing the AndroidViewBinding from your compose hierarchy does not remove the underlying Fragment from the FragmentManager. This means that the Fragment remains in memory forever afterwards.

I've attached a sample project that contains three situation (using FragmentContainerView, using <fragment>, and manually doing a FragmentTransaction in Compose code) and a 'Show' button of each that lets you confirm what happens when the AndroidViewBinding is removed from the hierarchy.

My investigation lead to a couple of discoveries:

• After a configuration change, the whole activity and the FragmentManager has moved to the RESUMED state before the compose hierarchy is processed and AndroidViewBinding is able to inflate its container. This means the original fragment added via the inflated FragmentContainerView has already had its view created and moved to the RESUMED state before the container exists. Thus, the transition between onCreateView() and onViewCreated() where the view is attached to its container has already passed when the AndroidViewBinding creates the container.

• The <fragment> tag added fragment never goes above the CREATED state on its own - Fragments is correctly stopping it from going higher than CREATED during the inflation, but because Compose is inflating it after the FragmentManager has already moved through RESUMED, the usual moving of state for <fragment> inflated fragments doesn't happen. Doing another FragmentTransaction on a different fragment/container moves it to STARTED, but it never moves to RESUMED as no FragmentTransactions on that container are pending (and moving to RESUMED is done at a container by container basis) as the <fragment> tag doesn't actually do a FragmentTransaction.

• It is expected that when a composable is removed from the hierarchy that any internal state is thrown out (that's why you'd normally hoist state you want to save). Because Fragments are never removed when the AndroidViewBinding is removed from the hierarchy, the Fragments keep their state over a removal / addition of a new element that happens to inflate that same layout.