Existe-t-il des conventions sur la manière de nommer les ressources?
Existe-t-il des conventions pour nommer les ressources dans Android? Par exemple, des boutons, textViews, menus, etc.
Je ne sais pas s'il y a 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 les dimensions, les chaînes, les nombres et les couleurs que j'utilise dans ces mises en page. Cependant, j'essaie de généraliser. Par exemple, si tous les boutons ont un textColor commun, je ne préfixerai pas le nom avec la présentation Le nom de la ressource serait 'button_textColor'. Si tous les textColors utilisent la même ressource, la ressource sera nommée '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 différentes car vous ne pouvez pas utiliser de lettres majuscules. Il en va de même pour les ressources XML attrayantes, je crois.
Android SDK sera un bon point de départ.
Par exemple, j'essaie d'étendre les identifiants dans l'activité.
Si j’avais une ListView ce serait tout simplement @Android:id/list dans toutes les activités.
Cependant, si j’avais deux listes, j’utiliserais les codes plus spécifiques @id/list_Apple et @id/list_orange
Donc générique (ids, ...) est réutilisé dans le R.Java file tandis que les uniques (parfois réutilisés) sont préfixés par les génériques séparés par un tiret bas .
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 code , alors j'essaie de m'y tenir comme list_Apple
Donc, un bouton de connexion sera login, mais si nous avons deux connexions then login_foo et login_bar.
Extrait de la documentation Android . Il y a plus là-bas sur le sujet.
Pour répondre à votre question: oui, il y en a.
Vous pouvez en trouver beaucoup via google search par exemple. Et la meilleure convention de nommage n'existe pas. 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 blog sur la désignation des ressources dans Android XML de Jeroen Mols. L'auteur mentionne le principe de base que toutes les ressources devraient suivre, puis comment cette convention est appliquée à chaque type de ressource. Les deux décrits sur ressource Android nommant la feuille de triche :
Il décrit ensuite chaque élément et chaque type de ressource en détail.
Je dirais que vous pouvez utiliser cette convention pour des projets de petite à moyenne envergure (usage personnel, demandes contractuelles de quelques mois). Bien que, je ne le recommande pas pour des projets à long terme avec comme 50 activités ou plus de 1000 chaînes.
Les conventions relatives à la valeur des ressources dans les projets de cette ampleur nécessitent des recherches plus poussées sur la manière dont elles seront utilisées. Prenez des ficelles par exemple. Peut-être affecté par la taille de votre équipe, le centre de traduction que vous utilisez (le cas échéant), VCS que vous utilisez (pour éviter les conflits de fusion, par exemple), etc. Vous pourriez même penser à scinder des chaînes en plusieurs fichiers .
Je suppose que vous cherchez quelque chose pour commencer. Donc, je recommanderais le blog que j'ai mentionné. C'est bon pour les débutants et vous pouvez certainement vous en inspirer pour créer vos propres conventions de nommage.
N'oubliez pas non plus que, à mesure que le projet se développe, de nombreux besoins et exigences peuvent évoluer avec le temps. Il est donc tout à fait normal que les conventions de dénomination convenant au début ne le soient pas au bout de 2 ans. Et c'est complètement 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 cela 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 garantit que vos fichiers sont uniquement en minuscules, car l'utilisation de casse mixte peut entraîner des problèmes pour les systèmes de fichiers ne respectant pas 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. Ceci est par exemple où vous voyez des choses comme layout_width et layout_alignLeft. Dans un fichier de présentation, les attributs de la vue et de la gestion de la présentation parente sont mélangés, même s’ils sont différents propriétaires. La convention "layout_ *" garantit qu'il n'y a pas de conflits entre ces noms et il est facile de comprendre quelle entité le nom impacte.
Cette convention "layout_blah" a également été utilisée dans quelques autres endroits. Par exemple, il existe des attributs "state_blah" qui sont les états pouvant être dessinés par une vue.
De plus, à 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 en tant que valeurs explicites. En règle générale, nous aimerions utiliser underscore pour tous ces éléments, mais cela ne se produit pas toujours.
En fin de compte, nous ne nous inquiétons pas beaucoup des conventions de nommage des ressources. Le gros problème que nous maintenons cohérent est "mixedCase" pour les attributs, et l'utilisation de "layout_blah" pour identifier les attributs de paramètres de présentation.
En parcourant également les ressources publiques, vous devriez avoir une bonne idée des conventions:
http://developer.Android.com/reference/Android/R.html
Vous verrez que les attributs sont tous assez cohérents (à condition de bien comprendre la convention de mise en page), les tirables sont tous underscore_separated, etc.
C’est un problème courant dans n’importe quel langage ou framework, mais tant que vous évitez les mots réservés, vous devriez être en mesure de vous souvenir de ce que vous avez appelé.
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 réellement
Les noms de ressources basés sur des fichiers doivent contenir uniquement des lettres minuscules a-z, 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 ceci peut généralement être ignoré si vous avez deux identifiants identiques, Android ne fera que réutiliser l'identifiant défini.
Pour les identifiants, j'utilise un qualificatif de 3 lettres suivi de ce à quoi il fait référence dans la notation camel, par exemple lblFoo pour une étiquette de texte statique (ou textview), txtFoo pour une zone de texte modifiable (edittext dans Android). Cela peut sembler étrange au début, mais je l’utilise depuis VB6 et ces commandes étaient appelées label et textbox.
En voici d'autres que j'utilise couramment:
- btnFoo - bouton
- pwdFoo - mot de passe
- lstFoo - liste
- clrFoo - couleur
- tblFoo - table
- colFoo - colonne
- rowFoo - row
- imgFoo - image
- dimFoo - dimension
- padFoo - rembourrage
- mrgFoo - margin
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 paquet le permettra très facilement:
Button btnFoo = (Button)findViewById(R.id.btnFoo);
Vous pouvez, si vous préférez, ajouter un peu d’espacement en utilisant un trait de soulignement, par exemple btn_foo ... Je le ferais probablement si je pouvais me débarrasser de vieilles habitudes.
Il y a ceux qui peuvent argumenter que l'abréviation de ceux-ci peut ne pas être l'idéal et les puristes diraient que le nom complet devrait être utilisé, mais lorsque vous nommez des dizaines de contrôles et que vous passez d'un système à un autre, les noms complets perdent leur signification. les utilise 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 appelle cela une zone de texte 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 entre.
Une dernière remarque est que, quelle que soit la convention que vous décidez d’importer, il est important de nommer les commandes correctement et de manière cohérente, de sorte que vous ne vous débattiez pas avec les identificateurs par défaut vagues, par exemple TextView5 ou un mélange de différentes conventions.
Lien utile pour le concepteur et les développeurs - ici
Dimensions et tailles, conventions de nommage, styles et thèmes, neuf correctifs, etc.
Je ne pense pas qu'il y ait une convention standard promue par Google. J'ai vu toutes sortes de façons différentes de nommer des éléments, même au sein de différentes applications Google officielles.
Tout ce qui vous aide le plus lorsque vous essayez de comprendre une centaine de fichiers de mise en page (ou de fichiers 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 technique v7 ( https://dl-ssl.google.com/Android/repository/support_r21.Zip ).
Sinon, voici ce que j'ai envisagé pour nommer les ressources:
1. trouver facilement des ressources lors de l'écriture de code
2. comprendre facilement les ressources lors de la lecture de code
3. faire des noms utiles pour les traducteurs (ressources R.string.* uniquement)
4. Réutilisation de modèles avec <include/> (conflits de ressources R.id.*)
5. traiter des projets de bibliothèque
Logiquement, l'organisation des ressources ne devrait pas être différente du regroupement de classes Java dans des packages (ou du placement de fichiers dans des dossiers). Toutefois, comme les ressources Android ne possèdent pas d’espace de nom, vous devez ajouter des préfixes 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, dialogues, etc.) avec des noms courts et uniques pouvant être utilisés comme préfixes de ressources. De cette manière, nous regroupons des ressources avec des fonctionnalités connexes, ce qui facilite leur recherche (point 1) et évite les conflits de noms avec les projets <include/> et 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 indiquer à quoi sert la ressource (action à effectuer, contenu à afficher, etc.). Choisir un bon nom est important pour comprendre (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_string, la deuxième "chaîne" est redondante). Cependant, l'ajout explicite de types peut améliorer la compréhension (par exemple, il peut être utile pour les traducteurs de faire la distinction entre un pain grillé ou une étiquette). Parfois, les parties "nom" et "type" peuvent être permutées pour permettre le filtrage par type (R.string.photo_menu_* nous donnera uniquement les éléments liés au menu pour le composant photo).
Supposons 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 est fait mention de "bonnes pratiques", mais il n'y a certainement pas de règles concrètes. Par exemple, dans Consignes de création d'icônes , Google suggère de nommer les icônes avec le préfixe "ic_".
Consultez également la source/les exemples du SDK ainsi que le Blog des développeurs Android si vous souhaitez savoir comment les développeurs de Google font les choses.
J'ai trouvé pratique la convention de nommage suivante pour les chaînes:
[<action>]_<object>_<purpose>
Par exemple, clear_playlist_text, delete_song_message, update_playlist_positivebutton_text. Et "action" est optionnel.
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 compliqué à identifier. "Nom" est une étiquette ou une zone de texte. 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 TextBoxes ou Labels
Exemple :
btnName
labName
txtName
listName
Peut-être que cela vous est utile.
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:
<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)
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 dans le cadre de l'Id de Android TextView (x destiné à XML), j'ai suivi ce type de conventions de dénomination pour les objets d'affichage tels que Boutons et EditText, etc.
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 le plus possible vos noms et il est préférable qu'ils soient compréhensibles et significatifs pour les autres co-développeurs (mais cela risque de ne pas être possible chaque fois), espérons que mon expérience aidera les autres, les suggestions sont les bienvenues.
vous pouvez lire la documentation google sur le style de code pour avoir une idée ici