Gibt es Konventionen zum Benennen von Ressourcen?

Gibt es Konventionen zum Benennen von Ressourcen in Android? Zum Beispiel Schaltflächen, Textansichten, Menüs usw.

Ich weiß nicht, ob es offizielle Empfehlungen gibt.

Für IDs in meinen Layouts mit Widgets und Containern verwende ich die Konvention:

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

Ich mache die gleiche Strategie für alle Dimensionen, Zeichenfolgen, Zahlen und Farben, die ich in diesen Layouts verwende. Ich versuche jedoch zu verallgemeinern. Wenn beispielsweise alle Schaltflächen eine gemeinsame Textfarbe haben, wird dem Namen kein Layout vorangestellt. Der Ressourcenname wäre 'button_textColor'. Wenn alle textColors dieselbe Ressource verwenden, wird sie als 'textColor' bezeichnet. Bei Styles ist dies normalerweise auch der Fall.

Für Menüressourcen verwende ich:

menu_<activity>_<name>

Animationen sind nur unterschiedlich, da Sie keine Großbuchstaben verwenden können. Gleiches gilt für zeichnbare XML-Ressourcen, glaube ich.

Android SDK ist ein guter Anfang.

Zum Beispiel versuche ich, IDs innerhalb der Aktivität zu erfassen.

Wenn ich eine ListViewhätte, wäre es einfach @android:id/listin allen Aktivitäten.
Wenn ich jedoch zwei Listen hätte, würde ich die spezifischeren @id/list_appleund verwenden@id/list_orange

Generische (IDs, ...) werden also wiederverwendet, R.java filewährend den eindeutigen (manchmal wiederverwendeten) generische ( durch einen Unterstrich getrennte ) vorangestellt werden .

Der Unterstrich ist eine Sache, die ich zum Beispiel beobachtet habe:

Die Layoutbreite ist layout_widthin XML und layoutWidthim Code angegeben , daher versuche ich, mich daran zu haltenlist_apple

Also wird ein Login Button sein login, aber wenn wir zwei Logins haben dann login_foound login_bar.

Entnommen aus der Android-Dokumentation . Es gibt mehr zu diesem Thema.

Um Ihre Frage zu beantworten: Ja, das gibt es.

Sie können viele davon beispielsweise über die Google-Suche finden . Und es gibt keine beste Namenskonvention. Dies hängt immer von Ihren Anforderungen und Ihren Projektattributen ab (vor allem vom Umfang).

Kürzlich habe ich einen ziemlich guten Blog-Beitrag über das Benennen von Ressourcen in Android XML von Jeroen Mols gelesen . Der Autor erwähnt das Grundprinzip, dem alle Ressourcen folgen sollten, und wie diese Konvention dann auf jeden Ressourcentyp angewendet wird. Beide werden auf dem Spickzettel zur Benennung von Android-Ressourcen beschrieben :

Anschließend beschreibt er jedes Element und jeden Ressourcentyp im Detail.

Ich würde sagen, Sie könnten diese Konvention für kleine bis mittlere Projekte verwenden (persönlicher Gebrauch, Vertragsanträge für einige Monate). Obwohl ich es nicht für Langzeitprojekte mit mehr als 50 Aktivitäten oder mehr als 1000 Zeichenfolgen empfehlen würde.

Konventionen für Ressourcenwerte in Projekten von so großem Umfang erfordern genauere Untersuchungen darüber, wie sie verwendet werden. Nehmen Sie zum Beispiel Strings. Dies kann sich auf die Größe Ihres Teams, das von Ihnen verwendete Übersetzungscenter (falls vorhanden), das von Ihnen verwendete VCS (um beispielsweise Zusammenführungskonflikte zu vermeiden) usw. auswirken. Möglicherweise möchten Sie sogar Zeichenfolgen in mehrere Dateien aufteilen.

Ich nehme an, Sie suchen zunächst etwas. Daher würde ich den Blog-Beitrag empfehlen, den ich erwähnt habe. Es ist gut für den Anfang und Sie können es definitiv als Inspiration verwenden, um eigene gute Namenskonventionen zu erstellen.

