I have a question regarding using `Layout` how it s used in

Question

I have a question regarding using `Layout` how it s used in the implementation of Column|Row measure policy and in a codelab More in thread thread

Stylianos Gakis · Answer

I was looking at this which initializes something right before the `layout` call just like I can see it s done in this in the code snippet right above the MyOwnColumn in action section However then looking for this in cs android I found which is the same snippet but with the y coord being initialized inside the `layout` block From my understanding that `layout` block can be called independently from the rest and more than one time as which makes me feel like you d want to make these initializations be inside the block in which they are being used Does it just not matter or are some of these snippets slightly wrong or am I missing something

Albert Chang · Answer

What are you actually concerning The only difference is that `mainAxisPositions` won t be GCed after layout block is executed

Stylianos Gakis · Answer

What I was basically wondering is that if yPosition is initialized outside of the `layout` block as 0 for example But the `layout` block is called twice wouldn t the old reference of yPosition still be referenced which after the first `layout` call was made it d not be 0 anymore And if that s not the case how is it not the case It just feels like a basic concept that both calls to it are referencing to the same mutable variable that is outside of their scope which would mean that it might interfere with each other I must be missing something feeling kinda dumb even asking this but what is it that I am missing Unless the `layout` block isn t just called separately from the rest of the code that s above as I understood from the `Deep dive into Jetpack Compose layouts` video that I linked in my comment above

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

It looks like that array is used to store the output of the arrangement function which means it s always going to be written to first before being read later in the layout block

Stylianos Gakis · Answer

Aha I see what you mean for the arrangement block it s a bit less simple than the other example so let s focus on the simple example with the yPosition In the codelab snippet the `yPosition` isn t written to first It s instead initialized outside of the `layout` s `placementBlock` and it s then being read and written to inside the `layout` s `placementBlock` block

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

There were a lot of links lol which one are you referring to now

Stylianos Gakis · Answer

Yeah mb I was referring to this <https developer android com codelabs jetpack compose layouts 6|codelab> now on the 2nd from last snippet right above the text that reads MyOwnColumn in action

Stylianos Gakis · Answer

And I was referring to how in <https cs android com androidx platform frameworks support + androidx main compose integration tests docs snippets src main java androidx compose integration docs layout CustomLayouts kt l=131 132 q=Track 20the 20y 20co ord 20we 20have 20placed 20children 20up 20to|this> snippet in cs android it is initialized inside the `layout` block as I would suspect would be the correct way to do this Since from the video I linked they imply that this block may be run independently and I d assume it would want to not use old references to a mutable variable that may have been mutated from a previous call to this block I am having a bit of a hard time to explain exactly what I am referring to considering there are so many things I am referring to sorry for that please point out if something still doesn t make sense so that I can help clarify

Albert Chang · Answer

Yeah I think in the codelab case it can be a problem though there is no state reads in the layout block so it won t actually be re run independently Surely better to not rely on this behavior

Stylianos Gakis · Answer

Alright so it is a potential problem then Even if there s no state being read inside this layout doesn t mean that just like in that video there could be some other modifier which does do that making all the layout blocks to be re run making this potentially work wrong right If that s the case maybe this codelab may need this to be fixed to avoid people referring to it to get inspiration for similar use cases and having things work wrong for them

Albert Chang · Answer

I think in 1 1 layout modifiers actually have their own scope See <https android review googlesource com c platform frameworks support + 1769926 |this CL>

Stylianos Gakis · Answer

Not sure I understand this but by have their own scope I assume that means their own recomposition scope if you can call it that idk I mean that it will run again if some state has changed that s referenced inside that block s scope But having their own scope doesn t mean they re not accessing the common mutable state that s outside of their scope does it The fact that they might re run individually without having the outer block run if anything makes this case possible since that yPosition would be referencing the same old reference which is not 0 I believe I am really out of my league with this discussion tbh maybe what I m thinking about doesn t make sense sweat smile

Albert Chang · Answer

I don t actually understand what you mean Layout modifiers can be re run individually without the layout block in `Layout` being re run so `yPosition` is irrelevant here The result of `Layout` is cached and layout modifiers can t access `yPosition`

Stylianos Gakis · Answer

Anyway I don t know how to better explain what I meant aside from this <https kotlinlang slack com archives CJLTWPH7S p1648137232093579 thread ts=1648129488 652169 amp cid=CJLTWPH7S|comment> here so if that doesn t make sense then whatever I appreciate you trying to help though of course

Albert Chang · Answer

I understand the comment you referenced and it is indeed a potential bug That s why I said Surely better to not rely on this behavior I was arguing against this part gt Even if there s no state being read inside this layout doesn t mean that just like in that video there could be some other modifier which does do that making all the layout blocks to be re run

Stylianos Gakis · Answer

Aha now I get it Sorry I got a bit confused about which thing you were referring to So what I said there is wrong because as you said it would simply not re run if that itself doesn t read the state that has changed Again thanks for bearing with me on this one I feel a bit more comfortable with these concepts now after this discussion raised hands