Android のドキュメントhttp://developer.android.com/guide/topics/resources/localization.htmlでは、この方法で現在のロケールを取得できることが説明されています。
context.getResources().getConfiguration().locale
Java はすでにこの情報をこのメソッドの形式で提供しているようです。
java.util.Locale.getDefault()
では、なぜ Android 開発者はロケールを取得する別の方法を導入したのでしょうか? 上記の 2 行のコードを同時に実行すると、異なる結果が得られるでしょうか?
私はそれが混乱していることに同意します。私はそれを攻撃しているわけでも擁護しているわけでもありませんが、いくつかのことができるようになっていることがわかります。
最初から始めましょう。
java.util.Locale.getDefault()Java ランタイムによって定義されます。電話/デバイスのロケールです。これは、DateFormats (ISO Dateformat 規格、US フォーマット規格など)、NumberFormats (コンマまたは 10 進数、3 または 4 のグループ化など)、および CurrenyFormats ($ または CAD のように見えますか) のようなものに力を与えます。与えられた。これらのケースでは、とにかくこれらのタイプのオブジェクトに Locale を指定するのがおそらく最善です。
context.getResources().getConfiguration().locale指定されたコンテキストで現在のリソース パックに登録されているロケールです。すべてのリソース コンテンツが現在のコンテキスト/リソースのペアを尊重するロケール値を含めることができます。構成は、現在のリソースに最も適したデバイスの現在の状態のようなものです。ロケールに基づいて変化するコンテンツを必ずしも指定する必要はありませんが、オプションです。
リソースは、向き、画面幅、ロケールなどの構成で一連の識別子を使用します。したがって、アプリ内で、ロケール アプリの構成を別のロケールに変更するだけで、現在の Resources() を別のリソースでオーバーライドできる場合があります。たとえば、住所のレイアウトを作成していたとします。選択した国に応じて、特定のフィールドを変形させたい場合があります。(これがそのようなアプリの正しい動作であるとは言いませんが、今考えられる最も簡単なことです)。単純に Locale.getDefault() に依存しなければならない場合は、今説明したように何かをしたいときに、システム アプリと状態の厄介なリセットが発生します。
基本的に、デバイス全体のロケールを変更する必要があります (これは必ずしも安全ではなく、古いユーザーが楽しめるものでもありません)。ホスト vm によって複製されるセキュリティ マネージャーの問題を無視したとしても。ほとんどのデバイスでは、カントリー キット用にキャッシュされた多くの状態があります。そのため、この値を切り替えるときにかなりの遅延とおそらく多くの不安定性が生じるでしょう (誰かがそれを行うことができれば)。もう 1 つの方法は、常にすべてのロケールを指定することです。それがどれほど厄介なことかがわかります。したがって、コンテキストの構成内にあります。
そのため、ぎこちなくはありますが、追加の自由度と保護、および利便性が提供されます。ほとんどの場合、アプリケーションはベースコンテキストのプロセスから開始されたため、Locale.getDefault() に初期化されました。一般的に、私は Locale.getDefault() の値を使いすぎることをためらいます。コンシューマー向けアプリの開発において、それが信頼されるべきものであることはあまりありません。
私は OS 開発者ではないので、事実に基づくものではありません。主にシステムの長所と短所の分析に基づいています。構成のロケールは完全に合理的だと思います。