get Android diversi approcci

Question

Così, ho scoperto che ci sono due approcci per ottenere il locale del sistema in Android:

Locale.getDefault() 

E

getResources().getConfiguration().locale 

Fondamentalmente domanda è - uscita può essere diverso per queste Due? O sono sempre gli stessi e posso usare il primo, dal momento che non richiede l'oggetto Context?

Answer 1

Citato da this page:

diffidare di locale predefinito

Nota che ci sono molti metodi di convenienza che utilizzano automaticamente le impostazioni internazionali predefinite, ma utilizzando possono portare a bug sottili.

Le impostazioni locali predefinite sono appropriate per le attività che prevedono la presentazione di dati all'utente. In questo caso, si desidera utilizzare i formati data/ora dell'utente, i formati numerici, le regole per la conversione in lettere minuscole e così via. In questo caso, è sicuro usare i metodi di convenienza.

Le impostazioni locali predefinite non sono appropriate per l'output leggibile dalla macchina. La scelta migliore è solitamente Locale.US - questa localizzazione è garantita per essere disponibile su tutti i dispositivi, e il fatto che non abbia casi speciali sorprendenti e sia usata frequentemente (specialmente per le comunicazioni tra computer e computer) significa che tende ad essere il scelta più efficiente anche.

Un errore comune consiste nell'utilizzare implicitamente le impostazioni internazionali predefinite quando si produce un output che deve essere letto da una macchina. Questo tende a funzionare sui dispositivi di test dello sviluppatore (specialmente perché così tanti sviluppatori usano en_US), ma fallisce quando viene eseguito su un dispositivo il cui utente si trova in un ambiente più complesso.

Ad esempio, se si stanno formattando numeri interi alcune locali utilizzeranno cifre decimali non ASCII. Come altro esempio, se si stanno formattando numeri a virgola mobile alcune locali useranno "," come punto decimale e "." per il raggruppamento delle cifre. Questo è corretto per l'output leggibile dall'uomo, ma potrebbe causare problemi se presentato a un altro computer (parseDouble (String) non può analizzare un numero simile, ad esempio). Dovresti anche essere cauto con gli overload toLowerCase() e toUpperCase() che non prendono un Locale: in Turchia, ad esempio, i caratteri 'i' e 'I' non saranno convertiti in 'I' e 'i '. Questo è il comportamento corretto per il testo turco (come l'input dell'utente), ma inappropriato per, per esempio, le intestazioni HTTP.

Answer 2

Locale current = getResources(). GetConfiguration(). Locale;

È possibile che questo valore venga aggiornato più rapidamente dopo una modifica delle impostazioni, se necessario per l'applicazione.

che non è nella vostra un altro metodo

Answer 3

per quanto ne so, è possibile utilizzare, a meno che la vostra applicazione stessa manomette locale utilizzando un modo, ma non l'altro (Locale.setDefault() ma non config.locale o viceversa)

Ecco perché:

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