Esistono convenzioni su come denominare le risorse?

Esistono convenzioni su come denominare le risorse in Android? Ad esempio, pulsanti, textViews, menu, ecc.

Non so se ci sono raccomandazioni ufficiali.

Per gli ID nei miei layout con widget e contenitori, utilizzo la convenzione:

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

Faccio la stessa strategia per qualsiasi dimensione, stringa, numero e colore che uso in quei layout. Tuttavia, provo a generalizzare. es. se tutti i pulsanti hanno un textColor comune, non aggiungerò il prefisso al nome con il layout. Il nome della risorsa sarebbe "button_textColor". Se tutti i textColors utilizzano la stessa risorsa, verrà chiamata "textColor". Per gli stili, di solito questo è anche il caso.

Per le risorse di menu che uso:

menu_<activity>_<name>

Le animazioni sono diverse solo in quanto non è possibile utilizzare lettere maiuscole. Lo stesso vale per le risorse xml disegnabili, credo.

Android SDK sarà un buon punto di partenza.

Ad esempio, cerco di definire l'ambito degli ID all'interno dell'attività.

Se ne avessi uno ListViewsarebbe semplicemente @android:id/listin tutte le attività.
Se, tuttavia, avessi due elenchi, utilizzerei il più specifico @id/list_applee@id/list_orange

Quindi generico (ids, ...) viene riutilizzato R.java filementre quelli univoci (a volte vengono riutilizzati) vengono preceduti da quelli generici separati da un trattino basso .

Il carattere di sottolineatura è una cosa, ho osservato, ad esempio:

La larghezza del layout è layout_widthin xml e layoutWidthnel codice , quindi cerco di attenermi ad essa comelist_apple

Quindi un pulsante di accesso sarà login, ma se abbiamo due accessi, quindi login_fooe login_bar.

Tratto dalla documentazione di Android . C'è di più sull'argomento.

Per rispondere alla tua domanda: Sì, ci sono.

