Matti MK
04/22/2025, 5:14 PMpadding
or height
?
The Compose Resources doc mentions the dimensionResource API, and it is used in some codelabs like Simple Animation with Jetpack Compose. This leads me to think we should maybe use the dimensionResource
API. However, there are some other points that make me reconsider:
• The Migrating to Jetpack Compose codelab mentions the following: "Compose provides convenient methods to get values from the dimens.xml
... With this, you have the View system as the source of truth"
◦ I'd rather stay away from the View system
• Dimensions are not used anywhere in the NIA app, for example the Catalog.kt
has multiple hardcoded padding values, for example here.
◦ NIA is not a small app, and as such I'd imagine they'd use the "best" approach available
So far I can tell there's three clear options:
1. Hardcode dimensions
2. Use dimensionResource
3. Use a CompositionLocalProvider
to provide the values
Opinions on which way to go?mattinger
04/23/2025, 6:25 PMdimensionResource
is not something i'd personally consider part of the "view system". It's part of the "resource system". Think of it as being equivalent to the stringResource
function.
It has the same advantage as stringResource
in that it will automatically resolve qualifiers like screen size, language, orientation, etc... for you, rather than you having to hardcode all that logic in a composable.
I'm not saying there is a hard and fast rule to always use dimensionResource
as most of the time, you don't need to change these values based on qualifiers. But if you find yourself checking these things in code and writing a lot of if/then/else or when statement for this, consider putting in a resource file and using this function.
Bottom line is it's use case dependent on what your best approach is. What i will say is that CompositionLocalProvider
should be used sparingly, as it does have overhead involved with itMatti MK
04/24/2025, 11:04 AM