Warum hat Android seinen eigenen Weg, um das aktuelle Gebietsschema zu erhalten?

Question

Die Android-Dokumentation hier http://developer.android.com/guide/topics/resources/localization.html erklärt, dass Sie das aktuelle Gebietsschema mit dieser Methode erhalten kann:

context.getResources().getConfiguration().locale 

Es scheint Java bereits diese Informationen in Form dieses Verfahrens sieht vor:

java.util.Locale.getDefault() 

Warum tat die Android-Entwickler führen eine andere Möglichkeit ein, das Gebietsschema zu bekommen? Würden die oben genannten zwei Codezeilen jemals zu unterschiedlichen Ergebnissen führen, wenn sie gleichzeitig nebeneinander ausgeführt werden?

Answer 1

Ich stimme zu, dass es verwirrend ist und während ich es nicht angreife und ich es nicht verteidige, kann ich es sehen und dir erlauben, einige Dinge zu tun.

Beginnen wir von Anfang an.

java.util.Locale.getDefault() wird durch die Java-Laufzeit definiert. Es ist das Gebietsschema des Telefons/Geräts. Es ist, was Dinge wie DateFormats (ISO-Dateformat-Standard, US-Format-Standard, etc), NumberFormats (Komma oder Dezimalzahlen, Gruppierungen von 3 oder 4, etc) und CurrenyFormats (Sieht es wie ein $ oder ein CAD) wenn kein Gebietsschema ist gegeben. In diesen Fällen empfiehlt es sich, das Gebietsschema für diese Objekttypen zu definieren.

context.getResources().getConfiguration().locale ist das Gebietsschema, das mit dem aktuellen Ressourcenpaket im angegebenen Kontext registriert ist. Es kann den Gebietsschemawert enthalten, den der gesamte Ressourceninhalt für das aktuelle Kontext/Ressourcen-Paar berücksichtigt. Die Konfiguration kann ähnlich wie der aktuelle Status des Geräts sein, der am besten zu den aktuellen Ressourcen gefiltert wird. Sie müssen nicht unbedingt einen Inhalt angeben, der sich je nach Gebietsschema ändert, aber es ist eine Option.

Ressourcen verwenden eine Reihe von Diskriminatoren in der Konfiguration wie Ausrichtung, Bildschirmbreite, Gebietsschema usw. In Ihrer App können Sie daher das Überschreiben der aktuellen Resources() durch ein anderes zulassen, indem Sie einfach die Gebietsschema-App-Konfiguration in ein anderes Gebietsschema ändern. Wie zum Beispiel, Sie haben ein Layout für eine Adresse erstellt. Je nachdem, welches Land ausgewählt wurde, möchten Sie möglicherweise bestimmte Felder morphen. (Nicht zu sagen, das ist das richtige Verhalten für eine solche App, aber es ist die einfachste Sache, an die man gerade denken kann). Wenn Sie sich einfach auf Locale.getDefault() verlassen müssten, würde dies zu einem umständlichen Zurücksetzen von System-Apps und -Zuständen führen, wenn Sie etwas tun wollten, wie ich es gerade beschrieben habe.

Sie müssten im Wesentlichen das Gebietsschema für das gesamte Gerät ändern (dies ist nicht unbedingt sicher, und es ist auch nichts, was ein alter Benutzer genießen würde). Auch wenn wir die Sicherheitsmanager-Probleme ignorieren, die von der Host-VM vervielfältigt werden würden; Auf den meisten Geräten gibt es viele Länder, die für das Länderpaket zwischengespeichert werden. Es würde also eine beträchtliche Verzögerung und wahrscheinlich eine große Instabilität geben, wenn dieser Wert umgestellt wird (falls irgendjemand das tun könnte). Die andere Alternative wäre, immer das Gebietsschema für alles anzugeben. Du könntest sehen, wie nervig das wäre. Es befindet sich also in der Konfiguration des Kontextes.

Also, während es umständlich ist, bietet es einen zusätzlichen Grad an Freiheit und Schutz und Bequemlichkeit. Die meiste Zeit wird es Locale.getDefault() sein, da Ihre Anwendung von einem Prozess gestartet wurde, dessen Basiskontext auf Locale.getDefault() initialisiert wurde. Im Allgemeinen würde ich den Locale.getDefault() Wert zu sehr scheuen. Es gibt nicht viele Male in der Consumer-App-Entwicklung, wenn es etwas sein sollte, dem vertraut werden sollte.

Auch dies basiert nicht auf Tatsache, da ich kein Betriebssystem dev bin, nur meist auf der Analyse der Vor- und Nachteile des Systems basiert. Ich denke, das Gebietsschema in der Konfiguration ist völlig in Ordnung.