Существуют ли соглашения о том, как называть ресурсы? - PullRequest
96 голосов
/ 23 августа 2011

Есть ли соглашения, как называть ресурсы в Android?Например, кнопки, текстовые представления, меню и т. Д.

Ответы [ 15 ]

43 голосов
/ 29 августа 2011

Android SDK будет хорошим местом для начала.

Например, я пытаюсь охватить идентификаторы внутри действия.

Если бы у меня было ListView, то просто было бы @android:id/list во всех видах деятельности.
Однако, если бы у меня было два списка, я бы использовал более конкретные @id/list_apple и @id/list_orange

Таким образом, общие (ids, ...) повторно используются в R.java file, в то время как уникальные (иногда используются повторно) имеют префикс с общими , разделенными подчеркиванием .


Подчеркивание - это одна вещь, которую я заметил, например:

Ширина макета составляет layout_width в xml и layoutWidth в код , поэтому я стараюсь придерживаться его как list_apple

Таким образом, кнопка входа в систему будет login, но , если у нас будет два логина , тогда login_foo и login_bar.

25 голосов
/ 31 августа 2011

Я не знаю, есть ли какие-либо официальные рекомендации.

Для идентификаторов в моих макетах с виджетами и контейнерами я использую соглашение:

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

Я использую ту же стратегиюдля любых размеров, строк, чисел и цветов, которые я использую в этих макетах.Тем не менее, я пытаюсь обобщить.Например, если все кнопки имеют общий textColor, я не буду префикс имени с макетом.Имя ресурса будет «button_textColor».Если все textColors используют один и тот же ресурс, он будет называться textColor.Для стилей это также обычно так.

Для ресурсов меню я использую:

menu_<activity>_<name>

Анимации отличаются только тем, что вы не можете использовать заглавные буквы.Я полагаю, что то же самое касается и доступных для рисования XML-ресурсов.

23 голосов
/ 02 января 2013

Взято из документации Android .На эту тему есть еще что-то.

15 голосов
/ 05 октября 2016

Чтобы ответить на ваш вопрос: да, есть.

Многие из них можно найти, например, Поиск в Google . И нет такой вещи, как лучшее соглашение об именах. Это всегда зависит от ваших потребностей и атрибутов вашего проекта (главное - от объема).


Недавно я прочитал блог о наименовании ресурсов в Android XML от Jeroen Mols. Автор упоминает основной принцип, которому должны следовать все ресурсы, а затем, как это соглашение применяется к каждому типу ресурсов. Оба описаны в Шпаргалке по именованию ресурсов Android :

Android resource naming cheat sheet

Затем он подробно описывает каждый элемент и каждый тип ресурса.


Я бы сказал, что вы можете использовать это соглашение для небольших и средних проектов (персональное использование, заявки на несколько месяцев). Хотя я не рекомендовал бы это для долгосрочных проектов с более чем 50 активностями или 1000+ строками.

Соглашения о ресурсных ценностях в проектах такого масштаба требуют более тщательного изучения того, как они будут использоваться. Возьмем строки, например. На это может повлиять размер вашей команды, используемый вами центр перевода (если есть), VCS , который вы используете (например, чтобы избежать конфликтов слияния) и т. Д. Вы можете даже подумать о разбиении строк на несколько файлов. .

Полагаю, вы ищете что-то для начала. Поэтому я бы порекомендовал пост в блоге, который я упомянул Это хорошо для начинающих, и вы определенно можете использовать его как источник вдохновения для создания собственных соглашений об именах.

Также имейте в виду, что по мере роста проекта многие потребности и требования могут со временем меняться. Поэтому вполне нормально, что соглашения о присвоении имен, которые были подходящими в начале, не будут подходящими через 2 года. И это совершенно нормально. Вы не должны пытаться предсказать будущее. Просто выберите соглашение и следуйте ему. Вы найдете, подходит ли он для вас и вашего проекта. Если это не так, подумайте, почему он не подходит, и начните использовать что-то еще.

