Existe-t-il des conventions sur la façon de nommer les ressources?

Existe-t-il des conventions pour nommer les ressources dans Android? Par exemple, des boutons, des textViews, des menus, etc.

Je ne sais pas s'il existe des recommandations officielles.

Pour les identifiants dans mes mises en page avec des widgets et des conteneurs, j'utilise la convention:

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

Je fais la même stratégie pour tous les dimens, chaînes, nombres et couleurs que j'utilise dans ces mises en page. Cependant, j'essaye de généraliser. par exemple, si tous les boutons ont un textColor commun, je ne préfixerai pas le nom avec la mise en page. Le nom de la ressource serait «button_textColor». Si tous les textColors utilisent la même ressource, elle s'appellera «textColor». Pour les styles, c'est généralement le cas également.

Pour les ressources de menu que j'utilise:

menu_<activity>_<name>

Les animations sont uniquement différentes car vous ne pouvez pas utiliser de lettres majuscules. Il en va de même pour les ressources xml dessinables, je crois.

Le SDK Android sera un bon point de départ.

Par exemple, j'essaie de définir les identifiants dans l'activité.

Si j'avais un, ListViewce serait simplement @android:id/listdans toutes les activités.
Si, cependant, j'avais deux listes, j'utiliserais la plus spécifique @id/list_appleet@id/list_orange

Ainsi, les génériques (ids, ...) sont réutilisés pendant R.java fileque les uniques (parfois réutilisés) sont préfixés par des génériques séparés par un trait de soulignement .

Le trait de soulignement est une chose, j'ai observé, par exemple:

La largeur de la mise en page est layout_widthen xml et layoutWidthen code , j'essaie donc de m'en tenir àlist_apple

Ainsi , un bouton de connexion sera login, mais si nous avons deux connexions alors login_fooet login_bar.

Tiré de la documentation d' Android . Il y a plus là-bas sur le sujet.

Pour répondre à votre question: oui, il y en a.

Vous pouvez en trouver plusieurs via la recherche Google par exemple. Et il n'y a pas de meilleure convention de dénomination. Cela dépend toujours de vos besoins et des attributs de votre projet (surtout la portée).

Récemment, j'ai lu un très bon article de blog sur la dénomination des ressources dans Android XML de Jeroen Mols. L'auteur mentionne le principe de base que toutes les ressources doivent suivre et ensuite comment cette convention est appliquée à chaque type de ressource. Les deux décrits sur la feuille de triche de dénomination des ressources Android :

Il décrit ensuite chaque élément et chaque type de ressource en détail.

Je dirais que vous pouvez utiliser cette convention pour les petits et moyens projets (usage personnel, demandes de contrat de quelques mois). Cependant, je ne le recommanderais pas pour des projets de longue durée avec plus de 50 activités ou plus de 1000 chaînes.

Les conventions relatives à la valeur des ressources dans des projets d'une telle envergure nécessitent une recherche plus approfondie sur la manière dont elles seront utilisées. Prenons les chaînes par exemple. Peut être affecté par la taille de votre équipe, le centre de traduction que vous utilisez (le cas échéant), le VCS que vous utilisez (pour éviter les conflits de fusion par exemple), etc. Vous pourriez même penser à diviser les chaînes en plusieurs fichiers.

Je suppose que vous cherchez quelque chose pour commencer. Je recommanderais donc le billet de blog que j'ai mentionné. C'est bon pour les débutants et vous pouvez certainement l'utiliser comme source d'inspiration pour créer vos propres conventions de dénomination.

Gardez également à l'esprit qu'à mesure qu'un projet se développe, de nombreux besoins et exigences peuvent changer avec le temps. Il est donc tout à fait normal que les conventions de dénomination qui convenaient au début ne le soient pas après 2 ans. Et tout va bien. Vous ne devriez pas essayer de prédire l'avenir. Choisissez simplement une convention et suivez-la. Vous saurez s'il vous convient et convient à votre projet. Si ce n'est pas le cas, demandez-vous pourquoi il ne convient pas et commencez à utiliser autre chose.

Il existe quelques conventions utilisées dans les ressources:

• Pour les ressources qui existent en tant que fichiers séparés, elles doivent être lower_case_underscore_separated. L'outil appt s'assure que vos fichiers ne sont que des minuscules, car l'utilisation de la casse mixte peut causer des problèmes sur les systèmes de fichiers insensibles à la casse.
• Pour les ressources déclarées uniquement dans les valeurs / ... (attributs, chaînes, etc.), la convention est généralement mixedCase.
• Il existe une convention parfois utilisée pour étiqueter les noms avec une «classification» pour avoir des espaces de noms simples. C'est par exemple là que vous voyez des éléments tels que layout_width et layout_alignLeft. Dans un fichier de mise en page, les attributs de la vue et de la gestion de la mise en page parente sont mélangés, même s'ils sont des propriétaires différents. La convention "layout_ *" garantit qu'il n'y a pas de conflit entre ces noms et il est facile de comprendre quelle entité le nom affecte.

