Android gets system locales of different approaches

Question

So, I found out that there are two approaches to get the system language in Android:

Locale.getDefault() 

and

 getResources().getConfiguration().locale 

The main question is - can extradition be different for the two? Or are they always the same and I can use the first one since it does not require a Context object?

Answer 1

Quote from this page:

Be careful with the default locale

Please note that there are many convenient methods that automatically use the default locale, but using them can lead to subtle errors.

The default locale is suitable for tasks related to the presentation of data to the user. In this case, you want to use custom date / time formats, number formats, lowercase conversion rules, etc. In this case, it is safe to use convenient methods.

The default locale is not suitable for machine-readable output. The best choice there, as a rule, is Locale.US - this locale is guaranteed to be available on all devices, and the fact that it does not have unexpected special cases and is often used (especially for computer-computer communication) means that it is usually , the most effective choice.

A common mistake is the implicit use of a standard language for a machine read release. This usually works on test devices of developers (especially because many developers use en_US), but it does not work on launch on a device whose user is in a more complex locale.

For example, if you format integers, some locales will use decimals without ASCII. As another example, if you format floating point numbers, some locales will use "," as the decimal point and ".". to group numbers. This is correct for human reading, but can cause problems if they are presented on another computer (parseDouble (String) cannot parse such a number, for example). You should also be careful with overloads of toLowerCase () and toUpperCase () that do not occupy the locale: in Turkey, for example, the characters "i" and "I" will not be converted to "I" and "i". This is the correct behavior for Turkish text (e.g. user input), but not acceptable for, say, HTTP headers.

Answer 2

Local current = getResources (). getConfiguration (). locale;

You may find that this value updates faster after changing the settings, if necessary for your application.

What is not in your other method

Answer 3

AFAIK, you can use either, unless your application compresses the language using one path, but not another ( Locale.setDefault() , but not config.locale or vice versa)

That's why:

ResourceManager.applyConfigurationToResourcesLocked () # 275 :

 public final boolean applyConfigurationToResourcesLocked(Configuration config, CompatibilityInfo compat) ... // set it for java, this also affects newly created Resources if (config.locale != null) { Locale.setDefault(config.locale); } Resources.updateSystemConfiguration(config, defaultDisplayMetrics, compat); ApplicationPackageManager.configurationChanged(); ...