Question

The Android documentation here http://developer.android.com/guide/topics/resources/localization.html explains that you can get the current locale with this method:

context.getResources().getConfiguration().locale

It seems Java already provides this information in the form of this method:

java.util.Locale.getDefault()

So why did the Android developers introduce another way to get the locale? Would the above two lines of code ever produce different results when run side-by-side at the same time?

Answer 1

I agree it is confusing and while I am not attacking it nor am I defending it I can see it allowing you to do some things.

Let’s start from the beginning.

java.util.Locale.getDefault() is defined by the java runtime. It is the locale of the phone/device. It is what powers things like DateFormats (ISO Dateformat standard, US format standard, etc), NumberFormats (comma’s or decimals, groupings of 3 or 4, etc) and CurrenyFormats (Does it look like a $ or a CAD) when no locale is given. For these cases it’s probably best to specify the Locale to these types of objects anyways.

context.getResources().getConfiguration().locale is the locale that is registered with the current resources pack in the given Context. It can include the locale value that all the resource content will respect for the current context/resources pair. The configuration can be sort of like the current state of the device that best filtered to the current resources. You don’t necessarily need to specify any content that changes based on locale, but it’s an option.

Resources use a set of discriminators in the Configuration like orientation, screen width, locale, etc. So within your app you might allow overriding the current Resources() with another by just changing the locale app configuration to a different locale. Like for example, you were making a layout for an address. You might want certain fields to morph depending on what the country selected is. (Not saying this is correct behavior for such an app but it’s the simplest thing to think of right now). If you had to simply rely on Locale.getDefault(), it would make for some awkward resetting of system apps and state when you wanted to do something as I just described.

You would essentially be required to modify the Locale for the entire device (this isn’t necessarily safe, nor is it something any old user would enjoy). Even if we disregard the security manager issues that would be duplicated by the host vm; on most devices there is a lot of state that is cached for the country kit. So there would be considerable lag and probably a lot of instability while switching this value over (If anyone could do it that is). The other alternative would to be always specify the locale for everything. You could see how annoying that would be. So it’s inside the Context’s Configuration.

So while it’s awkward, it does provide an extra degree of freedom and protection, and convenience. Most of the time it will be Locale.getDefault() since your Application was started from a process that’s base context was initialized to Locale.getDefault(). In general I would shy away from using the Locale.getDefault() value too much. There aren’t too many times in consumer app development when it would be something that should be trusted.

Again not based on fact since I am not a OS dev, just mostly based on analyzing the pros and cons of the system. I think the locale in the configuration is completely reasonable.