Android get locale różnych podejść

Question

Tak, dowiedziałem się, że istnieją dwa sposoby, aby uzyskać ustawienia regionalne systemu Android:

Locale.getDefault() 

I

getResources().getConfiguration().locale 

zasadzie pytanie - może wyjście różnią się dla nich dwa? Czy zawsze są one takie same i mogę użyć pierwszego, ponieważ nie wymaga on obiektu Context?

Answer 1

Cytat z this page:

Bądź ostrożny z domyślnej lokalizacji

pamiętać, że istnieje wiele metod, wygoda, które automatycznie korzystać z domyślnego ustawienia regionalne, ale przy użyciu mogą one prowadzić do subtelnych błędów.

Domyślne ustawienia regionalne są odpowiednie dla zadań związanych z prezentowaniem danych użytkownikowi. W takim przypadku chcesz użyć formatu daty/czasu użytkownika, formatów liczb, reguł konwersji na małe litery i tak dalej. W takim przypadku można bezpiecznie korzystać z wygodnych metod.

Domyślne ustawienia regionalne nie są odpowiednie dla danych wyjściowych do odczytu maszynowego. Najlepszym wyborem jest zazwyczaj Locale.US - to locale jest dostępne na wszystkich urządzeniach, a fakt, że nie ma żadnych zaskakujących specjalnych przypadków i jest często używany (szczególnie w komunikacji komputerowo-komputerowej) oznacza, że ​​jest on najczęściej także najbardziej skuteczny wybór.

Typowym błędem jest niejawne użycie domyślnych ustawień narodowych podczas wytwarzania danych wyjściowych, które mają być odczytywalne maszynowo. Ma to tendencję do pracy na testowych urządzeniach programisty (zwłaszcza dlatego, że tak wielu programistów używa en_US), ale nie działa, gdy działa na urządzeniu, którego użytkownik jest w bardziej złożonym języku.

Na przykład, jeśli formatujesz liczby całkowite, niektóre lokalizacje będą używać cyfr dziesiętnych innych niż ASCII. Jako inny przykład, jeśli formatujesz liczby zmiennoprzecinkowe, niektóre lokalizacje użyją "," jako przecinka dziesiętnego i "." do grupowania cyfr. Jest to poprawne dla odczytu czytelnego dla człowieka, ale może powodować problemy, jeśli zostanie przedstawione innemu komputerowi (parseDouble (String) nie może parsować takiej liczby, na przykład). Powinieneś także uważać na przeciążenia toLowerCase() i toUpperCase(), które nie uwzględniają ustawień regionalnych: w Turcji, na przykład znaki "i" i "I" nie zostaną zamienione na "I" i "i" ". Jest to poprawne zachowanie dla tekstu tureckiego (np. Dane wprowadzane przez użytkownika), ale nieodpowiednie dla, powiedzmy, nagłówków HTTP.

Answer 2

Ustawienia regionalne locale = getResources(). GetConfiguration(). Locale;

Może się okazać, że ta wartość zostanie zaktualizowana szybciej po zmianie ustawień, jeśli jest to konieczne dla twojej aplikacji.

który nie jest w inny sposób

Answer 3

AFAIK, można skorzystać z jednego, chyba że sama aplikacja manipuluje lokalizacji przy użyciu jednej drodze, ale nie inne (Locale.setDefault() ale nie config.locale lub odwrotnie)

Oto dlaczego:

ResourcesManager.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(); 
    ...