hey all - is the best practice when using compose to still use fragments, or are the composable func...

# compose

[Matthew Laser]

hey all - is the best practice when using compose to still use fragments, or are the composable functions intended to just live in an activity without that layer

[iona bartishvili]

if you are migrating the existing app, i think that fragments should stay.

but in general, i think that there should be one entrypoint activity with all of its composables and compose navigation

[Matthew Laser]

that is kinda what I thought, though it's a legacy architecture and this is a completely disconnected UI flow that really won't need to interact with anything previous apart from initial launch

[iona bartishvili]

ye, in that case i think that its not necessary to migrate ui framework entirely. it will cause much more pain

[Marcin Wisniowski]

I have a single-activity app with fragments and the Navigation component. When moving to Compose I still use that, just put Compose in the fragments instead of XML.

[Ian Lake]

We talk about that in the context of Navigation Compose in the interop section of the docs: https://developer.android.com/jetpack/compose/navigation#interoperability

[Matthew Laser]

yeah I read that a bit - though I think I'm trying to understand that at the most basic level if fragments are suggested at all. For instance, in a non-compose world, I could stick an <http://R.layout.my|R.layout.my>_screen directly into an Activity if I wanted to, but for most "real world" use cases, it'll be in my best interest to attach a fragment to that activity, which uses <http://R.layout.my|R.layout.my>_screen inside of onCreateView.

I'm trying to understand if the compose tutorials / docs are sticking @Composable views directly into `Activity`'s setContentView for simplicity of explanation or as a best practice

[Ian Lake]

In a pure Compose app, there's no need for FragmentActivity or Fragment at all - you'd just use ComponentActivity and setContent directly. You'd still want to separate out the logic of each screen (either by using Navigation Compose or some other navigation system) into their own, separately testable/previewable composable

[Emre ERKAHRAMAN]

but you'd still need AppCompatActivity, for Dark Mode right ?