Denken Sie auch daran, dass sich mit dem Wachstum eines Projekts viele Bedürfnisse und Anforderungen mit der Zeit ändern können. Es ist also völlig normal, dass Namenskonventionen, die am Anfang geeignet waren, nach 2 Jahren nicht mehr geeignet sind. Und es ist völlig in Ordnung. Sie sollten nicht versuchen, die Zukunft vorherzusagen. Wählen Sie einfach eine Konvention und folgen Sie ihr. Sie werden feststellen, ob es für Sie und Ihr Projekt geeignet ist. Wenn dies nicht der Fall ist, überlegen Sie, warum es nicht geeignet ist, und verwenden Sie etwas anderes.

In Ressourcen werden einige Konventionen verwendet:

• Für Ressourcen, die als separate Dateien vorhanden sind, müssen sie in Kleinbuchstaben_untercore_separiert sein. Das Appt-Tool stellt sicher, dass Ihre Dateien nur in Kleinbuchstaben geschrieben werden, da die Verwendung von Groß- und Kleinschreibung Probleme bei Dateisystemen verursachen kann, bei denen die Groß- und Kleinschreibung nicht berücksichtigt wird.
• Für Ressourcen, die nur in Werten / ... deklariert sind (Attribute, Zeichenfolgen usw.), lautet die Konvention im Allgemeinen MixedCase.
• Es gibt eine Konvention, die manchmal verwendet wird, um Namen mit einer "Klassifizierung" zu kennzeichnen, um einfache Namespaces zu erhalten. Hier sehen Sie beispielsweise Dinge wie layout_width und layout_alignLeft. In einer Layoutdatei werden die Attribute sowohl für die Ansicht als auch für die übergeordnete Layoutverwaltung gemischt, obwohl sie unterschiedliche Eigentümer sind. Die Konvention "layout_ *" stellt sicher, dass keine Konflikte zwischen diesen Namen bestehen und es leicht zu verstehen ist, welche Entität der Name beeinflusst.

Diese "layout_blah" -Konvention wurde auch an einigen anderen Stellen verwendet. Beispielsweise gibt es "state_blah" -Attribute, die die zeichnbaren Zustände sind, die eine Ansicht haben kann.

Auch aufgrund dieser beiden Konventionen (underscore_separated für Dateien, MixedCase für deklarierte Ressourcen) werden Sie eine Reihe von Inkonsistenzen feststellen. Beispielsweise können Farben entweder mit Dateien oder als explizite Werte deklariert werden. Im Allgemeinen möchten wir bei all diesen Punkten bei underscore_separated bleiben, aber das passiert nicht immer.

Letztendlich machen wir uns keine großen Sorgen um Namenskonventionen für Ressourcen. Das große Problem, das wir konsistent halten, ist "MixedCase" für Attribute und die Verwendung von "layout_blah" zur Identifizierung von Layoutparameterattributen.

Auch das Durchsuchen der öffentlichen Ressourcen hier sollte ein gutes Gefühl für die Konventionen vermitteln:

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

Sie werden sehen, dass die Attribute alle ziemlich konsistent sind (vorausgesetzt, Sie verstehen die layout_-Konvention), die Drawables sind alle unterstrichen_getrennt usw.

Dies ist ein häufiges Problem für jede Sprache oder jedes Framework. Solange Sie jedoch reservierte Wörter vermeiden, sollten Sie in Ordnung sein, vorausgesetzt, Sie können sich daran erinnern, was Sie Dinge genannt haben.

Ich habe festgestellt, dass Android die Namen von XML-Ressourcendateien einschränkt, aber Unterstriche scheinen in Ordnung zu sein. ADT gibt tatsächlich an

Dateibasierte Ressourcennamen dürfen nur Kleinbuchstaben az, 0-9 oder _ enthalten.

Etwas, das mich zuerst auslöste, war das Fehlen von Namespaces mit IDs, aber dies kann im Allgemeinen ignoriert werden, wenn Sie zwei IDs haben, die das gleiche Android nur die definierte ID wiederverwendet.

Für IDs verwende ich ein 3-Buchstaben-Qualifikationsmerkmal, gefolgt von dem, worauf es in der Kamelnotation verweist, z. B. lblFoo für eine statische Textbezeichnung (oder Textansicht), txtFoo für ein bearbeitbares Textfeld (edittext in Android). Dies mag zunächst seltsam erscheinen, aber ich benutze es seit VB6 und diese Steuerelemente wurden als Label und Textbox bezeichnet.

