IssueTracker

The only currently supported strategy for adding Fragments to compose is via AndroidViewBinding. Are you familiar with this approach?

Yes, I am familiar with AndroidViewBinding, however, as far as I know it has some limitations, like, I can't decide at runtime what fragment to commit.

I also can't give parameters to the fragment being inflated.

Hey, Thanks to checking this out, I just checked this sample in the the repository, but this does not solve my issue.

I don't have access to the actual fragment class, we use an abstraction that just returns me a instance of Fragment with the arguments set, so this won't solve the issue for me, would it be possible to allow passing the Fragment instance ?

Re comment#6 - no. AndroidFragment uses the FragmentFactory you've set on your FragmentManager to instantiate fragment instances, ensuring that every construction of the fragment, from the initial one to the one after process death and recreation all go through the same route.

This aligns with other fragment based APIs like FragmentScenario and NavHostFragment. You'll want to adjust your own abstraction to use those APIs and separate the creation of the fragment instance from the arguments.

I'll note that FragmentFactory does allow you to request an AbstractBaseFragment and redirect it to a specific subclass of that class without exposing that subclass itself if you do need that level of indirection.

We were always allowed to create a new Fragment and to commit a Fragment instance in FragmentManager, could you align with that as well? My abstraction returns a Fragment instance because this allows us to avoid directly depending on the gradle module that provides the Fragment and this strategy improves compilation time by making the gradle dependency graph flatter.

You'll want your abstraction to be implemented in terms of a FragmentFactory.

My abstraction does not use fragmentFactory, and don't need to. How is that related to this issue? Devs have always been able to instantiate a fragment using default fragment constructor, I am not exposing which Fragment subclass is being instantiated in the calling site or using the className as key to find which fragment to instantiate, to add a fragment to FragmentManager we just need the base class Fragment.

Re comment#12 - you can surround the AndroidFragment with key(url) to reset that subtree whenever url changes.

Thanks, using key(url) works like a charm. I thought this function was only available for LazyList|Column...

For your information we have the following crash using AndroidView:

Exception java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState at androidx.fragment.app.FragmentManager.checkStateLoss (FragmentManager.java:1) at androidx.fragment.app.FragmentManager.ensureExecReady (FragmentManager.java:1) at androidx.fragment.app.FragmentManager.execSingleAction (FragmentManager.java:1) at androidx.fragment.app.BackStackRecord.commitNow (BackStackRecord.java:1) at androidx.fragment.compose.AndroidFragmentKt$AndroidFragment$4.invoke (AndroidFragment.kt:110) at androidx.fragment.compose.AndroidFragmentKt$AndroidFragment$4.invoke (AndroidFragment.kt:3) at androidx.compose.runtime.DisposableEffectImpl.onRemembered (Effects.kt:7) at androidx.compose.runtime.CompositionImpl$RememberEventDispatcher.dispatchRememberObservers (Composition.kt:144) at androidx.compose.runtime.CompositionImpl.applyChangesInLocked (Composition.kt:1) at androidx.compose.runtime.CompositionImpl.applyChanges (Composition.kt:6) at androidx.compose.runtime.Recomposer$runRecomposeAndApplyChanges$2$1.invoke (Recomposer.kt:1) at androidx.compose.runtime.Recomposer$runRecomposeAndApplyChanges$2$1.invoke (Recomposer.kt:7) at androidx.compose.ui.platform.AndroidUiFrameClock$withFrameNanos$2$callback$1.doFrame (AndroidUiFrameClock.android.kt:11) at androidx.compose.ui.platform.AndroidUiDispatcher.performFrameDispatch (AndroidUiDispatcher.android.kt:34) at androidx.compose.ui.platform.AndroidUiDispatcher.access$performFrameDispatch (AndroidUiDispatcher.android.kt:1) at androidx.compose.ui.platform.AndroidUiDispatcher$dispatchCallback$1.doFrame (AndroidUiDispatcher.android.kt:17) at android.view.Choreographer$CallbackRecord.run (Choreographer.java:1229) at android.view.Choreographer$CallbackRecord.run (Choreographer.java:1239) at android.view.Choreographer.doCallbacks (Choreographer.java:899) at android.view.Choreographer.doFrame (Choreographer.java:827) at android.view.Choreographer$FrameDisplayEventReceiver.run (Choreographer.java:1214) at android.os.Handler.handleCallback (Handler.java:942) at android.os.Handler.dispatchMessage (Handler.java:99) at android.os.Looper.loopOnce (Looper.java:201) at android.os.Looper.loop (Looper.java:288) at android.app.ActivityThread.main (ActivityThread.java:7918) at java.lang.reflect.Method.invoke at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:548) at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:936)

Will there also be an overload in which we can directly pass in an already created fragment instance? Like:

fun <T : Fragment> AndroidFragment(
    fragment: T,
    modifier: Modifier = Modifier,
    fragmentState: FragmentState = rememberFragmentState(),
    arguments: Bundle = Bundle.EMPTY,
    onUpdate: (T) -> Unit = { },
) { ... }

Re comment#15 - please file a separate issue so we can track that crash.

Re comment#16 - no, as explained in comment#7.

I could not reproduce the crash above with 1.6.0-alpha01

The steps I took where:

1. Created a new android project using Android Studio Giraffe | 2022.3.1 RC 1
2. Replaced Greeting with the code in #1 (fixing the imports)
3. Ran the program
4. Pressed the button (crash reproduced)
5. Added the line implementation("androidx.compose.runtime:runtime:1.6.0-alpha01") to the dependencies
6. Update the compile sdk to 34.
7. Sync'ed gradle
8. Ran the program
9. Pressed the button (no crash)

Note the above fix is only a partial fix. There are cases that will continue to violate the implied constraint until the second part of the fix lands (explained above).

Also note that this doesn't guarantee the constraint implied by the assert will always hold, only that the runtime will try to avoid recomposing sub-compositions that might be exposed to the constraint. Any use of sub-composition can violate this constraint as the value might change between the time the main composition composes and the sub-composition composes and before the main composition can be recomposed to remove the sub-composition.

If you require consistency between a composition and its subcomposition you need to capture the state as #5, above. This change just avoids a common case would violate this constraint.