Existe-t-il des conventions sur la manière de nommer les ressources?

Existe-t-il des conventions pour nommer les ressources sous 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:

__ 

Je fais la même stratégie pour tous les dimens, chaînes, numéros et couleurs que j’utilise dans ces mises en page. Cependant, j’essaie de généraliser. Par exemple, si tous les boutons ont une couleur commune, 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 du menu, j’utilise:

 menu__ 

Les animations ne sont différentes que parce que vous ne pouvez pas utiliser de lettres majuscules. Il en va de même pour les ressources xml pouvant être dessinées, je crois.

Android SDK sera un bon sharepoint départ.

Par exemple, j’essaie de définir les ID dans l’activité.

Si j’avais un ListView ce serait simplement @android:id/list dans toutes les activités.
Si, toutefois, j’avais deux listes, j’utiliserais plus @id/list_apple et @id/list_orange plus spécifiques @id/list_orange

Donc, générique (ids, …) est réutilisé dans le R.java file alors que les R.java file uniques (parfois réutilisés) sont préfixés par des R.java file génériques séparés par un trait de soulignement .


Le soulignement est une chose, j’ai observé, par exemple:

La largeur de la mise en page est layout_width dans xml et layoutWidth dans le code , donc j’essaye de s’y tenir comme list_apple

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

Tiré de la documentation d’ Android . Il y en a plus sur le sujet.

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 minuscules, car l’utilisation de casse mixte peut entraîner des problèmes sur les systèmes de fichiers insensibles à la casse.
  • Pour les ressources déclarées uniquement dans les valeurs / … (atsortingbuts, chaînes, etc.), la convention est généralement mixteCase.
  • 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 où vous voyez des choses comme layout_width et layout_alignLeft. Dans un fichier de mise en page, les atsortingbuts à la fois pour la gestion de la présentation et de la mise en page parent sont mélangés, même si ce sont des propriétaires différents. La convention “layout_ *” garantit qu’il n’y a pas de conflit entre ces noms et qu’il est facile de comprendre quelle entité affecte le nom.

Cette convention “layout_blah” a également été utilisée dans quelques autres endroits. Par exemple, il existe des atsortingbuts “state_blah” qui sont les états pouvant être dessinés par une vue.

En raison 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 des valeurs explicites. En général, nous aimerions restr avec underscore_separated pour tout cela, mais cela ne se produit pas toujours.

En fin de compte, nous ne nous préoccupons pas beaucoup des conventions de nommage des ressources. Le plus important que nous gardons cohérent est “mixedCase” pour les atsortingbuts, et l’utilisation de “layout_blah” pour identifier les atsortingbuts de parameters de disposition.

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 atsortingbuts sont tous assez cohérents (étant donné que vous comprenez la convention layout_), les drawables sont tous des raccourcis séparés, etc.

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

Vous pouvez en trouver beaucoup via la recherche google par exemple. Et la meilleure convention de nommage n’existe pas. Cela dépend toujours de vos besoins et des atsortingbuts de votre projet (le plus important est la scope).


Récemment, j’ai lu des articles sur le nommage de ressources dans Android XML de Jeroen Mols. Author mentionne le principe de base que toutes les ressources doivent suivre et comment cette convention est appliquée à chaque type de ressource. Les deux décrits sur la ressource Android nommer la feuille de sortingche :

Ressource Android nommer feuille d'aide

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


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

Les conventions relatives à la valeur des ressources dans les projets d’une telle ampleur requièrent plus d’investigation sur la manière dont elles seront utilisées. Prenez des 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 des chaînes en plusieurs fichiers.

Je suppose que vous cherchez quelque chose pour commencer. Je recommande 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 nommage.

Gardez également à l’esprit qu’au fur et à mesure que le projet se développe, de nombreux besoins et exigences peuvent changer avec le temps. Donc, il est tout à fait normal que les conventions de nommage appropriées au début ne conviendront pas après 2 ans. Et c’est tout à fait bien. Vous ne devriez pas essayer de prédire l’avenir. Il suffit de choisir une convention et de la suivre. Vous trouverez si cela convient à vous et à votre projet. Si ce n’est pas le cas, réfléchissez à la raison pour laquelle il ne convient pas et commencez à utiliser autre chose.

Ceci 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 impose une restitution sur les noms de fichiers de ressources xml, mais les traits de soulignement semblent convenir. ADT déclare effectivement

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

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

Pour id, j’utilise un qualificatif de 3 lettres suivi de ce qu’il désigne 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 label et textbox.

Voici quelques autres que j’utilise couramment:

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

J’utilise le même code dans le fichier java, donc je n’ai pas à y penser, la scope du paquet le permettra très heureusement:

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

