Google recently released the fragment-compose artifact with the AndroidFragment function. In short, this is the first first-party way to wrap a Fragment into a Composable function along with arguments. Previously, you could only draw the fragment's view using AndroidView or AndroidViewBinding, and everything else didn't work at all.
I'm very optimistic about this thing because it's, in my head, the only way to migrate navigation to Compose without rewriting all hundreds of existing project screens. And we want this because the idea of an application consisting of a hierarchy of Decompose components nested in each other looks very beautiful.
So, I got around to experimenting. And I'm rather disappointed. AndroidFragment is written in such a way that it simply creates an AndroidView with FragmentContainerView and executes an add transaction to FragmentManager in DisposableEffect, which is absolutely logical, of course. But in its onDispose a remove transaction is called, which seems to make this story completely unusable.
In practice, this leads to such an obvious situation: we simply navigate from AndroidFragment to another, for example, purely Composable screen, return back, and the fragment is recreated from zero state, and its ViewModel is reinitialized. Or we rotate the screen, everything is recreated.
With pure Compose, this doesn't happen thanks to the rememberSaveable mechanism. That is, even if the function left the composition, the memory of it is alive. However, even with pure AndroidView this doesn't happen, there's no FragmentManager which causes all the troubles.
In short, this is movement in the right direction (I praise), but there's a feeling that in this form it's at most for showing the deepest fragments in the hierarchy from Compose, and even then if we don't care about configuration changes.
Maybe I'm doing something wrong, but all the documentation so far is concentrated in changelogs and javadocs. Even the guides for using View in Compose haven't been updated.