Puoi trovarne molti tramite la ricerca su Google, ad esempio. E non esiste la migliore convenzione di denominazione. Dipende sempre dalle tue esigenze e dagli attributi del tuo progetto (soprattutto l'ambito).

Recentemente, ho letto un post sul blog abbastanza buono sulla denominazione delle risorse in XML Android da Jeroen Mols. L'autore menziona il principio di base che tutte le risorse dovrebbero seguire e poi come questa convenzione viene applicata a ciascun tipo di risorsa. Entrambi descritti nel cheat sheet per la denominazione delle risorse Android :

Quindi descrive in dettaglio ogni elemento e ogni tipo di risorsa.

Direi che potresti utilizzare questa convenzione per progetti medio-piccoli (uso personale, applicazioni per contratti di pochi mesi). Tuttavia, non lo consiglierei per progetti a lungo termine con oltre 50 attività o più di 1000 stringhe.

Le convenzioni per i valori delle risorse in progetti di così vasta scala richiedono ulteriori indagini su come verranno utilizzate. Prendi le stringhe per esempio. Potrebbe essere influenzato dalle dimensioni del tuo team, dal centro di traduzione che stai utilizzando (se presente), VCS che stai utilizzando (per evitare conflitti di unione, ad esempio), ecc. Potresti anche pensare di dividere le stringhe in più file.

Presumo tu stia cercando qualcosa con cui cominciare. Quindi consiglierei il post sul blog che ho citato. È buono per i principianti e puoi sicuramente usarlo come ispirazione per creare buone convenzioni di denominazione.

Inoltre, tieni presente che man mano che un progetto cresce, molte esigenze e requisiti possono cambiare nel tempo. Quindi è del tutto normale che le convenzioni di denominazione che erano adatte all'inizio non lo saranno dopo 2 anni. Ed è completamente a posto. Non dovresti cercare di prevedere il futuro. Basta scegliere una convenzione e seguirla. Troverai se è adatto a te e al tuo progetto. In caso contrario, pensa al motivo per cui non è adatto e inizia a utilizzare qualcos'altro.

Ci sono alcune convenzioni usate nelle risorse:

• Per le risorse che esistono come file separati, devono essere lower_case_underscore_separated. Lo strumento appt si assicura che i tuoi file siano solo minuscoli, perché l'uso di maiuscole e minuscole può causare problemi su filesystem senza distinzione tra maiuscole e minuscole.
• Per le risorse dichiarate solo in values ​​/ ... (attributi, stringhe, ecc.) La convenzione è generalmente mixedCase.
• C'è una convenzione usata a volte per etichettare i nomi con una "classificazione" per avere spazi dei nomi semplici. Questo è ad esempio dove vedi cose come layout_width e layout_alignLeft. In un file di layout gli attributi sia per la visualizzazione che per la gestione del layout principale sono mescolati insieme, anche se sono proprietari diversi. La convenzione "layout_ *" assicura che non ci siano conflitti tra questi nomi ed è facile capire quale entità ha impatto il nome.

Questa convenzione "layout_blah" è stata utilizzata anche in alcuni altri posti. Ad esempio, ci sono attributi "state_blah" che sono gli stati disegnabili che una vista può avere.

Anche a causa di queste due convenzioni (underscore_separated per i file, mixedCase per le risorse dichiarate), troverai una serie di incongruenze. Ad esempio, i colori possono essere dichiarati con file o come valori espliciti. Generalmente vorremmo restare con underscore_separated per tutti quelli, ma non sempre accade.

In definitiva, non ci preoccupiamo molto delle convenzioni di denominazione per le risorse. Quello più importante che manteniamo coerente è "mixedCase" per gli attributi e l'uso di "layout_blah" per identificare gli attributi dei parametri di layout.

Anche sfogliare le risorse pubbliche qui dovrebbe dare una buona idea delle convenzioni:

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

Vedrai che gli attributi sono tutti abbastanza coerenti (dato che hai compreso la convenzione layout_), i drawables sono tutti underscore_separated, ecc.

Questo è un problema comune a qualsiasi linguaggio o framework, ma fintanto che eviti le parole riservate dovresti essere a posto supponendo che tu possa ricordare ciò che hai chiamato cose.

Ho notato che Android pone una restrizione sui nomi dei file di risorse xml ma i trattini bassi sembrano essere ok. ADT afferma effettivamente

I nomi delle risorse basate su file devono contenere solo az minuscole, 0-9 o _.

Qualcosa che mi ha fatto inciampare all'inizio è stata la mancanza di spazi dei nomi con gli ID, ma questo può generalmente essere ignorato se hai due ID lo stesso Android riutilizzerà solo l'ID definito.

Per gli id ​​utilizzo un qualificatore di 3 lettere seguito da ciò a cui si riferisce nella notazione cammello, ad esempio lblFoo per un'etichetta di testo statica (o textview), txtFoo per una casella di testo modificabile (edittext in Android). All'inizio può sembrare strano, ma lo uso da VB6 e quei controlli erano chiamati etichetta e casella di testo.

Eccone altri che uso comunemente:

• btnFoo - pulsante
• pwdFoo - password
• lstFoo - list
• clrFoo - colore
• tblFoo - tavolo
• colFoo - colonna
• rowFoo - fila
• imgFoo - immagine
• dimFoo - dimensione
• padFoo - imbottitura
• mrgFoo - margin

Uso lo stesso nel codice anche all'interno del file java, quindi non devo pensarci, l'ambito del pacchetto lo consentirà abbastanza felicemente:

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

Potresti, se preferisci, aggiungere un po 'di spaziatura usando il carattere di sottolineatura, cioè btn_foo ... Probabilmente lo farei se potessi rompere le vecchie abitudini.

C'è chi potrebbe sostenere che abbreviarli potrebbe non essere l'ideale e i puristi sosterrebbero che dovrebbe essere usato il nome completo, ma quando si nominano dozzine di controlli e si cambia tra diversi sistemi e framework, i nomi completi perdono il loro significato, io li ho usati per oltre un decennio in VB, C ++, ASP.NET, WinForms in C # e VB.NET, Android e Python. Non ho mai bisogno di ricordare se Android lo chiama una casella di testo o un edittext. Tutto quello che devo sapere è che lblFoo è l'etichetta statica e txtFoo è ciò in cui l'utente digita l'input.

Un'ultima nota è che non importa quale convenzione tu decida sulle cose importanti è nominare i controlli in modo appropriato e coerente, in modo da non lottare con vaghi ID predefiniti, ad esempio TextView5 o un misto di convenzioni diverse

Link utile per designer e sviluppatori - qui

Dimensioni e dimensioni, convenzioni di denominazione, stili e temi, nove patch e così via.

Non credo ci sia alcuna convenzione standard promossa da Google. Ho visto tutti i tipi di modi diversi in cui le persone nominano le cose, anche all'interno di diverse app ufficiali di Google.

Qualunque cosa ti aiuti di più quando cerchi di dare un senso a 100 file di layout (o disegnabili, menu, ecc.) In una gerarchia di directory.

Una risposta breve: se desideri imparare dagli sviluppatori Android, un buon esempio è la libreria di supporto v7 ( https://dl-ssl.google.com/android/repository/support_r21.zip )

Altrimenti, ecco cosa ho considerato per denominare le risorse:
1. trovare facilmente le risorse durante la scrittura del codice
2. comprendere facilmente le risorse durante la lettura del codice
3. rendere i nomi utili per i traduttori ( R.string.*solo risorse)
4. riutilizzare i layout con <include/>( R.id.*conflitti di risorse)
5. trattare con progetti di biblioteca

Logicamente, la disposizione delle risorse non dovrebbe essere diversa dal raggruppamento di classi Java in pacchetti (o l'inserimento di file in cartelle). Tuttavia, poiché le risorse Android non hanno spazi dei nomi, è necessario aggiungere prefissi al nome della risorsa per ottenere lo stesso risultato (ad esempio, com.example.myapp.photodiventacom_example_myapp_photo ).

Suggerisco di dividere l'app in componenti separati (attività, frammenti, dialoghi, ecc.) Con nomi brevi univoci che possono essere utilizzati come prefissi di risorse. In questo modo stiamo raggruppando le risorse con le relative funzionalità insieme, il che le rende facili da trovare (punto 1) e allo stesso tempo evitiamo conflitti di denominazione sia con i <include/>progetti di libreria (punti 4 e 5). Tieni presente che le risorse comuni a più componenti possono comunque avere un prefisso (comeR.string.myapp_ok_button ).

Dopo il prefisso, il nome dovrebbe dirci per cosa viene utilizzata la risorsa (azione da eseguire, contenuto da visualizzare, ecc.). La scelta di un buon nome è importante per la comprensione (punti 2 e 3).

A volte "nome_componente" ci fornirà informazioni sufficienti, il che è particolarmente vero se il tipo è già fornito dalla classe R (nella R.string.myapp_name_stringseconda "stringa" è ridondante). Tuttavia, l'aggiunta di un tipo esplicito può migliorare la comprensione (ad esempio, può essere utile per i traduttori distinguere tra un brindisi o un'etichetta). A volte le parti "nome" e "tipo" possono essere scambiate per consentire il filtraggio basato sul tipo (R.string.photo_menu_* ci fornirà solo voci relative al menu per il componente foto).

Supponiamo che stiamo scrivendo un'attività per scattare foto, classe com.example.myapp.photo .PhotoActivity. Le nostre risorse potrebbero assomigliare a questa (raggruppate per il componente "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  

Se curiosate nella documentazione di Android, ci sono varie menzioni di "best practice", ma non ci sono certamente regole concrete. Ad esempio, in Icon Design Guidelines , Google suggerisce di denominare le icone con un prefisso "ic_".

Un buon punto di partenza potrebbe essere fornire risorse .

Cerca anche nei sorgenti / esempi dell'SDK e nel blog degli sviluppatori Android se vuoi vedere come fanno le cose gli sviluppatori di Google.

Ho trovato utile la prossima convenzione di denominazione per le stringhe:

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

Ad esempio, clear_playlist_text, delete_song_message, update_playlist_positivebutton_text. E "azione" qui è facoltativa.

puoi leggere la documentazione di Google per lo stile del codice per avere un'idea qui

In genere ho seguito le convenzioni di denominazione java per gli ID delle risorse (non per i file per i file) tranne per aver aggiunto "x" davanti agli ID, ad esempio:

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

In java possiamo usarlo semplice (possiamo anche ricordarlo in modo semplice)

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

Qui mTvName (è in generale le convenzioni di denominazione suggerite da Android) e xTvName che è stato nominato nel file di layout come parte dell'ID di TextView di Android (x significa XML), ho seguito questo tipo di convenzioni di denominazione per gli oggetti di visualizzazione come pulsanti e EditText ecc.

in XML IDS: xViewTypeSpecificName

in Java: mViewTypeSpeficName

Le convenzioni di cui sopra mi semplificano la vita quando creo layout complessi. Cerca solo di rendere i tuoi nomi il più brevi possibile ed è meglio se sono comprensibili e significativi per altri co-sviluppatori (ma potrebbe non essere possibile ogni volta), Spero che la mia esperienza possa aiutare gli altri, i suggerimenti sono ben accetti.

Nei nostri progetti Android ci sono molti componenti come pulsanti, etichette, caselle di testo. Quindi un nome semplice come ad esempio "nome" è molto confuso identificare "nome" come etichetta o casella di testo. Principalmente accade quando si mantengono progetti sviluppati da altri sviluppatori.

Quindi, per evitare questo tipo di confusione, ho usato i seguenti nomi per i pulsanti TextBoxes o Labels

Esempio :

 btnName
 labName
 txtName
 listName

Può essere utile per te.

Ci sono alcune limitazioni:

1. Il nome della risorsa deve contenere az, 0-9, _
2. Il nome della risorsa dovrebbe iniziare con az, _

A proposito, è più consigliabile seguire le linee guida o imparare dal codice standard.