¿Convenciones de nombres de archivos de diseño?

¿Cuáles son algunas de las convenciones de nomenclatura de ficheros de diseño que han surgido.

No he encontrado nada en línea, pero pensé en usar la siguiente convención.

¿Qué es lo que todo el mundo piensa?

- activity_* - dialog_* - list_item_* 

Eso es todo con lo que he trabajado hasta ahora.

Además, ¿qué pasa con el nombre de la actividad contra su diseño? Por ejemplo:

 -> res -> layout -> activity_about_us.xml -> src -> activity -> AboutUs.java 

Curiosamente, tratar de google esta pregunta sólo trae esta página como resultado significativo … Durante el último medio año estoy usando una convención de nomenclatura similar a la tuya, pero con prefijos más cortos. Por ejemplo: Para la actividad que muestra la pantalla "Acerca de nosotros":

Nombre de clase : ActAboutUs . Prefixing clase es una especie de exceso, pero claramente distingue las clases de actividad de los demás. Inicialmente utilicé directorio independiente para todas las actividades (similar a su enfoque), pero después de algún tiempo me di cuenta de que para aplicaciones más grandes puede ser mejor agrupar en directorios por función que por superclase (es decir, Actividad). Es más fácil para mí trabajar en el directorio único por ejemplo /src/settings/ cuando trabajo en Configuración. De esta manera todos los archivos java que necesito están en un solo directorio para que no tenga que vagar:

 /src/settings/ActSettingsGlobal.java /src/settings/ActSettingsNet.java /src/settings/Settings.java /src/settings/SettingsDBAdapter.java /src/settings/etc... 

Este enfoque también ayuda a dividir el trabajo entre los diferentes desarrolladores, es decir, cada uno está trabajando en su propio directorio en la característica por separado para no pisar los pies del otro :-).

Algunas personas prefieren sufijos, pero los encontré menos útiles. Los prefijos ayudan a agrupar las cosas alfabéticamente como en el ejemplo anterior: el prefijo Act* se ordena primero para que todas las actividades estén convenientemente en la parte superior.

Incluso estoy considerando de usar Act_ como un prefijo que es más legible aunque está en conflicto con las convenciones de nomenclatura de java …

Diseño de nombre de archivo : act_about_us.xml . En res/layout/ no tenemos el "lujo" de subdirs que es bastante desafortunado por lo que la única manera de agrupar cosas es usar prefijo apropiado como act_ , dlg_ , etc …

ID de cadena : <string name="act_about_us_dlg_help1_title" ... string.xml es el lugar donde tenemos más problemas con el name duplicado s. Es muy fácil crear duplicados si la convención de nomenclatura como activity_element_item no se utiliza. Añade un montón de mecanografía adicional, pero le ahorra mucha confusión más adelante. Para cadenas globales (de uso general) usamos el prefijo "global_" , por ejemplo global_btn_ok , global_msg_no_inet_conn . Por lo general, hacemos que una persona sea responsable de todas global_ cadenas global_ así que si alguien necesita una nueva cadena o un cambio, necesita sincronizarse con él para evitar crear un lío.

(Ahora me doy cuenta de que activity__element__item (dos subrayados) es más claro y legible que activity_element_item )

Con todo, todavía no puedo deshacerme de la sensación de que hay algo mal con mi enfoque porque no puedo creer que los desarrolladores de Google crearon un marco tan incómodo cuando se trata de trabajar con archivos, identificadores, nombres, etc. .

Creo que seguir la convención de nomenclatura debe ser seguir

Para la actividad

Si el nombre de nuestra actividad es

 DisplayListActivity 

Entonces nuestro nombre de diseño debe ser

 display_list_activity.xml 

Para los artículos de la lista podemos incluir la categoría en el nombre de la disposición del elemento de la lista

 country_list_item.xml 

Y para los cuadros de diálogo su acción puede ser incluida

 delete_country_dialog.xml 

Cuando busco un grupo de diseños, que es la forma en que tienden a trabajar en ellos, me parece que es eficaz siempre prepend el nombre de la clase y el seguimiento con cualquier sub-layouts. Por ejemplo:

Nombre de la clase: AboutActivity.java
Nombre del diseño: about_activity.xml
Sub-disposición Nombre: about_activity_menu.xml
Sub Sub-layout Nombre: about_activity_menu_item.xml

Su actividad siempre estará en la parte superior de cada grupo y la caza de no actividades se vuelve menos de una tarea. Alguien sabe por qué sub-carpetas no son una cosa todavía? Espero eficiencia y simplicidad en el back-end, pero me imagino que no dolería demasiado.

La primera parte de un nombre de archivo de diseño siempre debe ser el tipo de la clase correspondiente. Por ejemplo, si tenemos una clase MainActivity (el tipo es Activity en este caso), el archivo de diseño correspondiente debe llamarse activity_main.xml

Eso significa que vamos a decir que tenemos un diálogo llamado WarningDialog , el archivo de diseño correspondiente debe llamarse dialog_warning.xml , lo mismo ocurre con los fragmentos, etc.

Esto puede parecer familiar porque también es así como se nombran los archivos de activity/layout al crear un nuevo proyecto en Android Studio ( MainActivity -> activity_main.xml ).

  • Espacio flexible en Android
  • ¿Qué son WindowInsets?
  • Lamentablemente, la aplicación ha dejado de funcionar.
  • Este diseño de RelativeLayout o su padre LinearLayout es inútil
  • Carpetas de diseño de Android: diseño, layout-port, layout-land
  • Disposiciones condicionales de Android para teléfonos: tabletas
  • Cómo colocar los botones en la imagen de android?
  • Cajón de navegación cambio de color
  • Comportamiento extraño al usar WebView y RelativeLayout en pantalla completa
  • Galaxia s4 y tal vez todos los teléfonos HD? Fuera de error de memoria de inflado de diseño
  • Error: No se encontró ningún identificador de recurso para el atributo 'groupindicator' en el paquete 'android'
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.