Existem convenções sobre como nomear recursos no Android? Por exemplo, botões, textViews, menus, etc.
Respostas:
Não sei se existem recomendações oficiais.
Para ids em meus layouts com widgets e contêineres, uso a convenção:
<layout>_<widget/container>_<name>Eu faço a mesma estratégia para quaisquer dimensões, strings, números e cores que uso nesses layouts. No entanto, tento generalizar. por exemplo, se todos os botões têm uma textColor comum, não vou prefixar o nome com o layout. O nome do recurso seria 'button_textColor'. Se todos os textColors estiverem usando o mesmo recurso, ele será nomeado 'textColor'. Para Estilos, esse geralmente é o caso também.
Para recursos de menu eu uso:
menu_<activity>_<name>As animações são apenas diferentes porque você não pode usar letras maiúsculas. O mesmo vale para recursos xml drawable, acredito.
O Android SDK será um bom lugar para começar.
Por exemplo, tento definir o escopo de IDs dentro da atividade.
Se eu tivesse ListView, simplesmente estaria @android:id/listem todas as atividades.
Se, no entanto, eu tivesse duas listas, usaria a mais específica @id/list_applee@id/list_orange
Assim, os genéricos (ids, ...) são reutilizados R.java fileenquanto os únicos (às vezes são reutilizados) são prefixados com os genéricos separados por um sublinhado .
O sublinhado é uma coisa, observei, por exemplo:
A largura do layout está layout_widthem xml e layoutWidthem código , então tento mantê-la comolist_apple
Portanto, um botão de Login será login, mas se tivermos dois logins, então login_fooe login_bar.
Retirado da documentação do Android . Há mais informações sobre o assunto.
Para responder à sua pergunta: Sim, existem.
Você pode encontrar muitos deles através da pesquisa do google, por exemplo. E não existe a melhor convenção de nomenclatura. Sempre depende das suas necessidades e dos atributos do seu projeto (mais importante, o escopo).
Recentemente, li uma postagem de blog muito boa sobre como nomear recursos no Android XML de Jeroen Mols. O autor menciona o princípio básico que todos os recursos devem seguir e como essa convenção é aplicada a cada tipo de recurso. Ambos descritos na folha de dicas de nomenclatura de recursos do Android :
Ele então descreve cada elemento e cada tipo de recurso em detalhes.
Eu diria que você poderia usar essa convenção em projetos de pequeno a médio porte (uso pessoal, inscrições de contratos de alguns meses). Embora eu não o recomende para projetos de longa data com mais de 50 atividades ou mais de 1000 strings.
Convenções para valores de recursos em projetos de grande escala requerem mais investigação sobre como eles serão usados. Pegue strings, por exemplo. Pode ser afetado pelo tamanho da sua equipe, centro de tradução que você está usando (se houver), VCS que você está usando (para evitar conflitos de fusão, por exemplo), etc. Você pode até pensar em dividir as strings em vários arquivos.
Suponho que você esteja procurando algo para começar. Então, eu recomendaria a postagem do blog que mencionei. É bom para começar e você pode definitivamente usá-lo como inspiração para criar suas próprias convenções de nomenclatura.
Lembre-se também de que, à medida que um projeto cresce, muitas necessidades e requisitos podem mudar com o tempo. Portanto, é completamente normal que as convenções de nomenclatura que eram adequadas no início não sejam adequadas após 2 anos. E está tudo bem. Você não deve tentar prever o futuro. Basta escolher uma convenção e segui-la. Você descobrirá se é adequado para você e seu projeto. Se não for, pense por que não é adequado e comece a usar outra coisa.
Existem algumas convenções usadas em recursos:
Essa convenção "layout_blah" também foi usada em alguns outros lugares. Por exemplo, existem atributos "state_blah" que são os estados drawable que uma vista pode ter.
Além disso, por causa dessas duas convenções (underscore_separated para arquivos, mixedCase para recursos declarados), você encontrará várias inconsistências. Por exemplo, as cores podem ser declaradas com arquivos ou como valores explícitos. Geralmente, gostaríamos de usar underscore_separated para todos eles, mas isso nem sempre acontece.
Em última análise, não nos preocupamos muito com convenções de nomenclatura para recursos. O principal que mantemos consistente é "mixedCase" para atributos e o uso de "layout_blah" para identificar atributos de parâmetros de layout.
Além disso, navegar pelos recursos públicos aqui deve dar uma boa ideia das convenções:
http://developer.android.com/reference/android/R.html
Você verá que os atributos são todos bastante consistentes (desde que você entenda a convenção layout_), os drawables são todos underscore_separated, etc.
Este é um problema comum a qualquer linguagem ou estrutura, mas contanto que você evite palavras reservadas, você deve estar bem, presumindo que pode se lembrar do que chamou as coisas.
Eu observei que o Android restringe os nomes dos arquivos de recursos xml, mas os sublinhados parecem estar ok. ADT realmente afirma
Os nomes de recursos baseados em arquivo devem conter apenas az minúsculo, 0-9 ou _.
Algo que me incomodou no início foi a falta de namespaces com id's, mas isso geralmente pode ser ignorado se você tiver dois id's, o mesmo Android irá apenas reutilizar o id definido.
Para id's, eu uso um qualificador de 3 letras seguido pelo que ele se refere em notação de camelo, por exemplo, lblFoo para um rótulo de texto estático (ou textview), txtFoo para uma caixa de texto editável (editar texto no Android). Pode parecer estranho no início, mas tenho usado desde o VB6 e esses controles eram chamados de rótulo e caixa de texto.
Aqui estão mais alguns que costumo usar:
Eu uso o mesmo no código dentro do arquivo java, então não tenho que pensar sobre isso, o escopo do pacote permitirá isso perfeitamente:
Button btnFoo = (Button)findViewById(R.id.btnFoo);Você poderia, se preferir, adicionar um pouco de espaçamento usando sublinhado, ou seja, btn_foo ... Eu provavelmente faria isso se pudesse quebrar velhos hábitos.
Alguns podem argumentar que abreviá-los pode não ser o ideal e os puristas argumentariam que o nome completo deveria ser usado, mas quando você está nomeando dezenas de controles e mudando entre diferentes sistemas e estruturas, os nomes completos perdem seus significados, I usei-os por mais de uma década em VB, C ++, ASP.NET, WinForms em C # e VB.NET, Android e Python. Nunca preciso lembrar se o Android chama de caixa de texto ou texto de edição. Tudo que eu preciso saber é que lblFoo é o rótulo estático e txtFoo é o que o usuário digita.
Uma observação final é que não importa a convenção que você decida sobre as coisas importantes, é nomear os controles de forma adequada e consistente, para que você não lute com ids padrão vagos, por exemplo, TextView5 ou uma mistura de convenções diferentes
Não acho que haja uma convenção padrão promovida pelo Google. Já vi todos os tipos de maneiras diferentes de as pessoas darem nomes às coisas, mesmo em diferentes aplicativos oficiais do Google.
O que mais te ajudar ao tentar entender um layout de 100 arquivos (ou drawables, menus, etc.) em uma hierarquia de diretório.
Uma resposta curta: se você gostaria de aprender com os desenvolvedores Android, um bom exemplo é a biblioteca de suporte v7 ( https://dl-ssl.google.com/android/repository/support_r21.zip )
Caso contrário, aqui está o que considerei para nomear recursos:
1. encontrar recursos facilmente ao escrever o código
2. compreender os recursos facilmente ao ler o código
3. tornar os nomes úteis para tradutores ( R.string.*apenas recursos)
4. reutilizar layouts com <include/>( R.id.*conflitos de recursos)
5. lidar com projetos de biblioteca
Logicamente, organizar recursos não deve ser diferente de agrupar classes java em pacotes (ou colocar arquivos em pastas). No entanto, como os recursos do Android não têm namespaces, prefixos devem ser adicionados ao nome do recurso para obter o mesmo (por exemplo, com.example.myapp.phototorna-se com_example_myapp_photo).
Sugiro dividir o aplicativo em componentes separados (atividades, fragmentos, diálogos, etc.) com nomes curtos exclusivos que podem ser usados como prefixos de recursos. Desta forma, estamos agrupando recursos com funcionalidades relacionadas, o que os torna fáceis de encontrar (ponto 1) e estamos ao mesmo tempo evitando conflitos de nomenclatura com ambos <include/>e projetos de biblioteca (pontos 4 e 5). Observe que os recursos comuns a vários componentes ainda podem ter um prefixo (como R.string.myapp_ok_button).
Após o prefixo, o nome deve nos informar para que serve o recurso (ação a ser executada, conteúdo a ser exibido, etc.). A escolha de um bom nome é importante para a compreensão (pontos 2 e 3).
Às vezes, "component_name" nos dará informações suficientes, o que é especialmente verdadeiro se o tipo já for fornecido pela classe R (na R.string.myapp_name_string2ª "string" é redundante). No entanto, adicionar explicitamente o tipo pode melhorar a compreensão (por exemplo, pode ser útil para os tradutores distinguir entre um brinde ou um rótulo). Às vezes, as partes "nome" e "tipo" podem ser trocadas para permitir a filtragem baseada em tipo ( R.string.photo_menu_*nos dará apenas itens relacionados ao menu para o componente de foto).
Digamos que estejamos escrevendo uma atividade para tirar fotos, classe com.example.myapp.photo .PhotoActivity. Nossos recursos podem ser assim (agrupados pelo 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 você vasculhar a documentação do Android, verá várias menções às "melhores práticas", mas certamente não existem regras concretas. Por exemplo, nas Diretrizes de design de ícones , o Google sugere nomes de ícones com um prefixo "ic_".
Um bom lugar para começar pode ser fornecendo recursos .
Pesquise também na fonte / exemplos do SDK, bem como no Android Developers Blog, se quiser ver como os desenvolvedores do Google fazem as coisas.
Achei útil a próxima convenção de nomenclatura para strings:
[<action>]_<object>_<purpose>Por exemplo, clear_playlist_text, delete_song_message, update_playlist_positivebutton_text. E "ação" aqui é opcional.
você pode ler a documentação do google sobre estilo de código para ter uma ideia aqui
Eu geralmente segui as convenções de nomenclatura java para ids de recursos (não para arquivos de arquivos), exceto que adicionei "x" na frente dos ids, por exemplo:
<TextView android:id="@+id/xTvName" android:layout_width="wrap_content" android:layout_height="wrap_content"></TextView>Em java, podemos usá-lo simples (também podemos lembrar em simples)
TextView mTvName=(TextView)findViewById(R.id.xTvName);Aqui mTvName (em geral são convenções de nomenclatura sugeridas pelo Android) e xTvName, que foi nomeado no arquivo de layout como parte do Id do Android TextView (x destinado a XML), segui esse tipo de convenção de nomenclatura para objetos de visualização, como Botões e EditText etc.
em XML IDS: xViewTypeSpecificName
em Java: mViewTypeSpeficName
As convenções acima facilitam minha vida quando crio layouts complexos. Tente fazer com que seus nomes sejam o mais curtos possível e é melhor se eles forem compreensíveis e significativos para outros co-desenvolvedores (mas nem sempre é possível). Espero que minha experiência ajude outras pessoas, sugestões são bem-vindas.
Em nossos projetos Android, existem muitos componentes como botões, rótulos, caixas de texto. Um nome tão simples, como por exemplo "nome", é muito confuso identificar "nome" como rótulo ou caixa de texto. Isso acontece principalmente quando você mantém projetos desenvolvidos por outros desenvolvedores.
Então, para evitar esse tipo de confusão, usei os seguintes nomes para os botões TextBoxes ou Labels
Exemplo:
btnName
labName
txtName
listNamePode ser útil para você.
Existem algumas restrições:
A propósito, é mais aconselhável seguir as diretrizes ou aprender com o código padrão.