Conventions de nommage des fichiers de mise en page?
Quelles sont les conventions de nommage des fichiers de mise en page que les gens ont élaborées?.
Je n'ai rien trouvé en ligne, mais j'ai pensé utiliser la convention suivante.
Qu'est-ce que tout le monde pense?
- activity_*
- dialog_*
- list_item_*
C'est tout ce avec quoi j'ai travaillé jusqu'à présent.
De plus, qu'en est-il de la désignation de l'activité par rapport à sa présentation? Par exemple:
-> res
-> layout
-> activity_about_us.xml
-> src
-> activity
-> AboutUs.Java
Curieusement, essayer de google cette question apporte seulement cette page comme résultat significatif ... Depuis un semestre, j'utilise une convention de nommage similaire à la vôtre mais avec des préfixes plus courts. Par exemple: Pour l'activité qui affiche l'écran "À propos de nous":
Nom de la classe : ActAboutUs. Préfixer une classe est un peu excessif, mais il distingue clairement les classes d’activité des autres. Au départ, j’utilisais un répertoire séparé pour toutes les activités (semblable à votre approche), mais après un certain temps, j’ai réalisé que pour les plus grandes applications, il est préférable de regrouper les répertoires par fonction plutôt que par superclasse (c.-à-d. Activité). Il est plus facile pour moi de travailler dans un seul répertoire, par exemple /src/settings/ lorsque je travaille dans les paramètres. De cette façon, tous les fichiers Java dont j'ai besoin sont dans un seul répertoire, je n'ai donc pas à me promener:
/src/settings/ActSettingsGlobal.Java
/src/settings/ActSettingsNet.Java
/src/settings/Settings.Java
/src/settings/SettingsDBAdapter.Java
/src/settings/etc...
Cette approche permet également de répartir le travail entre différents développeurs, c’est-à-dire que chacun travaille dans son propre répertoire sur une fonctionnalité distincte, évitant ainsi de marcher sur les pieds les uns des autres :-).
Certaines personnes préfèrent des suffixes mais je les ai trouvées moins utiles. Les préfixes permettent de regrouper les éléments par ordre alphabétique, comme dans l'exemple ci-dessus: Le préfixe Act* est trié en premier, de sorte que toutes les activités se situent facilement en haut.
J'envisage même d'utiliser Act_ comme préfixe qui est plus lisible bien que ce soit en conflit avec les conventions de dénomination Java ...
Nom du fichier de mise en page : act_about_us.xml. Dans res/layout/, nous n'avons pas le "luxe" de sous-répertoires, ce qui est assez regrettable. Le seul moyen de regrouper des éléments consiste à utiliser le préfixe approprié, tel que act_, dlg_, etc ...
ID de chaîne : <string name="act_about_us_dlg_help1_title" ...string.xml est l'endroit où nous rencontrons le plus de problèmes avec les doublons names. Il est très facile de créer des doublons si la convention de nommage telle que activity_element_item n'est pas utilisée. Cela ajoute beaucoup de dactylographie, mais vous évite par la suite beaucoup de confusion. Pour les chaînes globales (à l'échelle de l'application), nous utilisons le préfixe "global_", par exemple global_btn_ok, global_msg_no_inet_conn. Habituellement, une personne est responsable de toutes les chaînes global_. Si quelqu'un a besoin d'une nouvelle chaîne ou d'un changement, il doit se synchroniser avec lui afin d'éviter de créer des dégâts.
(Je réalise maintenant que activity__element__item (deux traits de soulignement) est plus clair et lisible que activity_element_item)
Dans l'ensemble, je ne parviens toujours pas à éliminer le sentiment qu'il y a quelque chose qui cloche dans mon approche, car je ne peux pas croire que Google Devs a créé un cadre aussi peu pratique pour travailler avec des fichiers, des identifiants, des noms, etc. .
je pense que suite à la convention de nommage devrait être suivre
pour l'activité
si notre nom d'activité est
DisplayListActivity
alors notre layoutname devrait être
display_list_activity.xml
pour les éléments de liste, nous pouvons inclure une catégorie dans le nom de la présentation de l'élément de liste
country_list_item.xml
et pour les boîtes de dialogue, leur action peut être incluse
delete_country_dialog.xml
Lors de la recherche d'un groupe de mises en page, c'est ce que j'ai tendance à faire, je trouve qu'il est efficace de toujours ajouter le nom de la classe et de faire un suivi avec toutes les sous-mises en page. Par exemple:
Nom de la classe: AboutActivity.Java
Nom de la mise en page: about_activity.xml
Nom de la sous-structure: about_activity_menu.xml
Nom de la sous-mise en page: about_activity_menu_item.xml
Votre activité sera toujours au sommet de chaque groupe et la recherche de non-activités devient moins une corvée. Quelqu'un sait pourquoi les sous-dossiers ne sont pas encore une chose? Je m'attends à l'efficacité et à la simplicité du back-end, mais j'imagine que cela ne ferait pas trop mal.
C'est une bonne lecture https://jeroenmols.com/blog/2016/03/07/resourcenaming/
En gros, vous suivez WHAT WHERE DESCRIPTION SIZE
Par exemple, fichier de disposition
- activity_main: vue du contenu de MainActivity
- fragment_articledetail: vue pour l'articleDetailFragment
des cordes
- articledetail_title: titre de l'articleDetailFragment
- feedback_explanation: explication du retour dans FeedbackFragment
drawable - all_infoicon_large: version longue de l'icône d'informations génériques - all_infoicon_24dp: version 24dp de l'icône d'informations génériques
La première partie d'un nom de fichier de présentation doit toujours correspondre au type de la classe correspondante. Par exemple, si nous avons une classe MainActivity (le type est Activity dans ce cas), le fichier de présentation correspondant doit être appelé activity_main.xml
Cela signifie que nous avons une boîte de dialogue appelée WarningDialog, le fichier de mise en page correspondant doit être appelé dialog_warning.xml, de même pour les fragments, etc.
Cela peut sembler familier, car c’est également ainsi que les fichiers activity/layout sont nommés lors de la création d’un nouveau projet dans Android Studio (MainActivity -> activity_main.xml).