15 голосов
/ 01 сентября 2011

Существует несколько соглашений, используемых в ресурсах:

  • Для ресурсов, которые существуют как отдельные файлы, они должны быть lower_case_underscore_separated.Инструмент appt гарантирует, что ваши файлы имеют только нижний регистр, потому что использование смешанного регистра может вызвать проблемы в файловых системах без учета регистра.
  • Для ресурсов, объявленных только в значениях / ... (атрибуты, строки и т. Д.)обычно это смешанный регистр.
  • Существует соглашение, которое иногда используется для обозначения имен с помощью «классификации» для получения простых пространств имен.Это, например, где вы видите такие вещи, как layout_width и layout_alignLeft.В файле макета атрибуты как для представления, так и для родительского управления макетом смешиваются вместе, даже если они являются разными владельцами.Соглашение "layout_ *" гарантирует, что между этими именами нет конфликтов, и легко понять, на какой объект влияет имя.

Это соглашение "layout_blah" также использовалось в нескольких других местах.,Например, есть атрибуты «state_blah», которые могут быть отображаемыми состояниями, которые может иметь представление.

Также из-за этих двух соглашений (underscore_separated для файлов, mixedCase для объявленных ресурсов) вы найдете ряд несоответствий.Например, цвета могут быть объявлены либо с файлами, либо как явные значения.Как правило, мы хотели бы придерживаться underscore_separated для всех из них, но это не всегда происходит.

В конечном итоге мы не очень беспокоимся о соглашениях по присвоению имен для ресурсов.Важнейшим из тех, что мы поддерживаем согласованно, является «mixedCase» для атрибутов и использование «layout_blah» для идентификации атрибутов параметров макета.

Также просмотр общих ресурсов здесь должен дать хорошее представление о соглашениях:

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

Вы увидите, что все атрибуты достаточно согласованы (если вы понимаете соглашение layout_), все элементы рисования выделены подчеркиванием_ и т. Д.

11 голосов
/ 01 сентября 2011

Это общая проблема для любого языка или фреймворка, но если вы избегаете зарезервированных слов, у вас должно быть все в порядке, если вы помните, что вы называете вещи.

Я заметил, что Android устанавливает ограничениена именах файлов ресурсов XML, но подчеркивания, кажется, в порядке.ADT на самом деле заявляет

Имена файловых ресурсов должны содержать только строчные буквы az, 0-9 или _.

Вначале меня смутило отсутствиепространства имен с идентификаторами, но это, как правило, можно игнорировать, если у вас два идентификатора. Один и тот же Android будет повторно использовать определенный идентификатор.

Для идентификаторов я использую трехбуквенный квалификатор, за которым следует то, на что он ссылается в верблюжьей нотации, например, lblFooдля статической текстовой метки (или textview), txtFoo для редактируемого текстового поля (edittext в Android).Поначалу это может показаться странным, но я использую его с VB6, и эти элементы управления назывались label и textbox.

Вот еще несколько примеров, которые я обычно использую:

  • btnFoo - кнопка
  • pwdFoo - пароль
  • lstFoo - список
  • clrFoo - цвет
  • tblFoo - таблица
  • colFoo - столбец
  • rowFoo - строка
  • imgFoo - изображение
  • dimFoo - размерность
  • padFoo - отступ
  • mrgFoo - поле

Iиспользуйте то же самое в коде внутри java-файла, так что мне не нужно об этом думать, пакетная область позволит это весьма счастливо:

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

Вы можете, если вы предпочитаете добавить небольшой интервал, используя подчеркивание, т.е.btn_foo ... Я бы, наверное, сделал бы это, если бы мог избавиться от старых привычек.

