¿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.
- ¿Cómo podemos diseñar interfaces de usuario en Eclipse?
- Android: diseño alternativo xml para el modo horizontal
- LinearLayout vs RelativeLayout
- ¿Cómo hacer que el diseño con View llene el espacio restante?
- Barras del sistema translúcido y margen de contenido en KitKat
¿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
- ¿Es posible personalizar el diseño de la cabecera de preferencia?
- ¿Cómo mostrar el divisor entre los elementos giratorios?
- ¿Por qué añadir <merge> cambia el diseño de Android?
- Insertar contacto a SIM desde Android
- Lectura de archivos desde almacenamiento externo de Android SDK Emulator
- No se pudo expandir RemoteViews para: StatusBarNotification
- El visualizador de jerarquía no calcula Medir, Diseño y Dibujo y muestra no disponible
- Android: ¿Obtener la altura del elemento ListView?
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
).
- Cambiar la ruta de desarrollo de xcrun para Android Studio
- ¿Cómo puedo verificar las transacciones de facturación de Android en la aplicación en MI servidor?