We went ahead and added the configChanges activity settings that have been suggested here previously in our app. Everything works great except I’m seeing that Images that use the painterResource() composable are not being updated when switching from light to dark mode. Has anyone else seen this?

Look into the implementation of stringResources, and you will find that before resolving the string from the context the configuration is resolved first, and not used. This is done to run the string reading logic every time the configuratioj changes.

go ahead and file it; checking the source real quick, it looks like

painterResource

is not subscribing to configuration changes the way the other resource functions do

Based on this you can create your own painterResource implementation which does just that

Thanks for the quick response! That makes sense. I did compare the code between those two, but I mistook the LocalContext.current call on the first line of painterResource to be LocalConfiguration.current. That totally makes sense

if the snippet above works it's probably an incidental artifact of the implementation; use at your own risk, future changes might not cause the invalidation of everything you're looking at

Noted

What do you mean by that? Wouldn’t that go against the concept of CompositionLocals?

It might cause

myPainterResource

to recompose, but that doesn't mean

painterResource

can't skip at some point if it believes nothing else it would return has changed

Also, be aware that you still need to handle/check for configuration changes. Things like wallpaper changes will cause a config change without a way to opt out IIRC.

the internal implementation of

painterResource

causing a re-check and reload of related things, if it does today, is also coincidental

Yeah, good callout @Colton Idle, we mainly wanted to add these settings so the common config changes like rotate and dark mode switch are a little more smooth.

How does

myPainterResource

differ from how `stringResource`s invalidate themselves?

@Composable
@ReadOnlyComposable
private fun resources(): Resources {
    LocalConfiguration.current
    return LocalContext.current.resources
}

I think the main difference is after this stringResource just uses the resources to read the current value of the string by the given id

@Alex Vanyo that utility is the inner composable being called. If it invalidates then it has to recompose, and so does the outer scope that called it

Ah so you can rely on a “side-effect” read (like

LocalConfiguration.current

without actually using the value) to “bubble up” to callers to force recomposition, but not to “bubble down” to other calls

yes

painterResource

is not subscribing to configuration changes the way the other resource functions do

Looking around that code more, I think only

stringResource

and company are subscribing to configuration changes, so probably everything else should also do so?

booleanResource

,

dimensionResource

, etc.

probably

To create an edge case that

booleanResource

should probably handle 😄

Issue Link: https://issuetracker.google.com/issues/228862715 I didn’t add a code snippet because it seemed pretty straightforward, but if that would help I can do so.