Hier sind einige weitere, die ich häufig benutze:

• btnFoo - Schaltfläche
• pwdFoo - Passwort
• lstFoo - Liste
• clrFoo - Farbe
• tblFoo - Tabelle
• colFoo - Spalte
• rowFoo - row
• imgFoo - Bild
• dimFoo - Dimension
• padFoo - Polsterung
• mrgFoo - Rand

Ich verwende den gleichen Code auch in der Java-Datei, damit ich nicht darüber nachdenken muss. Der Paketumfang ermöglicht dies recht glücklich:

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

Sie könnten, wenn Sie es vorziehen, einen kleinen Abstand mit Unterstrich hinzuzufügen, dh btn_foo ... Ich würde dies wahrscheinlich tun, wenn ich alte Gewohnheiten brechen könnte.

Es gibt Leute, die argumentieren, dass die Abkürzung möglicherweise nicht ideal ist, und die Puristen würden argumentieren, dass der vollständige Name verwendet werden sollte, aber wenn Sie Dutzende von Steuerelementen benennen und zwischen verschiedenen Systemen und Frameworks wechseln, verlieren die vollständigen Namen ihre Bedeutung haben diese seit über einem Jahrzehnt in VB, C ++, ASP.NET, WinForms in C # und VB.NET, Android und Python verwendet. Ich muss mich nie daran erinnern, ob Android es ein Textfeld oder einen Edittext nennt. Ich muss nur wissen, dass lblFoo die statische Bezeichnung ist und txtFoo das ist, in das der Benutzer Eingaben eingibt.

Eine letzte Anmerkung ist, dass unabhängig davon, für welche Konvention Sie sich für die wichtigen Dinge entscheiden, die Benennung von Steuerelementen richtig und konsistent ist, damit Sie nicht mit vagen Standard-IDs wie TextView5 oder einer Mischung verschiedener Konventionen ringen

Nützlicher Link für Designer und Entwickler - hier

Abmessungen und Größen, Namenskonventionen, Stile und Themen, Neun-Patches und so weiter.

Ich glaube nicht, dass es eine Standardkonvention gibt, die von Google beworben wird. Ich habe viele verschiedene Arten gesehen, wie Leute Dinge benennen, sogar in verschiedenen offiziellen Google Apps.

Was auch immer Ihnen am meisten hilft, wenn Sie versuchen, 100 Layout-Dateien (oder Drawables, Menüs usw.) in einer Verzeichnishierarchie zu verstehen.

