We went ahead and added the configChanges activity...

# compose

[Joseph Hawkes-Cates]

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?

[Joseph Hawkes-Cates]

I tried looking for issues in issuetracker and didn’t find any. Wanted to check here to make sure I’m not missing something before I log an issue.

[Csaba Szugyiczki]

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.

[Adam Powell]

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

[Adam Powell]

yeah what @Csaba Szugyiczki said 🙂

[Csaba Szugyiczki]

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

[Csaba Szugyiczki]

something like this should do the trick

@Composable
fun myPainterResource(@DrawableRes id: Int): Painter {
    LocalConfiguration.current
    return painterResource(id = id)
}

[Joseph Hawkes-Cates]

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

[Adam Powell]

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

[Joseph Hawkes-Cates]

Noted

[Csaba Szugyiczki]

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

[Adam Powell]

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

[Colton Idle]

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.

[Adam Powell]

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

[Joseph Hawkes-Cates]

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.

[Alex Vanyo]

How does myPainterResource differ from how `stringResource`s invalidate themselves?

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

[Csaba Szugyiczki]

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

[Csaba Szugyiczki]

painterResource does a lot more internally

[Adam Powell]

@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

[Adam Powell]

painterResource accepts only an Int as an argument, which would make it otherwise stable; there's no affirmative signal that painterResource must recompose if its caller recomposes

[Alex Vanyo]

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

[Adam Powell]

yes

[Adam Powell]

if you poke around the implementation of painterResource too you can see and imagine all sorts of other valid implementations that wouldn't trigger a reload of the resource from an outer recomposition either

[Alex Vanyo]

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.

[Adam Powell]

probably

[Adam Powell]

though if you're using `booleanResource`/`dimensionResource` and such from compose code it's probably because you're in a hybrid views/compose app and you're not globally turning off activity recreation for config changes anyway

[Adam Powell]

if you're in a compose-only app and you're using those, why? 🙃

[Alex Vanyo]

To create an edge case that booleanResource should probably handle 😄

[Joseph Hawkes-Cates]

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.