Are there particular issues with using Compose in ...

# compose

[Mark Murphy]

Are there particular issues with using Compose in a fragment?

This code builds and runs fine, though admittedly it does not do much:

class SampleRosterFragment : Fragment() {
    override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View =
        inflater.inflate(R.layout.empty_frame, container, false)

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        (view as ViewGroup).setContent {
            Padding(10.dp) {
                
            }
        }
    }
}

This code causes the IDE and Gradle to go ballistic, with inscrutable error messages:

class SampleRosterFragment : Fragment() {
    override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View =
        inflater.inflate(R.layout.empty_frame, container, false)

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        (view as ViewGroup).setContent {
            MaterialTheme {
                Padding(10.dp) {

                }
            }
        }
    }
}

Yet that same MaterialTheme construction works fine from an activity.

I notice that the demos seem activity-centric, though I'm not certain if that is due to current Compose limitations or is tied to other concerns for how you are using those activities.

[Leland Richardson [G]]

Shouldn’t be any limitations with fragments.

I’m gonna make a wild guess as to what’s going on here. There are a couple of latent bugs with the compiler that you’re running into here that are hard to spot.

1. my guess is you are missing an import androidx.compose.composer at the top of this file. This import is currently needed, but the IDE marks it as unused and sometimes removes it.
2. the first example is “working” because you have Padding(10.dp) and not Padding(padding=10.dp). There is currently an issue where calls to composable functions that don’t use named arguments end up going down a code path that fails in terms of doing the right code generation, but doesn’t fail enough to complain

[Leland Richardson [G]]

these are frustrating bugs that will hopefully be fixed soon, but are being blocked by a rebase with kotlin master that i’ve been working on which is taking longer than we had thought

[Mark Murphy]

Things seem much happier with import androidx.compose.composer -- thanks!

[themishkun]

But why do you want to use fragments with jetpack compose at all, excluding interop?

[Mark Murphy]

In the long term, I expect that I will replace the fragments with something more Compose-native. Right now, my experiments have to go somewhere. The demos seem dominated by a "one activity to one experiment" model, and IMHO that's a pain. So, I was planning on organizing my experiments into fragments.

If you have another suggestion, I'd love to hear it. Eventually, I might stumble upon the Compose pattern for transitioning from one screenful of UI to another screenful of UI, but I don't know what that is yet.

[themishkun]

I have a suggestion for you. Use single activity for the whole app and an upper level Compose function that will call different Screen-level Compose functions based on some kind of enum or sealed class

[themishkun]

Optionally, you can have your own backstack, which would be just a list of your enum/sealed class

[Mark Murphy]

While that is simpler than how the demos are set up, it seems to run counter to Google's current direction outside of Compose. The Jetpack philosophy is to have few activities, perhaps just one (see the ViewModel system, the Navigation component, etc.). I suppose it is possible that they would retreat from that approach and go with one-activity-per-screen, but it seems unlikely. I am assuming that there will be some other pattern emerging that will avoid fragments yet will still have few activities.

Plus, part of my experimentation will be on patterns for how to migrate to Compose from existing code. Developers who try to adhere to current Jetpack guidelines will have lots of fragments and few activities. A likely migration step to Compose will be to keep the fragments for a while, but replace their layouts with @Composable functions. After that, they would start looking into replacing the fragments with... whatever comes next that ties Compose into the Navigation component.

I might use your suggestion for some of my early explorations of the @Composable functions supplied by the Compose libraries, though. Thanks for the recommendation!

[themishkun]

Yeah, the thing I proposed kinda throws out the ViewModel and NavigationComponent, but I think that they are the bandaids for the current problems of the outdated UI framework. With the approach Compose enables you really don`t need much of these tools, because it offers more straightforward and controllable way to do UI development