it-swarm.com.de

Gibt es Konventionen zur Benennung von Ressourcen?

Gibt es Konventionen, um Ressourcen in Android zu benennen? Zum Beispiel Schaltflächen, Textansichten, Menüs usw.

95
Eugene

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 verwende dieselbe 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 textColor haben, wird dem Namen nicht das 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 unterscheiden sich nur, da Sie keine Großbuchstaben verwenden können. Dasselbe gilt für zeichnende XML-Ressourcen, glaube ich.

24
Ian

Android SDK ist ein guter Anfang.

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

Wenn ich eine ListView hätte, wäre es einfach in allen Aktivitäten @Android:id/list.
Wenn ich jedoch zwei Listen hätte, würde ich die spezifischeren @id/list_Apple und @id/list_orange verwenden.

So wird generisch (ids, ...) im R.Java file wiederverwendet, während den eindeutigen (manchmal wiederverwendeten) generischen vorangestellt wird, die durch einen Unterstrich getrennt sind. 


Der Unterstrich ist eine Sache, die ich zum Beispiel beobachtete:

Die Layoutbreite ist layout_width in xml und layoutWidth in code. Ich versuche also, als list_Apple dabei zu bleiben.

Eine Login-Schaltfläche ist also login, aber wenn wir zwei Logins haben, dann login_foo und login_bar.

43
Samuel

Aus Android-Dokumentation entnommen . Es gibt mehr zum Thema.

23

Um Ihre Frage zu beantworten: Ja, gibt es.

Viele davon finden Sie beispielsweise über google search . Und die beste Namenskonvention gibt es nicht. Es hängt immer von Ihren Bedürfnissen und Ihren Projektattributen ab (am wichtigsten ist der Umfang).


Vor kurzem habe ich ziemlich gut blog post über Namensressourcen in Android XML von Jeroen Mols gelesen. Der Autor erwähnt das Grundprinzip, dem alle Ressourcen folgen sollten, und anschließend, wie diese Konvention auf jeden Ressourcentyp angewendet wird. Beides auf Android-Ressourcen-Benennungsschema beschrieben:

Android resource naming cheat sheet

Er beschreibt dann jedes Element und jeden Ressourcentyp detailliert.


Ich würde sagen, dass Sie diese Konvention von kleinen bis mittleren Projekten (persönlicher Gebrauch, einige Monate Vertragsanträge) anwenden könnten. Ich würde es jedoch nicht für Projekte mit mehr als 50 Aktivitäten oder mehr als 1000 Zeichenfolgen empfehlen.

Konventionen für Ressourcenwerte in Projekten von so großem Umfang erfordern weitere Untersuchungen, wie sie verwendet werden. Nehmen Sie zum Beispiel Strings. Möglicherweise wird die Größe Ihres Teams, das von Ihnen verwendete Übersetzungscenter (falls vorhanden), VCS , die Sie verwenden (um Zusammenführungskonflikte zu vermeiden) usw. beeinflusst. Sie könnten sogar überlegen, Strings in mehrere Dateien aufzuteilen .

Ich gehe davon aus, dass Sie nach etwas suchen, um damit anzufangen. Daher würde ich den Blogbeitrag empfehlen, den ich erwähnt habe. Es ist gut für den Anfang und Sie können es definitiv als Inspiration verwenden, um gute eigene Namenskonventionen zu erstellen.

Beachten Sie auch, dass sich mit dem Wachstum eines Projekts viele Anforderungen und Anforderungen im Laufe der Zeit ändern können. So ist es völlig normal, dass Namenskonventionen, die anfangs geeignet waren, nach 2 Jahren nicht geeignet sind. Und es ist vollkommen in Ordnung. Sie sollten nicht versuchen, die Zukunft vorherzusagen. Wählen Sie einfach eine Konvention und folgen Sie dieser. Sie werden feststellen, ob es für Sie und Ihr Projekt geeignet ist. Wenn nicht, überlegen Sie, warum es nicht geeignet ist, und verwenden Sie etwas anderes.

15
arenaq