Cette convention "layout_blah" a également été utilisée dans quelques autres endroits. Par exemple, il y a des attributs "state_blah" qui sont les états dessinables qu'une vue peut avoir.

Aussi à cause de ces deux conventions (underscore_separated pour les fichiers, mixedCase pour les ressources déclarées), vous trouverez un certain nombre d'incohérences. Par exemple, les couleurs peuvent être déclarées avec des fichiers ou sous forme de valeurs explicites. En général, nous aimerions nous en tenir à underscore_separated pour tout cela, mais cela ne se produit pas toujours.

En fin de compte, nous ne nous soucions pas beaucoup des conventions de dénomination des ressources. Le plus gros que nous gardons cohérent est "mixedCase" pour les attributs, et l'utilisation de "layout_blah" pour identifier les attributs des paramètres de mise en page.

Parcourir également les ressources publiques ici devrait donner une bonne idée des conventions:

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

Vous verrez que les attributs sont tous assez cohérents (étant donné que vous comprenez la convention layout_), les drawables sont tous des underscore_separated, etc.

C'est un problème commun à n'importe quel langage ou framework, mais tant que vous évitez les mots réservés, vous devriez être d'accord en supposant que vous pouvez vous souvenir de ce que vous avez appelé les choses.

J'ai noté qu'Android place une restriction sur les noms de fichiers de ressources xml mais les traits de soulignement semblent être corrects. ADT déclare en fait

Les noms de ressources basés sur des fichiers ne doivent contenir que des minuscules az, 0-9 ou _.

Quelque chose qui m'a fait trébucher au début était un manque d'espaces de noms avec des identifiants, mais cela peut généralement être ignoré si vous avez deux identifiants, le même Android réutilisera simplement l'identifiant défini.

Pour les identifiants, j'utilise un qualificatif à 3 lettres suivi de ce à quoi il fait référence en notation camel, par exemple lblFoo pour une étiquette de texte statique (ou textview), txtFoo pour une zone de texte modifiable (edittext sous Android). Cela peut sembler étrange au début, mais je l'utilise depuis VB6 et ces contrôles s'appelaient étiquette et zone de texte.

En voici d'autres que j'utilise couramment:

• btnFoo - bouton
• pwdFoo - mot de passe
• lstFoo - liste
• clrFoo - couleur
• tblFoo - table
• colFoo - colonne
• rowFoo - ligne
• imgFoo - image
• dimFoo - dimension
• padFoo - rembourrage
• mrgFoo - marge

J'utilise la même chose dans le code dans le fichier java aussi, donc je n'ai pas à y penser, la portée du package le permettra avec plaisir:

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

Vous pourriez si vous préférez ajouter un peu d'espacement en utilisant un trait de soulignement, c'est-à-dire btn_foo ... Je le ferais probablement si je pouvais casser les vieilles habitudes.

Il y a ceux qui peuvent soutenir que l'abréviation de ceux-ci n'est peut-être pas idéale et les puristes soutiendraient que le nom complet devrait être utilisé, mais lorsque vous nommez des dizaines de contrôles et changez entre différents systèmes et cadres, les noms complets perdent leur signification, je les utilisent depuis plus d'une décennie en VB, C ++, ASP.NET, WinForms en C # et VB.NET, Android et Python. Je n'ai jamais besoin de me rappeler si Android l'appelle une zone de texte ou un edittext. Tout ce que j'ai besoin de savoir, c'est que lblFoo est l'étiquette statique et txtFoo est ce que l'utilisateur saisit.

Une note finale est que quelle que soit la convention, vous décidez des choses importantes: nommer les contrôles correctement et de manière cohérente, afin de ne pas vous débattre avec des identifiants par défaut vagues, par exemple TextView5 ou un mélange de conventions différentes.

Lien utile pour les concepteurs et les développeurs - ici

Dimensions et tailles, conventions de dénomination, styles et thèmes, neuf patchs, etc.

Je ne pense pas qu'il y ait de convention standard promue par Google. J'ai vu toutes sortes de façons différentes de nommer des choses, même dans différentes applications Google officielles.

Ce qui vous aide le plus lorsque vous essayez de donner un sens à 100 fichiers de mise en page (ou dessinables, menus, etc.) dans une hiérarchie de répertoires.

