¿Existen convenciones sobre cómo nombrar los recursos?

¿Existen convenciones sobre cómo nombrar recursos en Android? Por ejemplo, botones, textViews, menús, etc.

No sé si hay recomendaciones oficiales.

Para los identificadores en mis diseños con widgets y contenedores, uso la convención:

<layout>_<widget/container>_<name>

Hago la misma estrategia para cualquier dimensión, cadena, número y color que use en esos diseños. Sin embargo, intento generalizar. por ejemplo, si todos los botones tienen un color de texto común, no prefijaré el nombre con el diseño. El nombre del recurso sería 'button_textColor'. Si todos los textColors están usando el mismo recurso, se llamará 'textColor'. Para Styles, este también suele ser el caso.

Para los recursos del menú que uso:

menu_<activity>_<name>

Las animaciones solo son diferentes, ya que no puede usar letras mayúsculas. Lo mismo ocurre con los recursos xml dibujables, creo.

Android SDK será un buen lugar para comenzar.

Por ejemplo, intento establecer el alcance de los ID dentro de la actividad.

Si tuviera un ListView, simplemente estaría @android:id/listen todas las actividades.
Sin embargo, si tuviera dos listas, usaría la más específica @id/list_appley@id/list_orange

Entonces, los genéricos (ids, ...) se reutilizan R.java filemientras que los únicos (a veces se reutilizan) se prefijan con los genéricos separados por un guión bajo .

El guión bajo es una cosa, observé, por ejemplo:

El ancho del diseño está layout_widthen xml y layoutWidthen código , así que trato de ceñirme a él comolist_apple

Entonces, un botón de inicio de sesión será login, pero si tenemos dos inicios de sesión, entonces login_fooy login_bar.

Tomado de la documentación de Android . Hay más sobre el tema.

Para responder a su pregunta: Sí, los hay.

Puede encontrar muchos de ellos a través de la búsqueda de Google, por ejemplo. Y no existe la mejor convención de nomenclatura. Siempre depende de sus necesidades y de los atributos de su proyecto (lo más importante, el alcance).

Recientemente, leí una publicación de blog bastante buena sobre recursos de nombres en XML de Android de Jeroen Mols. El autor menciona el principio básico que deben seguir todos los recursos y luego cómo se aplica esta convención a cada tipo de recurso. Ambos se describen en la hoja de referencia de nombres de recursos de Android :

Luego describe cada elemento y cada tipo de recurso en detalle.

Yo diría que podría utilizar esta convención para proyectos pequeños y medianos (uso personal, solicitudes de contratos de pocos meses). Aunque, no lo recomendaría para proyectos a largo plazo con más de 50 actividades o más de 1000 cadenas.

Las convenciones para los valores de los recursos en proyectos de tan gran escala requieren más investigación sobre cómo se utilizarán. Tome las cuerdas, por ejemplo. Podría verse afectado por el tamaño de su equipo, el centro de traducción que está utilizando (si corresponde), VCS que está usando (para evitar conflictos de fusión, por ejemplo), etc. Incluso podría pensar en dividir cadenas en varios archivos.

Supongo que está buscando algo para empezar. Así que recomendaría la publicación de blog que mencioné. Es bueno para empezar y definitivamente puede usarlo como inspiración para crear sus propias convenciones de nomenclatura.

También tenga en cuenta que a medida que un proyecto crece, muchas necesidades y requisitos pueden cambiar con el tiempo. Por lo tanto, es completamente normal que las convenciones de nomenclatura que eran adecuadas al principio no lo sean después de 2 años. Y está completamente bien. No debes intentar predecir el futuro. Simplemente elija una convención y sígala. Encontrarás si es adecuado para ti y tu proyecto. Si no es así, piense por qué no es adecuado y comience a usar otra cosa.

Hay algunas convenciones que se utilizan en los recursos:

• En el caso de los recursos que existen como archivos separados, deben estar en minúsculas_inferiores_por_separados. La herramienta appt se asegura de que sus archivos estén solo en minúsculas, porque el uso de mayúsculas y minúsculas puede causar problemas en sistemas de archivos que no distinguen entre mayúsculas y minúsculas.
• Para los recursos declarados solo en valores / ... (atributos, cadenas, etc.), la convención es generalmente MixedCase.
• Existe una convención que se usa a veces para etiquetar nombres con una "clasificación" para tener espacios de nombres simples. Aquí es, por ejemplo, donde ve cosas como layout_width y layout_alignLeft. En un archivo de diseño, los atributos tanto de la vista como de la gestión de diseño principal se mezclan, aunque sean propietarios diferentes. La convención "layout_ *" asegura que no haya conflictos entre estos nombres y es fácil entender a qué entidad afecta el nombre.