In Ressourcen werden einige Konventionen verwendet:

  • Für Ressourcen, die als separate Dateien vorhanden sind, müssen sie lower_case_underscore_separated sein. Das appt-Tool stellt sicher, dass Ihre Dateien nur Kleinbuchstaben sind, da die Verwendung von Groß- und Kleinschreibung zu Problemen in Dateisystemen führen kann, die nicht zwischen Groß- und Kleinschreibung unterscheiden.
  • Für Ressourcen, die nur in Werten/... (Attribute, Zeichenfolgen usw.) deklariert sind, ist 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 zum Beispiel 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, auch wenn sie unterschiedliche Eigentümer sind. Die "layout_ *" - Konvention stellt sicher, dass zwischen diesen Namen keine Konflikte bestehen, und es ist leicht zu verstehen, auf welche Entität sich der Name auswirkt.

Diese "layout_blah" -Konvention wurde auch an einigen anderen Orten verwendet. Zum Beispiel gibt es "state_blah" -Attribute, die die Zeichenzustände sind, die eine Ansicht haben kann.

Auch aufgrund dieser beiden Konventionen (unterstrichen_separiert 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 uns bei allers bei Underscore_separated aufhalten, aber das passiert nicht immer.

Letztendlich machen wir uns keine großen Sorgen um Namenskonventionen für Ressourcen. Das große, das wir konsistent halten, ist "mixedCase" für Attribute und die Verwendung von "layout_blah" zum Erkennen von Layout-Parameterattributen.

Auch das Durchsuchen öffentlicher Ressourcen sollte den Konventionen einen guten Eindruck vermitteln:

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

Sie werden sehen, dass die Attribute ziemlich konsistent sind (vorausgesetzt, Sie verstehen die Konvention layout_), drawables sind alle unterstrichen_separiert usw.

15
hackbod

Dies ist ein allgemeines Problem für jede Sprache oder Rahmen, aber solange Sie reservierte Wörter vermeiden, sollten Sie in Ordnung sein, vorausgesetzt, Sie können sich daran erinnern, was Sie als Dinge bezeichnet haben.

Ich habe bemerkt, dass Android die XML-Ressourcendateinamen einschränkt, aber Unterstriche scheinen in Ordnung zu sein. ADT sagt tatsächlich 

Dateibasierte Ressourcennamen dürfen nur Kleinbuchstaben von a-z, 0-9 oder _ enthalten.

Was mich anfangs veranlasst hat, war das Fehlen von Namespaces mit IDs. Dies kann jedoch generell ignoriert werden, wenn zwei IDs verwendet werden, bei denen das gleiche Android die definierte ID wiederverwendet.

Für IDs verwende ich ein aus 3 Buchstaben bestehendes Qualifikationsmerkmal, gefolgt von dem, worauf es sich in der Kamelnotation bezieht, z. B. lblFoo für eine statische Textbezeichnung (oder Textansicht), txtFoo für ein bearbeitbares Textfeld (Edittext in Android). Das mag auf den ersten Blick merkwürdig erscheinen, aber ich verwende es seit VB6 und diese Steuerelemente wurden als Label und Textbox bezeichnet.

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

  • btnFoo - Taste
  • pwdFoo - Passwort
  • lstFoo - liste
  • clrFoo - Farbe
  • tblFoo - tisch
  • colFoo - Spalte
  • rowFoo - Zeile
  • imgFoo - Bild
  • dimFoo - dimension
  • padFoo - Polsterung
  • mrgFoo - Marge

Ich verwende dasselbe auch in Code in der Java-Datei, sodass ich nicht darüber nachdenken muss. Der Umfang des Pakets wird dies sehr glücklich zulassen:

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

Sie könnten, wenn Sie es vorziehen, einen kleinen Abstand mit Unterstrich hinzufügen, d. H. Btn_foo ... Ich würde dies wahrscheinlich tun, wenn ich alte Gewohnheiten brechen könnte.

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

Eine letzte Anmerkung ist, dass unabhängig von der Konvention, die Sie für die wichtigen Dinge festlegen, die Benennung von Steuerelementen richtig und konsistent ist, sodass Sie nicht mit vagen Standard-IDs wie beispielsweise TextView5 oder einer Mischung verschiedener Konventionen kämpfen müssen

11
Merlin

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

Abmessungen und Größen, Namenskonventionen, Stile und Designs, neun Patches usw. 

3
validcat

Ich glaube nicht, dass es eine Standardkonvention gibt, die von Google gefördert wird. Ich habe alle möglichen Arten der Namensgebung von Leuten gesehen, sogar in verschiedenen offiziellen Google-Apps.

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

3
Jason Knight

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

Ansonsten habe ich Folgendes in Betracht gezogen, um Ressourcen zu benennen:
1. Ressourcen beim Schreiben von Code leicht finden
2. Ressourcen leicht verstehen, wenn Code gelesen wird
3. Namen für Übersetzer nützlich machen (nur R.string.* Ressourcen)
4. Wiederverwenden von Layouts mit <include/> (R.id.* Ressourcenkonflikte)
5. Umgang mit Bibliotheksprojekten

Das Anordnen von Ressourcen sollte logischerweise nicht anders sein als das Gruppieren von Java-Klassen in Paketen (oder das Ordnen von Dateien). Da Android-Ressourcen jedoch keine Namespaces haben, müssen dem Ressourcennamen Präfixe hinzugefügt werden, um denselben Namen zu erhalten (beispielsweise com.example.myapp.photo wird com_example_myapp_photo).

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

Nach dem Präfix sollte der Name uns mitteilen, 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 "Komponentenname" genügend Informationen, was besonders dann der Fall ist, wenn der Typ bereits von der R-Klasse angegeben wurde (in R.string.myapp_name_string ist der 2. "String" redundant). Das explizite Hinzufügen eines Typs kann jedoch das Verständnis verbessern (z. B. kann es für Übersetzer hilfreich sein, zwischen einem Toast oder einer Bezeichnung zu unterscheiden). Manchmal können die Teile "Name" und "Typ" ausgetauscht werden, um eine typbasierte Filterung zu ermöglichen (R.string.photo_menu_* gibt nur menübezogene Elemente für die Fotokomponente an).

Nehmen wir an, wir schreiben eine Aktivität zum Fotografieren, 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  
3
bzu

Wenn Sie in der Android-Dokumentation herumstochern, gibt es verschiedene Erwähnungen von "Best Practices", aber es gibt sicherlich keine konkreten Regeln. Zum Beispiel schlägt Google in Icon Design Guidelines vor, Icons mit einem Präfix "ic_" zu benennen.

Ein guter Startplatz kann sein: Bereitstellung von Ressourcen .

Auch im SDK-Quelltext/in den Beispielen sowie im Android Developers Blog wenn Sie sehen möchten, wie die Google-Entwickler etwas unternehmen.

2
NuSkooler

Ich fand eine praktische Benennungskonvention für Strings:

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

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

1
andrei

In unseren Android-Projekten gibt es viele Komponenten wie Schaltflächen, Beschriftungen, Textfelder. Ein einfacher Name wie zum Beispiel "Name" ist sehr verwirrend, wenn "Name" als Beschriftung oder Textfeld bezeichnet wird. Hauptsächlich geschieht dies, wenn Sie Projekte verwalten, die von anderen Entwicklern entwickelt wurden.

Um diese Art von Verwirrung zu vermeiden, habe ich folgende Namen für Buttons, TextBoxes oder Labels verwendet 

Beispiel:

 btnName
 labName
 txtName
 listName

Vielleicht ist das hilfreich für Sie.

0
Dhiral Pandya

Ich habe im Allgemeinen die Java-Namenskonventionen für Ressourcen-IDs (nicht für Dateien für Dateien) befolgt, außer dass ich vor den IDs ein "x" eingefü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 sind mTvName (im Allgemeinen von Android vorgeschlagene Namenskonventionen) und xTvName, die in der Layout-Datei als Teil der Android-TextView-ID (x für XML) benannt wurden, folgte dieser Art von Namenskonventionen für Ansichtsobjekte wie Buttons und EditText usw.

in XML IDS:xViewTypeSpecificName

in Java:mViewTypeSpeficName

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

0
sunriser

sie können die Google-Dokumentation für den Codestil lesen, um eine Idee zu erhalten. hier

0
Kevin Qiu