Есть те, кто может утверждать, что их сокращение может быть не идеальным, и пуристы утверждают, что следует использовать полное имя, но когдавы называете десятки элементов управления и переключаетесь между различными системами иrameworks, полные имена теряют свое значение, я использовал их более десяти лет в VB, C ++, ASP.NET, WinForms в C # и VB.NET, Android и Python.Мне никогда не нужно помнить, называет ли это Android текстовым полем или текстом редактирования.Все, что мне нужно знать, - это то, что lblFoo - это статическая метка, а txtFoo - это то, во что вводит пользователь.

И последнее замечание: независимо от того, какое соглашение вы решаете в отношении важных вещей, это правильное и последовательное именование элементов управления,чтобы вы не боролись с расплывчатыми идентификаторами по умолчанию, например TextView5 или смесью различных соглашений

3 голосов
/ 20 марта 2015

Короткий ответ: если вы хотите учиться у разработчиков Android, хорошим примером является библиотека поддержки v7 (https://dl -ssl.google.com / android / repository / support_r21.zip )

В противном случае вот что я рассмотрел для именования ресурсов:
1. легкий поиск ресурсов при написании кода
2. легкое понимание ресурсов при чтении кода
3. создание имен, полезных для переводчиков (R.string.* только ресурсы)
4. повторное использование макетов с <include/> (R.id.* конфликт ресурсов)
5. работа с библиотечными проектами

Логически, расположение ресурсов не должно отличаться от группировки javaзанятия в пакетах (или помещение файлов в папки).Однако, поскольку ресурсы Android не имеют пространств имен, для достижения того же самого имени необходимо добавить префиксы (например, com.example.myapp.photo становится com_example_myapp_photo).

Я предлагаю разделить приложение на отдельные компоненты (действия,фрагменты, диалоги и т. д.) с короткими уникальными именами, которые можно использовать в качестве префиксов ресурсов.Таким образом, мы группируем ресурсы со связанной функциональностью, что облегчает их поиск (пункт 1), и в то же время мы избегаем конфликтов имен как с <include/>, так и с проектами библиотеки (пункты 4 и 5).Обратите внимание, что ресурсы, общие для нескольких компонентов, по-прежнему могут иметь префикс (например, R.string.myapp_ok_button).

После префикса имя должно сообщать нам, для чего используется ресурс (действие, которое должно быть выполнено, содержимое, которое будетотображается и т. д.).Выбор хорошего имени важен для понимания (пункты 2 и 3).

Иногда «component_name» даст нам достаточно информации, что особенно верно, если тип уже задан классом R (в R.string.myapp_name_string).2-я «строка» является избыточной).Однако явное добавление типа может улучшить понимание (например, переводчикам может быть полезно различать тост или метку).Иногда части «name» и «type» можно поменять местами, чтобы разрешить фильтрацию по типу (R.string.photo_menu_* предоставит нам только элементы, относящиеся к меню для компонента photo).

Допустим, мы пишемактивность для фотографирования, класс com.example.myapp.photo .PhotoActivity.Наши ресурсы могут выглядеть так (сгруппированы по компоненту «фото»):

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 голосов
/ 14 мая 2014

Полезная ссылка для дизайнера и разработчиков - здесь

Размеры и размеры, соглашения об именах, стили и темы, девять патчей и так далее.

3 голосов
/ 27 августа 2011

Я не думаю, что существует какое-либо стандартное соглашение, продвигаемое Google. Я видел разные способы, которыми люди называют вещи, даже в разных официальных приложениях Google.

Все, что вам больше всего помогает, когда вы пытаетесь разобраться в 100 файлах макетов (или элементов рисования, меню и т. Д.) В одной иерархии каталогов.

2 голосов
/ 02 сентября 2011

Если вы покопаетесь в документации Android, там будут различные упоминания о «лучших практиках», но конкретных правил нет.Например, в Руководстве по дизайну значков Google предлагает именовать значки с префиксом «ic_».

Хорошее место для начала может быть Предоставление ресурсов .

Также покопайтесь в источнике / примерах SDK, а также в Блоге разработчиков Android , если хотите узнать, как работают разработчики Google.

...