Esta convención "layout_blah" también se ha utilizado en algunos otros lugares. Por ejemplo, hay atributos "state_blah" que son los estados dibujables que puede tener una vista.

Además, debido a estas dos convenciones (subrayado_separado para archivos, mixedCase para recursos declarados), encontrará una serie de inconsistencias. Por ejemplo, los colores se pueden declarar con archivos o como valores explícitos. En general, nos gustaría quedarnos con underscore_separated para todos esos, pero no siempre sucede.

En última instancia, no nos preocupamos demasiado por las convenciones de nombres de los recursos. El más grande que mantenemos consistente es "mixedCase" para los atributos, y el uso de "layout_blah" para identificar los atributos de los parámetros de diseño.

También navegar a través de los recursos públicos aquí debería dar una buena idea de las convenciones:

http://developer.android.com/reference/android/R.html

Verá que todos los atributos son bastante consistentes (dado que comprende la convención de diseño), los elementos de diseño están separados por subrayado, etc.

Este es un problema común a cualquier lenguaje o marco, pero siempre que evite las palabras reservadas, debería estar bien asumiendo que puede recordar cómo ha llamado las cosas.

Noté que Android restringe los nombres de los archivos de recursos xml, pero los guiones bajos parecen estar bien. ADT en realidad dice

Los nombres de recursos basados ​​en archivos solo deben contener az minúscula, 0-9 o _.

Algo que me hizo tropezar al principio fue la falta de espacios de nombres con identificaciones, pero esto generalmente se puede ignorar si tiene dos identificaciones, el mismo Android simplemente reutilizará la identificación definida.

Para las identificaciones, uso un calificador de 3 letras seguido de lo que se refiere en notación camel, por ejemplo, lblFoo para una etiqueta de texto estático (o vista de texto), txtFoo para un cuadro de texto editable (edittext en Android). Esto puede parecer extraño al principio, pero lo he estado usando desde VB6 y esos controles se llamaban etiqueta y cuadro de texto.

Aquí hay algunos más que uso comúnmente:

• btnFoo - botón
• pwdFoo - contraseña
• lstFoo - lista
• clrFoo - color
• tblFoo - mesa
• colFoo - columna
• rowFoo - fila
• imgFoo - imagen
• dimFoo - dimensión
• padFoo - relleno
• mrgFoo - margen

También uso lo mismo en el código dentro del archivo java, así que no tengo que pensar en ello, el alcance del paquete permitirá esto con bastante alegría:

Button btnFoo = (Button)findViewById(R.id.btnFoo);

Si lo prefiere, podría agregar un poco de espacio usando un guión bajo, es decir, btn_foo ... Probablemente haría esto si pudiera romper los viejos hábitos.

Hay quienes pueden argumentar que abreviarlos puede no ser ideal y los puristas argumentarían que se debe usar el nombre completo, pero cuando se nombran docenas de controles y se cambia entre diferentes sistemas y marcos, los nombres completos pierden su significado. los he utilizado durante más de una década en VB, C ++, ASP.NET, WinForms en C # y VB.NET, Android y Python. Nunca necesito recordar si Android lo llama un cuadro de texto o un texto de edición. Todo lo que necesito saber es que lblFoo es la etiqueta estática y txtFoo es lo que ingresa el usuario.

Una nota final es que no importa qué convención decida, lo importante es nombrar los controles de manera adecuada y coherente, de modo que no tenga que luchar con los identificadores predeterminados vagos, por ejemplo, TextView5 o una mezcla de diferentes convenciones.

Enlace útil para diseñadores y desarrolladores - aquí

Dimensiones y tamaños, convenciones de nomenclatura, estilos y temas, nueve parches, etc.

No creo que Google promueva ninguna convención estándar. He visto todo tipo de formas diferentes en que las personas nombran cosas, incluso dentro de diferentes aplicaciones oficiales de Google.

Lo que más le ayude cuando intente dar sentido a 100 archivos de diseño (o elementos de diseño, menús, etc.) en una jerarquía de directorios.

