Isn't reading dimensions or other legacy xml resou...

# compose

[Pablichjenkov]

Isn't reading dimensions or other legacy xml resources files in Android, slow for compose. Shouldn't compose warn about this and promote direct constant/enum declaration/usage of things like dimensions and colors potentially strings, in plain kotlin files.

[Pablichjenkov]

This subject came over a PR argument about using dimensions from the xml resource file in Android. But on the other hand Themes and Colors are using plain kotlin files. Why should dimensions be an exception.
Strings I get it because they consume a lot of RAM, but DP dimensions I think makes no sense reading them from an Xml file

[yschimke]

I hope android optimises the build so at runtime so it's not XML parsing.

[jw]

It's always been a binary format that represents hierarchical key/value pairs. It's not doing plain XML parsing.

[jw]

And unless you've actually measured it as a problem, I would not expect it to be a problem. It was load bearing on the entire view system for 20 years. It's a highly-optimized codepath.

[Pablichjenkov]

Right Yuri, I assumed that optimization was part of the XML view system when a specific view was inflated but had my doubts in compose.
Oh thanks J, ai couldn't give me that response for more than I asked lol. But all clear now.

[Rafs]

In that case, what would be the recommended approach for new apps, xml dimensions or hard coding .dp values in modifiers?

[jw]

I think everyone prefers values in code

[stefanober]

I think hardcoding .dp values directly in modifiers is never the recommended approach. I personally use a wrapper object with consistent Dimension-values (8, 16, 24, 32.dp) that can be reused everywhere.

[Pablichjenkov]

I personally prefer values in code. However, when this project adopted Compose we always used the resources approach. But fresh minds have joined the team recently and have challenged the resources approach. Then in a discussion about which one would be more performance friendly, this question showed up. But it is clear performance is good in both, however, a search in a map won't beat a direct reference access in a constant file. So at the end the "constants in code approach" is faster and cleaner.