Eine kurze Antwort: Wenn Sie von Android-Entwicklern lernen möchten, ist die Support-Bibliothek v7 ( https://dl-ssl.google.com/android/repository/support_r21.zip ) ein gutes Beispiel.

Ansonsten habe ich Folgendes für die Benennung von Ressourcen in Betracht gezogen:
1. Ressourcen beim Schreiben von Code leicht finden
2. Ressourcen beim Lesen von Code leicht verstehen
3. Namen für Übersetzer nützlich machen ( R.string.*nur Ressourcen)
4. Layouts wiederverwenden mit <include/>( R.id.*Ressourcenkonflikten)
5. Umgang mit Bibliotheksprojekten

Das Anordnen von Ressourcen sollte sich logischerweise nicht vom Gruppieren von Java-Klassen in Paketen (oder dem Ablegen von Dateien in Ordnern) unterscheiden. Da Android-Ressourcen jedoch keine Namespaces haben, müssen dem Ressourcennamen Präfixe hinzugefügt werden, um dasselbe zu erreichen (z . B. com.example.myapp.photowird com_example_myapp_photo).

Ich schlage vor, die App in separate Komponenten (Aktivitäten, Fragmente, Dialoge usw.) mit kurzen eindeutigen Namen zu unterteilen, die als Ressourcenpräfixe verwendet werden können. Auf diese Weise gruppieren wir Ressourcen mit verwandten Funktionen, wodurch sie leicht zu finden sind (Punkt 1), und vermeiden gleichzeitig Namenskonflikte mit beiden <include/>und Bibliotheksprojekten (Punkte 4 und 5). Beachten Sie, dass Ressourcen, die mehreren Komponenten gemeinsam sind, weiterhin ein Präfix haben können (z. B. R.string.myapp_ok_button).

Nach dem Präfix sollte der Name angeben, wofür die Ressource verwendet wird (auszuführende Aktion, anzuzeigender Inhalt usw.). Die Wahl eines guten Namens ist wichtig für das Verständnis (Punkte 2 und 3).

Manchmal gibt uns "Komponentenname" genügend Informationen, was insbesondere dann der Fall ist, wenn der Typ bereits von der R-Klasse angegeben wird (in R.string.myapp_name_stringder zweiten "Zeichenfolge" ist redundant). Das explizite Hinzufügen von Typ kann jedoch das Verständnis verbessern (z. B. kann es für Übersetzer hilfreich sein, zwischen einem Toast oder einem Etikett zu unterscheiden). Manchmal können die Teile "Name" und "Typ" ausgetauscht werden, um eine typbasierte Filterung zu ermöglichen (es R.string.photo_menu_*werden nur menübezogene Elemente für die Fotokomponente angezeigt).

Angenommen, wir schreiben eine Aktivität zum Aufnehmen von Bildern, Klasse com.example.myapp.photo .PhotoActivity. Unsere Ressourcen könnten folgendermaßen aussehen (gruppiert nach der Komponente "Foto"):

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  

Wenn Sie in der Android-Dokumentation stöbern, werden verschiedene "Best Practices" erwähnt, aber es gibt sicherlich keine konkreten Regeln. In den Richtlinien für das Symboldesign schlägt Google beispielsweise vor, Symbole mit dem Präfix "ic_" zu benennen.

Ein guter Ausgangspunkt kann die Bereitstellung von Ressourcen sein .

Stöbern Sie auch in der SDK-Quelle / den SDK-Beispielen sowie im Android-Entwicklerblog, wenn Sie sehen möchten, wie die Google-Entwickler vorgehen.

Ich fand die nächste Namenskonvention für Zeichenfolgen praktisch:

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

Beispiel: clear_playlist_text, delete_song_message, update_playlist_positivebutton_text. Und "Aktion" hier ist optional.

Sie können die Google - Dokumentation für die Code - Stil lesen eine Vorstellung zu bekommen hier

Ich habe im Allgemeinen die Java-Namenskonventionen für Ressourcen-IDs befolgt (nicht für Dateien für Dateien), außer dass ich "x" vor den IDs hinzugefügt habe, zum Beispiel:

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

In Java können wir es einfach verwenden (wir können uns auch einfach erinnern)

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

Hier mTvName (es wird im Allgemeinen von Android Namenskonventionen vorgeschlagen) und xTvName, die in der Layoutdatei als Teil der ID von android TextView (x für XML) benannt wurden, habe ich diese Art von Namenskonventionen für Ansichtsobjekte wie Buttons und EditText usw. befolgt.

in XML IDS: xViewTypeSpecificName

in Java: mViewTypeSpeficName

Die oben genannten Konventionen erleichtern mir das Leben, wenn ich komplexe Layouts erstelle. Versuchen Sie einfach, Ihre Namen so kurz wie möglich zu halten, und es ist besser, wenn sie für andere Mitentwickler verständlich und aussagekräftig sind (dies ist jedoch möglicherweise nicht jedes Mal möglich). Ich hoffe, dass meine Erfahrung anderen hilft. Vorschläge sind willkommen.

In unseren Android-Projekten gibt es viele Komponenten wie Schaltflächen, Beschriftungen, Textfelder. Ein so einfacher Name wie zum Beispiel "Name" ist sehr verwirrend, um zu identifizieren, dass "Name" eine Bezeichnung oder ein Textfeld ist. Hauptsächlich passiert es, wenn Sie Projekte pflegen, die von anderen Entwicklern entwickelt wurden.

Um diese Art von Verwirrung zu vermeiden, habe ich folgende Namen für Schaltflächen, Textfelder oder Beschriftungen verwendet

Beispiel:

 btnName
 labName
 txtName
 listName

Vielleicht ist das hilfreich für Sie.

Es gibt einige Einschränkungen:

1. Der Ressourcenname sollte az, 0-9, _ enthalten
2. Der Ressourcenname sollte mit az, _ beginnen

Übrigens ist es ratsamer, die Richtlinien zu befolgen oder aus Standardcode zu lernen.