Подтвердить что ты не робот

Hardcode string vs @string в Java-коде - Android

Мне просто интересно, какие преимущества/накладные расходы для использования @string, а не жесткие строки кодирования в реальном Java-коде... Например:

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

Является ли это лучшей практикой для таких вещей, как заголовки Actionbar, динамически созданный текст кнопки и т.д. Или я должен просто сделать это:

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

Я знаю, что будет немного больше накладных расходов, делая это первым способом. Просто не уверен, что такое лучшая практика.

4b9b3361

ОТВЕТЫ

Ответ 1

Если вы не знали о фактической точке системы @string, пожалуйста, прочитайте документацию localization. Это позволяет легко находить текст в приложении, а затем переводить его.

Edit Спасибо Hippo за это.

Использование нескольких строк одного и того же значения независимо от метода (Strings.xml vs programatically), похоже, не имеет связанных с этим накладных расходов. Согласно Oracle "Все литеральные строки и строковые константные выражения интернированы", что означает, что объект повторно используется, а не воссоздается, если вы снова используете его.

Ответ 2

Неправильная практика заключается в том, чтобы жестко закодировать строки в файлы/код макета. Вы должны добавить их в строковый файл ресурсов, а затем ссылаться на них из макета.

Причины:

  • Это позволяет вам обновлять каждое вхождение одного и того же слова во всех макетах одновременно, просто редактируя файл strings.xml.
  • Это также чрезвычайно полезно для поддержки нескольких языков, так как отдельный файл strings.xml может использоваться для каждого поддерживаемого языка.

Как сообщает документация:

Предположим, что языком вашего приложения по умолчанию является английский. предполагать также, что вы хотите локализовать весь текст в своем приложении, чтобы Французский, и большая часть текста в вашем приложении (все, кроме название приложения) на японский язык. В этом случае вы можете создать три альтернативных файла strings.xml, каждый из которых хранится в локали каталог ресурсов

Я думаю, что этих причин достаточно, чтобы рекомендовать для @String

Ответ 3

Таким образом у вас есть фиксированное место, чтобы изменить все ваши строки в проекте. Допустим, вы использовали ту же строку в 10 разных местах кода. Что, если вы решите изменить его? Вместо того, чтобы искать, где все это было использовано в проекте, вы просто меняете его один раз, и изменения отражаются везде в проекте.

Ответ 4

Ну, строки strings.xml должны быть проанализированы, не так ли? Тогда я предполагаю, что жестко закодированный будет лучше всего для производительности, хотя, вероятно, незаметный во время выполнения. Люди предпочитают использовать его, хотя для того, чтобы все строки были в одном месте, если планируете перевести приложение.

Ответ 5

Существует множество преимуществ установки строк в файле strings.xml; в двух словах, он позволяет использовать одну и ту же строку в нескольких местах, что хорошо, если вам как-то понадобится изменить строку позже. Он также позволяет отображать один и тот же текст на разных языках; hardcoding строка не дает вам всех этих параметров.

BTW, вам не нужно помещать каждый текст в файл strings.XML; только те, которые могут использоваться в нескольких местах приложения.

Общее правило размещения строк в файле strings.xml:

  •  
  • Будет ли использоваться в нескольких местах?  
  • Будет ли он использоваться на нескольких языках?  
  • Будет ли он динамическим или статическим?

Я уверен, что есть другие причины, но это те, которые я знаю.

Надеюсь, это поможет.