mozilla-services
Bug 970176 - Invoke LocaleManager locale switching code prior to handling strings or Locale in background services.
I think I understand what you're doing, and I think this does what you say. But I'm not convinced this is the right way to go about it. I think the abstraction we're looking for is the Application, not all the various entry points to said Application. I'm going to assume you understand this deeply, and say r+ after fixing issues, but I'd still like you to explain why we can't bend the application to our will.
Also, this is tying ABS and Fennec tightly. Could we do this with a local broadcast that Fennec responds to (and is just ignored for android-sync.apk, or similar)? To decouple these things.
The application is involved, just not entirely responsible.
- We don't want to incur the initial prefs read at the Application creation level. (And we wouldn't be able to if we switched to per-profile prefs, most likely, because the Application doesn't get recreated unless you kill the process.)
- We aren't happy with the junk that Android seems to give us — the application configuration seems to regularly get reset to the system locale. The only place I found to ensure that an activity would get the right configuration and context (again, as I recall) was to make the activity do something during the activity lifecycle, rather than relying on the application getting things done before the activity code ran.
Instead, we read prefs after the activity has been kicked off (and thus Android is done messing with our config), and we fix up the configuration as necessary from inside Application.onConfigurationChanged.
I agree with your point, though: it would be nice if we could essentially opt-in to locale switching at the app level, and I continue to think about it.
It's worth remembering, though, that browser activities (not so much these FxA setup ones — we mostly worry about ones that can be earlier in the stack than Firefox settings) need to be able to respond to locale changes, which naturally introduces some locale-specific coupling.
The reason I didn't use a broadcast is because this work is being done during the activity setup. My expectation was that a broadcast would either be asynchronous (and thus we'd have to handle a reply) or would block the activity UI thread.
I agree that it would be ideal to use an Android-supported decoupling mechanism.
Am I misinformed about local broadcasts?