Une réponse courte: si vous souhaitez apprendre des développeurs Android, un bon exemple est la bibliothèque de support v7 ( https://dl-ssl.google.com/android/repository/support_r21.zip )

Sinon, voici ce que j'ai pris en compte pour nommer les ressources:
1. trouver facilement des ressources lors de l'écriture de code
2. comprendre facilement les ressources lors de la lecture du code
3. rendre les noms utiles pour les traducteurs ( R.string.*ressources uniquement)
4. réutiliser les mises en page avec <include/>( R.id.*conflits de ressources)
5. gérer avec des projets de bibliothèque

Logiquement, l'organisation des ressources ne doit pas être différente du regroupement des classes Java dans des packages (ou de la mise des fichiers dans des dossiers). Cependant, comme les ressources Android n'ont pas d'espaces de noms, des préfixes doivent être ajoutés au nom de la ressource pour obtenir la même chose (par exemple, com.example.myapp.photodevient com_example_myapp_photo).

Je suggère de diviser l'application en composants séparés (activités, fragments, dialogues, etc.) avec des noms uniques courts pouvant être utilisés comme préfixes de ressources. De cette façon, nous regroupons les ressources avec des fonctionnalités associées, ce qui les rend faciles à trouver (point 1) et nous évitons en même temps les conflits de noms avec les deux <include/>projets de bibliothèque (points 4 et 5). Notez que les ressources communes à plusieurs composants peuvent toujours avoir un préfixe (tel que R.string.myapp_ok_button).

Après le préfixe, le nom doit nous dire à quoi sert la ressource (action à effectuer, contenu à afficher, etc.). Choisir un bon nom est important pour la compréhension (points 2 et 3).

Parfois, "nom_composant" nous donnera suffisamment d'informations, ce qui est particulièrement vrai si le type est déjà donné par la classe R (dans R.string.myapp_name_stringla 2ème "chaîne" est redondante). Cependant, l'ajout explicite d'un type peut améliorer la compréhension (par exemple, il peut être utile pour les traducteurs de faire la distinction entre un toast ou une étiquette). Parfois, les parties «nom» et «type» peuvent être permutées pour permettre un filtrage basé sur le type ( R.string.photo_menu_*nous ne donnerons que les éléments liés au menu pour le composant photo).

Disons que nous écrivons une activité pour prendre des photos, classe com.example.myapp.photo .PhotoActivity. Nos ressources pourraient ressembler à ceci (regroupées par le composant "photo"):

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 vous fouillez dans la documentation d'Android, il existe diverses mentions de «bonnes pratiques», mais il n'y a certainement pas de règles concrètes. Par exemple, dans Icon Design Guidelines , Google suggère de nommer les icônes avec un préfixe "ic_".

Un bon point de départ peut être la fourniture de ressources .

Cherchez également dans la source / les exemples du SDK ainsi que sur le blog des développeurs Android si vous voulez voir comment les développeurs Google font les choses.

J'ai trouvé la prochaine convention de dénomination pratique pour les chaînes:

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

Par exemple, clear_playlist_text, delete_song_message, update_playlist_positivebutton_text. Et «action» ici est facultative.

vous pouvez lire la documentation google pour le style de code pour avoir une idée ici

J'ai généralement suivi les conventions de nommage Java pour les identifiants de ressources (pas pour les fichiers pour les fichiers) sauf que j'ai ajouté "x" devant les identifiants par exemple:

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

En java, nous pouvons l'utiliser simplement (nous pouvons aussi nous en souvenir en simple)

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

Ici mTvName (il s'agit en général des conventions de dénomination suggérées par Android) et xTvName qui a été nommé dans le fichier de mise en page dans le cadre de l'id d'Android TextView (x destiné au XML), j'ai suivi ce type de conventions de dénomination pour les objets de vue tels que Buttons et EditText, etc.

dans XML IDS: xViewTypeSpecificName

en Java: mViewTypeSpeficName

Les conventions ci-dessus me facilitent la vie lorsque je crée des mises en page complexes. Essayez simplement de rendre vos noms autant que possible courts et il est préférable qu'ils soient compréhensibles et significatifs pour les autres co-développeurs (mais ce n'est peut-être pas possible à chaque fois), j'espère que mon expérience aidera les autres, les suggestions sont les bienvenues.

Dans nos projets Android, il existe de nombreux composants tels que des boutons, des étiquettes, des zones de texte. Un nom simple comme par exemple "nom" est très déroutant pour identifier "nom" est une étiquette ou une zone de texte. Cela se produit principalement lorsque vous maintenez des projets développés par d'autres développeurs.

Donc, pour éviter ce genre de confusion, j'ai utilisé les noms suivants pour les boutons TextBoxes ou Labels

Exemple :

 btnName
 labName
 txtName
 listName

Cela peut être utile pour vous.

Il y a quelques restrictions:

1. Le nom de la ressource doit contenir az, 0-9, _
2. Le nom de la ressource doit commencer par az, _

À propos, il est plus conseillé de suivre les directives ou d'apprendre du code standard.