When writing a scree-level composable, I always en...

# compose

[Stylianos Gakis]

When writing a scree-level composable, I always end up doing this, it’s in all such composables

AppTheme {
  Surface(color = MaterialTheme.colors.background) {
    // stuff
  }
}

to get the right theme + composition locals in place for the rest of the screen. The one thing that looks a tiny but suspicious is that I have to call surface and change the color to be background instead. Then use normal Surface with the default MaterialTheme.colors.surface for cards and other surfaces, so that there’s this difference between background and surface colors.
Does this look odd, is there some better composable I should be using for this situation?

[Nick Rout]

If you use a Scaffold or BottomSheetScaffold the default backgroundColor is MaterialTheme.colors.background.

Alternatively I guess you could do something like this:

@Composable
fun Background(
    modifier: Modifier = Modifier,
    content: @Composable () -> Unit
) {
    Surface(
        modifier = modifier,
        color = MaterialTheme.colors.background,
        content = content
    )
}

[Stylianos Gakis]

Yeah, we most often than not don’t use Scaffold as we don’t need anything but the TopAppBar, so no reason to add a SubcomposeLayout for no reason, we just do it in a Column, Scaffold only in very specific situations.
But yeah this composable makes a lot of sense, I was just double checking I’m not missing some existing API and introduce a new composable for no reason. Thanks a lot for the help 🤗

[Nick Rout]

No worries!

[Zoltan Demant]

The M3 scaffold also helps a great deal if youre using setDecorFitsSystemWindows(false), it basically does all the heavy lifting for you; I find it really really nice and havent needed to even think about statusbar/navigationbar paddings. YMMV 🙂

[Albert Chang]

Usually you just do this once in the root composable. Why do you need to add it to every screen?

[Albert Chang]

Also I would avoid Scaffold whenever possible because it uses subcompose layout under the hood and is less performant.

[Stylianos Gakis]

The M3 scaffold also helps a great deal if youre using setDecorFitsSystemWindows(false)

True that! Although in most cases I am only adding a TopAppBar, so the rest of the insets is easy to figure out.
With that said, with the scaffold case, you get those insets passed in as PaddingValues in the content lambda, that means that if you apply them to the entire content composable, your content won’t actually render behind the navigation bar for example right? More often than not, I do want to render behind, so I don’t want that, and instead have in my column a

Spacer(Modifier.windowInsetsPadding(WindowInsets.safeDrawing.only(WindowInsetsSides.Bottom)))

at the end, meaning that if I scroll up the content does draw under the system bars.

If I have a LazyColumn or some composable which accepts a contentPadding you can pass it in there, but if you got a normal Column for example it wouldn’t work, so still, doing it myself has proven to be easier tbh.

[Stylianos Gakis]

Usually you just do this once in the root composable. Why do you need to add it to every screen?

I am in this app which is activity-based for all screens 🥲, so each of the activities (I referred to them as screens) is like starting from scratch, I can’t rely on the top level root composable, hence why I in particular need to do this often.

[Albert Chang]

I'm not sure what you mean exactly by "screen" but if you are putting it in the screen composables (e.g. @Composable fun MainScreen()), I would say it's better to put it in your activities instead. If you are already putting it in the activities, I don't think it's odd at all.

[Zoltan Demant]

I agree with @Stylianos Gakis; if you were to keep a Scaffold at the root, then you wouldnt be able to pass around the paddingValues (without severe pain anyhow)? For example, Ill pass them into whatever layout Im using in the content block, with LazyColumn the content automatically flows under the statusBar that way, etc.

[Zoltan Demant]

Ive heard about SubcomposeLayout being less performant than other layouts, but how much are we talking? Ive never noticed any issues, despite using it for every screen!