I'm kind of going crazy on not being able to get this layout to look quite right in my app. Essentially, the top horizontal bar is a carousel made up of RedComposable's, and then there is a green composable list, which is a vertical scrolling column. The GreenComposable includes a RedComposable. The trouble I'm having is how to size the RedComposable. My design team said "The Red should be 40% of the green, and then that size of the red should be used in the horizontal scroller" How would I do that in compose?

I would start with measuring column width (eq.

onSizeChanged

), then I would use that size to compute size of GreenComposable (eg. subtract column paddings, ..), then I would derive RedComposable from that. If the performance is not good enough (there will be unnecessary layout passes due to laziness of this solution), I would try to create

SubcomposeLayout

to see if can spare some layout passes.

Assuming you only care about screen width, you could query

LocalConfiguration.current.screenWidthDp

to get the device width, then do a calculation based on the horizontal padding you plan to have on the green Composables list. Save that as a variable hoisted to a place in your hierarchy that can control the top Red container and the green list, and go from there

You can just use

Modifier.fillParentMaxWidth(fraction = 0.4f)

in a

LazyRow

.

I think though that value needs to be then passed to size the red Composables in the top container

I mean use that in the top container:

LazyRow(
    modifier = Modifier.fillMaxWidth(),
    contentPadding = PaddingValues(16.dp),
    horizontalArrangement = Arrangement.spacedBy(16.dp)
) {
    items(10) { i ->
        Text(
            text = (i + 1).toString(),
            modifier = Modifier
                .fillParentMaxWidth(fraction = 0.4f)
                .height(100.dp)
                .background(color = Color.Red.copy(alpha = 0.2f))
                .wrapContentSize()
        )
    }
}

Oh yeah good call!

Hm. And then my GreenComposable would just fill the max width (with 16 horizontal padding), and the RedComposable would again be set to .4f width of the GreenComposable? So in that solution @Albert Chang I'm not actually "saving" a width value anywhere for green and reusing it... I "just so happen" to get the same width through a use of width modifiers?

Yes. Note that you need to adjust the paddings in order for them to be exactly the same width:

LazyRow(
    modifier = Modifier.fillMaxWidth(),
    contentPadding = PaddingValues(horizontal = 16.dp * 0.8f, vertical = 16.dp),
    horizontalArrangement = Arrangement.spacedBy(16.dp * 0.6f)
) {
    items(10) { i ->
        Text(
            text = (i + 1).toString(),
            modifier = Modifier
                .fillParentMaxWidth(fraction = 0.4f)
                .height(100.dp)
                .padding(horizontal = 16.dp * 0.2f)
                .background(color = Color.Red.copy(alpha = 0.2f))
                .wrapContentSize()
        )
    }
}

Hm. You lost me at adjusting the paddings...

16.dp * 0.2f

and

16.dp * 0.8f,

?

Modifier.fillParentMaxWidth(fraction = 0.4f)

makes the width 40% of screen width, however you want it to be 40% of (screenWidth - 16dp), so you need to add a padding of (16dp * 20%) on both sides, and accordingly substract that from contentPadding and subtract 2 * that from spacing between items.

Hm. I don't think that extra calculation is needed?

Oh yeah, seems that the parent size is already the size with contentPadding applied.

Awesome. Thought I was going crazy. That works sort of nicely then.

They can and should be the same component. You should always provide a Modifier parameter.

I read that article this past weekend. But yeah, I think maybe lemme give a whirl of how itd look like if it was shared.

You can always set the default Modifier in your function parameter to

Modifier.width(<usual size>)

@Chris Sinco [G] for "You can always set the default Modifier in your function parameter to 

Modifier.width(<usual size>)

" Where would I put that? In the RedComposable?

Yes the signature of the RedComposable function

Oh. I think I know what you mean. So you mean like this

@Composable
fun RedComposable(text: String, modifier: Modifier.width(200.dp)) {
    Text(
        text = text,
        modifier = modifier
            .height(100.dp)
            .background(color = Color.Red.copy(alpha = 0.2f))
            .wrapContentSize()
    )
}

wrapContentSize()

(with the

align

parameter set to its default value

Alignment.Center

) aligns the text at the center. Without that the text will be placed at the top start. You can also use

Text(textAlign = TextAlign.Center)

to align the text at the center horizontally but that doesn’t change vertical alignment.

ooh. interesting. thanks albert.

Haha well you can still use the RedComposable as a component and pass whatever value you want in, even if that's screenWidthDp ;)

the screen width approach will completely nuke any drop in reusability of the component though, just something to keep in mind for future tech debt, when using this screen in a dialog / on the desktop or a tablet in a column etc

What's your suggested solution to it?

Probably

BoxWithConstraints

Running into a similar use case, came across this thread. @Colton Idle its been a while but do you recall what your solution was? (to make matters worse, for me everything is supposed to live in a

LazyColumn

) 🙏🏼

IIRC and my biggest thing I took away from this was the fact that I stopped sizing my composables inside of the composable. Basically what @Chris Sinco [G] said

Then you can always override the width where you use the RedComposable based on the context / parent container

So a technique I was mostly taking was that "hey wouldn't it be convenient if this composable always just knew it should be fill max width" and after chris' comments and the rest of the comments above I basically conceded to the fact that it's kinda like not doing dependency injection. Sure. Having a class where I don't have to pass in a bunch of services to make it work correctly is convenient, but its extremely limiting. So yeah. I basically typically have composables take up the least amount of space possible, and then have a modifier so it can be adjusted based on its context.