Vous pourriez, si vous préférez, append un peu d’espacement en utilisant un soulignement, par exemple btn_foo … Je le ferais probablement si je pouvais briser de vieilles habitudes.

Il y a ceux qui peuvent prétendre que l’abréviation de ces termes peut ne pas être idéale et les puristes diraient que le nom complet devrait être utilisé, mais quand vous nommez des dizaines de contrôles et changez de systèmes et de frameworks, les utilisent depuis plus de dix ans 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 un textbox ou un edittext. Tout ce que j’ai besoin de savoir, c’est que lblFoo est l’étiquette statique et que txtFoo est ce que l’utilisateur tape dans.

Une dernière remarque est que, peu importe la convention que vous décidez des choses importantes, nommer les contrôles correctement et de manière cohérente, de sorte que vous ne vous débattiez pas avec des ID par défaut vagues, par exemple TextView5 ou un mélange de conventions différentes.

Je ne pense pas qu’il existe une convention standard promue par Google. J’ai vu toutes sortes de manières différentes de nommer des personnes, même dans différentes applications officielles de Google.

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

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

Dimensions et tailles, conventions de nommage, styles et thèmes, neuf patchs, etc.

Si vous parcourez la documentation d’Android, il existe différentes mentions de “meilleures pratiques”, mais il n’y a certainement pas de règles concrètes. Par exemple, dans Icon Design Guidelines , Google suggère de nommer des icons avec un préfixe “ic_”.

Un bon endroit pour commencer peut être la fourniture de ressources .

Renseignez-vous également sur les sources / exemples du SDK ainsi que sur le blog des développeurs Android si vous voulez voir comment les développeurs de Google agissent.

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 considéré pour nommer les ressources:
1. trouver des ressources facilement lors de l’écriture du code
2. comprendre les ressources facilement lors de la lecture du code
3. rendre les noms utiles pour les traducteurs (ressources R.ssortingng.* Uniquement)
4. réutiliser des modèles avec (conflits de ressources R.id.* )
5. traiter des projets de bibliothèque

Logiquement, organiser les ressources ne devrait pas être différent du regroupement des classes Java dans des packages (ou dans la mise des fichiers dans des dossiers). Cependant, comme les ressources Android ne disposent pas d’espaces de noms, des préfixes doivent être ajoutés au nom de la ressource pour obtenir le même résultat (par exemple, com_example_myapp_photo devient com_example_myapp_photo ).

Je suggère de diviser l’application en composants distincts (activités, fragments, dialogs, etc.) avec des noms uniques courts pouvant être utilisés comme préfixes de ressources. De cette manière, nous regroupons les ressources avec les 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 projets et de bibliothèque (points 4 et 5). Notez que les ressources communes à plusieurs composants peuvent toujours avoir un préfixe (par exemple, R.ssortingng.myapp_ok_button ).

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

Parfois, “component_name” nous donnera suffisamment d’informations, ce qui est particulièrement vrai si le type est déjà donné par la classe R (dans R.ssortingng.myapp_name_ssortingng la 2ème “chaîne” est redondante). Cependant, l’ajout explicite de 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 “name” et “type” peuvent être échangées pour permettre un filtrage basé sur les R.ssortingng.photo_menu_* ( R.ssortingng.photo_menu_* ne nous donnera que des éléments liés aux menus 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.ssortingng.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 

J’ai trouvé la prochaine convention de nommage pour les chaînes:

 []__ 

Par exemple, clear_playlist_text, delete_song_message, update_playlist_positivebutton_text. Et “action” ici est facultatif.

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 de fichiers) sauf que j’ai ajouté “x” devant les identifiants, par exemple:

  

En java, nous pouvons l’utiliser simplement (on peut aussi s’en souvenir simplement)

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

Ici, mTvName (c’est en général les conventions de dénomination suggérées par Android) et xTvName qui a été nommé dans le fichier de mise en page de l’ID Android TextView (x pour XML), j’ai suivi ce type de conventions de nommage pour des objects tels que

en 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 raccourcir vos noms autant que possible et il vaut mieux qu’ils soient compréhensibles et significatifs pour les autres co-développeurs (mais ce n’est peut-être pas toujours possible). J’espère que mon expérience aidera les autres, les suggestions sont les bienvenues.

Dans nos projets Android, il y a beaucoup de composants comme des boutons, des étiquettes, des zones de texte. Donc, un nom simple comme par exemple “name” est très déroutant pour identifier “name” est label ou textbox. Cela se produit principalement lorsque vous gérez 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 TextBox ou les étiquettes

Exemple :

  btnName labName txtName listName 

C’est peut-être utile pour vous.

Il y a des ressortingctions:

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

Par ailleurs, il est préférable de suivre les directives ou d’apprendre du code standard.