Hi, what's the sense of concatenating wrapContentS...

# compose

[Pablo]

Hi, what's the sense of concatenating wrapContentSize to fillMaxSize in a Modifier? I mean this:

Modifier
    .fillMaxSize()
    .wrapContentSize()

They do it in a compose sample of a Android development guide from official android guides. ( https://developer.android.com/codelabs/basic-android-kotlin-compose-build-a-dice-roller[…]abs%2Fbasic-android-kotlin-compose-build-a-dice-roller-app )
I mean... fillMaxSize does that the view fills the entire screen, and wrapContentSize does that the view uses only it's size.. so I don't understand why use both at same time. They do it to center the view, passing an argument to wrapContentSize, but I just can't understand this way of achieving it. I mean.. if you wanna center a view, you supposedly put that view in a bigger container and center it, but passing a "fillMaxSize" and a "wrapContentSize" to center it is very strange.

[Chrimaeon]

But with this approach you spare the container. It’s up to you what you prefer. It just another method to center a composable.

[Pablo]

can you explain me the sense of this?

[Pablo]

why setting wrap content size to a fill max size haves sense? I really wanna understand it

[Pablo]

how can this work? it haves no sense for me

[Pablo]

coming from views... I imagine setting match parent and wrap content to a view, and has no sense

[Chrimaeon]

you know that modifiers are executed in the order they are applied. So first the the fillMaxSize modifier tells the measurement phase that this view wants to consume the max available space. that’s then mesured and passed to the next modifier, the wrapContentSize , which then calculates with the fillMaxSize contraints to shrink back down to wrap the content and with the alignment parameter used in the codelab, center the view.

[Chrimaeon]

so you should not compare modifers to xml layout params. they behave completely different.

[Chrimaeon]

this might help to understand better:

https://www.youtube.com/watch?v=OeC5jMV342A&ab_channel=AndroidDevelopers▾

[romainguy]

@Pablo The View system had somewhat nonsensical setups sometimes. For instance a layout marked wrap_content and a single child marked match_parent. How big should the result be?

[Pablo]

Romain Guy, I never tryed that, is nonsense too, but that seems not to be a recommended practice.

[Pablo]

@romainguy in this case, they are recommending that non sense practice in a official guide

[Pablo]

I mean that it MUST have sense, but it's hard for me to understand why should I tell a view that must fill max size and also must wrap its size to its content and then, by some logic I dont know, it will work, and also... being a recommended practice in an official guide. I'm sure that understanding why this works and how it works, will help me in my progress improving my Compose knowledge

[Pablo]

I viewed that video from Christian and it is good to know how modifier works concatenating calls, but I'm still not understanding why should I tell to fill max size and then tell to wrap size to the content

[Pablo]

it feels strange to write that

[Zach Klippenstein (he/him) [MOD]]

you can sometimes just use wrapContentSize. It will center its content in the minimum constraints if smaller, but most of the time it will have a minimum size of 0, so it won’t need to center. It’s up to the layout in which that’s placed to decide whether to pass a minimum size or not, and then where to place that minimally-sized element within the available space. Many components will default to placing it in the top-start corner, i.e. IntOffset.Zero. To override that behavior, that’s why you need fillMaxSize, so the parent can place it at Zero and wrapContentSize can then use all that space.

[Pablo]

I think it is easy to agree that it is very confussing

[Pablo]

let's say it's not human reading/understanding friendly to put wrapcontentsize after a fillmaxsize

[Pablo]

I still don't fully get it, but I'll try to simply memorize it, that it will work. I hope I'll not find more of these kind of non sense concatenations in the future. As I can remember from my first steps on the first guides, kotlin and compose are meant to be more easy to read and understand than java/views

[Pablo]

thank you very much guys for helping me with this, I'm sure making this effort in understanding everything will help me to improve

[Chrimaeon]

You’ll also find something like

Modifier.background(Red).padding(8.dp).background(Green)

So you set the background twice on one composable but it will look like having a border. 😉

[Zach Klippenstein (he/him) [MOD]]

It’s not nonsense just because it’s not untuitive. It is very consistent with Compose’s box layout model.

> For instance a layout marked wrap_content and a single child marked match_parent. How big should the result be?
That’s nonsense.

[Zach Klippenstein (he/him) [MOD]]

Another way to think of it is with composables:

Box(Modifier.fillMaxSize(), contentAlignment = Alignment.Center) {
    YourComposable()
}

In this case, Box by default doesn’t propagate min constraints, so wrapContentSize is not needed. The outer box is still required to fill max size, otherwise it would shrink to the the size of YourComposable.

[romainguy]

@Chrimaeon you're not setting a background here. You can think of modifiers as add-ons you attach to the Composable

[Chrimaeon]

Sure, it should just show how modifiers are evaluated.

[Zach Klippenstein (he/him) [MOD]]

idk if this helps