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

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

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

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

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.

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

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

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

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