Reading through the per-app language <documentatio...

# compose

[Stylianos Gakis]

Reading through the per-app language documentation, there’s a part which says “Note that calling setApplicationLocales() recreates your Activity, unless your app handles locale configuration changes by itself.”
Now I remember reading some discussions here, like this one where @Adam Powell suggests that compose handles those itself anyway.
Shouldn’t that mean that the documentation should reflect this behavior if it’s also the case for this config change too? It’d be great to know that directly from there without needing to be part of this slack channel.

[Michael Paus]

But that would only work if you have a pure Compose app and you have configured the suppression of the activity recreation in the manifest of that app, which will not be the case for all apps automatically.

[Stylianos Gakis]

“Pure compose app” I wonder what this means actually.
If it’s a multi-activity app, this would apply if for that specific activity you only had compose on and fill the list of configChanges right?

If it’s not only compose, does it work if the root is a composable but maybe you have some AndroidViewBinding in the middle? Does it work if the root is a XML layout but some children are composables? Do maybe only the composable parts of it get invalidated? Hmm not sure tbh

[Michael Paus]

You might just give it a try and see what happens in your second scenario if you switch off the config changes in the manifest 😉.

[Stylianos Gakis]

Yeah I haven’t tested such scenarios, I haven’t played with the idea yet that’s the thing, I’m just curious hence I’m starting this discussion.

Is that the issue then? If there’s any of the interoperability APIs used it breaks the entire thing? Even if let’s say the View part is fine without reacting to the config changes?

[Adam Powell]

It's situational for your app. The inflated viewbinding example is a good one; if you had different layout resources for different configurations, it wouldn't be automatically reinflated unless you specifically accounted for it in your own code

[Adam Powell]

Or if your single layout xml referred to other resource constants that vary by configuration

[Alex Vanyo]

Locale is also a good example where it’s easy to have subtle bugs when you’ve previously been operating in a world when activity recreation does the heavy lifting for you.

If you call Locale.getDefault() (or a built-in method that uses it under the hood), then that use of the locale isn’t snapshot-state aware, so it won’t necessarily get updated. Or for a custom View, you’d need to listen to View.onConfigurationChanged to update yourself.

With activity recreation, you could usually use Locale.getDefault() and be just fine because you’d end up calling it again as everything was reconstructed.

Activity recreation is the original “reemit the UI when something changes”

[Stylianos Gakis]

Aha that's also a concern. In a full compose app, which would recompose itself, it'd still be a problem right? If the component that happens to read the locale doesn't get recomposed that is.
Because as I understand, the way compose handles these config changes itself is that they get updated and only if you're actually reading them somewhere things get recomposed. Like if the screen width changes everything will recompose, but if locale changes, there will be nothing recomposing if there's nothing reading the locale right?
Trying to wrap my head around how all this works with compose and configChanges tbh still.

[Adam Powell]

yes; specifically, if locale changes nothing will recompose if there's nothing reading the locale from a place that invalidates that locale read in a way that compose understands.

[Michael Paus]

But if that is indeed the case then it means that Compose does not properly handle configuration changes at all. That comes a little bit as a surprise now after the statements made before.

[Adam Powell]

Compose is not a sandbox that prevents you from escaping it. It properly handles config changes and gives you the tools to do the same in your own code

[Stylianos Gakis]

Do you think it'd be possible to provide a little sample of how one would properly handle specifically locale changes in compose, at a place where you're using this locale?
That'd clear a lot of misunderstandings I believe, and provide a nice reference for all future people who are gonna inevitably have the same questions regarding this.

[Adam Powell]

Use LocalConfiguration.current.locale instead of Locale.getDefault()

[Alex Vanyo]

(ConfigurationCompat.getLocales(LocalConfiguration.current)[0] is the compat one that won’t complain about being deprecated)

[Adam Powell]

Or just suppress that particular deprecation globally because it's silly 🙃

[Zoltan Demant]

Hmm, do I escape this hassle if I fetch strings in my app from one source? So I dont have any stringResource calls, etc. I do eventually call context.getString, but I control that context and its locale (upading to match the Android 13 changes)? Or are there any other cases where LocalConfiguration.current.locale is used besides for fetching strings?

[Michael Paus]

Formatting numbers and parsing input comes to mind.

[Zoltan Demant]

Exactly, but I don't think there's any composable (or component) that does that automatically for you?

[Michael Paus]

Yes, but something needs to trigger a recomposition so that this can then be handled automatically by my own code. Android once decided that a change of the locale is worth a complete restart of the activity in a brute force manner. I expected Compose to do something similar, although somewhat less brutal, by automatically causing a complete recomposition of the currently visible screen.