22

@string実際のJavaコード内で文字列をハードコーディングするのではなく、使用することの利点/オーバーヘッドは何かと思っています...例：

// To get the string resource:
getActivity.setTitle(getString(R.string.my_string));

これは、アクションバーのタイトル、動的に作成されたボタンテキストなどのベストプラクティスですか...または、これを行う必要があります:

// Hardcoded string
getActivity.setTitle("My String");

最初の方法で行うと、オーバーヘッドが少し増えることはわかっています..ベストプラクティスが何であるかはわかりません。

4

5 に答える 5

28

システムを持っていることの実際のポイントについて知らなかった場合は、ローカリゼーションのドキュメント@stringを読んでください。アプリ内のテキストを簡単に見つけて、後で翻訳することができます。

編集 これを片付けてくれたカバに感謝します。

メソッド（Strings.xmlとプログラムによる）に関係なく、同じ値の複数の文字列を使用しても、関連するオーバーヘッドはないようです。Oracle によると、「すべてのリテラル文字列と文字列値の定数式はインターンされます」。これは、オブジェクトを再度使用すると、オブジェクトが再作成されるのではなく、再利用されることを意味します。

于 2012-11-24T04:33:24.220 に答える
9

文字列をレイアウトファイル/コードにハードコーディングすることはお勧めできません。それらを文字列リソースファイルに追加してから、レイアウトから参照する必要があります。

理由：

  • これにより、strings.xmlファイルを編集するだけで、すべてのレイアウトで同じ単語が出現するたびに同時に更新できます。
  • また、サポートされている言語ごとに個別のstrings.xmlファイルを使用できるため、複数の言語をサポートする場合にも非常に役立ちます。

ドキュメントにあるように：

アプリケーションのデフォルト言語が英語であるとします。また、アプリケーション内のすべてのテキストをフランス語にローカライズし、アプリケーション内のほとんどのテキスト（アプリケーションのタイトルを除くすべて）を日本語にローカライズするとします。この場合、それぞれがロケール固有のリソースディレクトリに保存されている3つの代替strings.xmlファイルを作成できます。

これらの理由は、@Stringに行くことをお勧めするのに十分だと思います

于 2012-11-24T04:57:06.510 に答える
3

そうすれば、プロジェクト内のすべての文字列を変更する場所が固定されます。コード内の 10 か所の異なる場所で同じ文字列を使用したとします。変更することにした場合はどうなりますか？プロジェクト内のどこで使用されているかを検索する代わりに、一度変更するだけで、変更がプロジェクトのすべての場所に反映されます。

于 2012-11-24T04:33:23.630 に答える
1

それなら、strings.xml を解析する必要がありますね。次に、実行時にはおそらく目立たないものの、ハードコーディングがパフォーマンスに最適であると思います。アプリを翻訳する計画がある場合に備えて、すべての文字列を 1 つの場所に配置するために、人々はそれを使用することを選択します.

于 2012-11-24T04:43:21.197 に答える
0

strings.xml ファイルで文字列を設定すると、多くの利点があります。簡単に言えば、複数の場所で同じ文字列を使用できるようにするため、後で何らかの方法で文字列を変更する必要がある場合に便利です。また、同じテキストを異なる言語で表示することもできます。文字列をハードコーディングしても、これらすべてのオプションが得られるわけではありません。
ところで、strings.XML ファイルにすべてのテキストを入れる必要はありません。アプリケーションの複数の場所で使用される可能性があるもののみ。
strings.xml ファイルに文字列を配置するための一般的なルールは次のとおりです。

  • 複数の場所で使用されますか？
  • 複数の言語で使用されますか?
  • それは動的か静的か？

他にも理由があると思いますが、私が知っているのはこれらの理由です。

うまくいけば、これは役に立ちます。

于 2012-11-24T04:46:36.953 に答える