studio - string array android

Hardcode String vs @string en código Java-Android

Question

Me pregunto cuáles son los beneficios / gastos generales de usar @string lugar de cadenas de codificación rígidas dentro del código Java real ... Por ejemplo:

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

¿Es esta la mejor práctica para cosas como títulos de Actionbar, texto de botón creado dinámicamente, etc.? O debería hacer esto:

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

Sé que habrá un poco más de sobrecarga al hacerlo de la primera manera ... Simplemente no estoy seguro de cuál es la mejor práctica.

Answer 1

Bueno, strings.xml tendría que ser analizado, ¿no? Entonces supongo que el código duro sería el mejor para el rendimiento, aunque probablemente no se note en el tiempo de ejecución. Sin embargo, la gente elige usarlo para tener todas las cadenas en un solo lugar en caso de que haya planes para traducir la aplicación.

Answer 2

De esa manera, tendrá un lugar fijo para alterar todas sus cadenas dentro del proyecto. Digamos que usaste la misma cadena en 10 ubicaciones diferentes en el código. ¿Y si decides alterarlo? En lugar de buscar dónde se ha utilizado todo en el proyecto, solo cámbielo una vez y los cambios se reflejarán en todas partes del proyecto.

Answer 3

En caso de que no estuviera al tanto del punto real de tener el sistema @string , lea la documentación de localization . Le permite localizar fácilmente el texto en su aplicación y luego traducirlo.

Editar Gracias a Hippo por aclarar esto.

El uso de varias cadenas del mismo valor sin importar el método (Strings.xml vs programatically) no parece tener una sobrecarga asociada. Según Oracle "Todas las cadenas literales y las expresiones constantes con valores de cadena están internadas", lo que significa que el objeto se reutiliza en lugar de volver a crearse si se usa de nuevo.

Answer 4

Hay muchas ventajas al establecer las cadenas en un archivo strings.xml; en pocas palabras, le permite usar la misma cadena en varias ubicaciones, lo que es bueno si de alguna manera necesita modificar la cadena más adelante. También le permite mostrar el mismo texto en diferentes idiomas; codificar la cadena no te da todas esas opciones.
Por cierto, no es necesario poner todos los textos en el archivo strings.XML; solo los que se pueden utilizar en varios lugares de la aplicación.
La regla general para colocar cadenas en el archivo strings.xml son las siguientes:

• ¿Se utilizará en múltiples ubicaciones?
• ¿Se utilizará en varios idiomas?
• ¿Será dinámico o estático?

Estoy seguro de que hay otras razones, pero estas son las que conozco.

Con suerte, esto ayuda.

Answer 5

No es una buena práctica codificar las cadenas en sus archivos / código de diseño. Debe agregarlos a un archivo de recursos de cadena y luego hacer referencia a ellos desde su diseño.

Razones:

• Esto le permite actualizar cada aparición de la misma palabra en todos los diseños al mismo tiempo simplemente editando su archivo strings.xml.
• También es extremadamente útil para admitir múltiples idiomas, ya que se puede usar un archivo strings.xml separado para cada idioma admitido.

Como dice la localization :

Supongamos que el idioma predeterminado de su aplicación es el inglés. Supongamos también que desea localizar todo el texto de su aplicación al francés y la mayor parte del texto de la aplicación (todo excepto el título de la aplicación) al japonés. En este caso, podría crear tres archivos strings.xml alternativos, cada uno almacenado en un directorio de recursos específico del entorno local

Creo que estas razones son suficientes para recomendar ir a @String