Una respuesta breve: si desea aprender de los desarrolladores de Android, un buen ejemplo es la biblioteca de soporte v7 ( https://dl-ssl.google.com/android/repository/support_r21.zip )

De lo contrario, esto es lo que he considerado para nombrar recursos:
1. encontrar recursos fácilmente al escribir código
2. comprender recursos fácilmente al leer código
3. hacer que los nombres sean útiles para los traductores ( R.string.*solo recursos)
4. reutilizar diseños con<include/> ( R.id.*conflictos de recursos)
5. tratar con proyectos de biblioteca

Lógicamente, organizar los recursos no debería ser diferente a agrupar clases de Java en paquetes (o poner archivos en carpetas). Sin embargo, dado que los recursos de Android no tienen espacios de nombres, se deben agregar prefijos al nombre del recurso para lograr lo mismo (por ejemplo, se com.example.myapp.photoconvierte com_example_myapp_photo).

Sugiero dividir la aplicación en componentes separados (actividades, fragmentos, diálogos, etc.) con nombres únicos cortos que se pueden usar como prefijos de recursos. De esta manera estamos agrupando recursos con funcionalidades relacionadas, lo que los hace fáciles de encontrar (punto 1) y al mismo tiempo estamos evitando conflictos de nombres con ambos <include/>proyectos y bibliotecas (puntos 4 y 5). Tenga en cuenta que los recursos comunes a varios componentes aún pueden tener un prefijo (como R.string.myapp_ok_button).

Después del prefijo, el nombre debe indicarnos para qué se utiliza el recurso (acción a realizar, contenido a mostrar, etc.). Elegir un buen nombre es importante para la comprensión (puntos 2 y 3).

A veces, "nombre_componente" nos dará suficiente información, lo cual es especialmente cierto si el tipo ya está dado por la clase R (en R.string.myapp_name_stringla segunda "cadena" es redundante). Sin embargo, agregar explícitamente el tipo puede mejorar la comprensión (por ejemplo, puede ser útil para los traductores distinguir entre un brindis o una etiqueta). A veces, las partes "nombre" y "tipo" se pueden intercambiar para permitir el filtrado basado en el tipo ( R.string.photo_menu_*nos dará solo elementos relacionados con el menú para el componente de la foto).

Digamos que estamos escribiendo una actividad para tomar fotografías, clase com.example.myapp.photo .PhotoActivity. Nuestros recursos podrían verse así (agrupados por el componente "foto"):

R.layout.photo //if only a single layout is used
R.menu.photo  
R.string.photo_capture_instructions_label  
R.id.photo_capture_instructions_label  
R.id.photo_capture_button  
R.id.photo_capture_image  
R.drawable.photo_capture_placeholder  
R.dimen.photo_capture_image_height  

Si busca en la documentación de Android, hay varias menciones de "mejores prácticas", pero ciertamente no hay reglas concretas. Por ejemplo, en las Pautas de diseño de iconos , Google sugiere nombrar los iconos con un prefijo "ic_".

Un buen lugar para comenzar puede ser el suministro de recursos .

También busque en la fuente / ejemplos del SDK, así como en el Blog de desarrolladores de Android, si desea ver cómo hacen las cosas los desarrolladores de Google.

Encontré útil la siguiente convención de nomenclatura para cadenas:

[<action>]_<object>_<purpose>

Por ejemplo, clear_playlist_text, delete_song_message, update_playlist_positivebutton_text. Y "acción" aquí es opcional.

Puede leer la documentación de Google para obtener una idea del estilo del código aquí.

Generalmente seguí las convenciones de nomenclatura de Java para los identificadores de recursos (no para los archivos de los archivos) excepto que agregué "x" delante de los identificadores, por ejemplo:

<TextView android:id="@+id/xTvName" android:layout_width="wrap_content" android:layout_height="wrap_content"></TextView>

En java podemos usarlo simple (también podemos recordarlo en simple)

TextView mTvName=(TextView)findViewById(R.id.xTvName);

Aquí mTvName (es, en general, las convenciones de nomenclatura sugeridas por Android) y xTvName, que se nombró en el archivo de diseño como parte del Id. De TextView de Android (x significa para XML), seguí este tipo de convenciones de nomenclatura para ver objetos como Buttons y EditText, etc.

en XML IDS: xViewTypeSpecificName

en Java: mViewTypeSpeficName

Las convenciones anteriores me facilitan la vida cuando creo diseños complejos. Solo intente que sus nombres sean lo más cortos posible y es mejor si son comprensibles y significativos para otros co-desarrolladores (pero puede que no sea posible siempre). Espero que mi experiencia ayude a otros, las sugerencias son bienvenidas.

En nuestros proyectos de Android hay muchos componentes como botones, etiquetas, cuadros de texto. Un nombre tan simple como, por ejemplo, "nombre", es muy confuso identificar que "nombre" es etiqueta o cuadro de texto. Principalmente sucede cuando estás manteniendo proyectos desarrollados por otros desarrolladores.

Entonces, para evitar este tipo de confusión, utilicé los siguientes nombres para Buttons TextBoxes o Labels

Ejemplo:

 btnName
 labName
 txtName
 listName

Puede que esto sea útil para ti.

Existen algunas restricciones:

1. El nombre del recurso debe contener az, 0-9, _
2. El nombre del recurso debe comenzar con az, _

Por cierto, es más recomendable seguir las pautas o aprender del código estándar.