https://kotlinlang.org logo
#compose
Title
# compose
m

Mark Murphy

08/05/2019, 10:41 PM
Are there particular issues with using Compose in a fragment? This code builds and runs fine, though admittedly it does not do much:
Copy code
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:
Copy code
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.
l

Leland Richardson [G]

08/05/2019, 10:48 PM
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
❤️ 3
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
m

Mark Murphy

08/05/2019, 10:50 PM
Things seem much happier with
import androidx.compose.composer
-- thanks!
t

themishkun

08/06/2019, 8:42 AM
But why do you want to use fragments with jetpack compose at all, excluding interop?
m

Mark Murphy

08/06/2019, 11:06 AM
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.
t

themishkun

08/06/2019, 12:52 PM
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
Optionally, you can have your own backstack, which would be just a list of your enum/sealed class
m

Mark Murphy

08/06/2019, 1:06 PM
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!
🙂 1
t

themishkun

08/06/2019, 1:14 PM
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
👍 1
4 Views