Существуют ли соглашения о том, как назвать ресурсы в Android? Например, кнопки, текстовые элементы, меню и т.д.
Существуют ли соглашения о том, как назвать ресурсы?
Ответ 1
Я не знаю, есть ли какие-либо официальные рекомендации.
Для идентификаторов в моих макетах с виджетами и контейнерами я использую соглашение:
<layout>_<widget/container>_<name>
Я делаю ту же самую стратегию для любых размеров, строк, чисел и цветов, которые я использую в этих макетах. Однако я пытаюсь обобщить. например, если все кнопки имеют общий textColor, я не буду префикс имени с макетом. Имя ресурса будет "button_textColor". Если все textColors используют один и тот же ресурс, он будет называться "textColor". Для стилей это обычно так же.
Для ресурсов меню я использую:
menu_<activity>_<name>
Анимация отличается только тем, что вы не можете использовать заглавные буквы. Я думаю, что это тоже относится к ресурсам xml.
Ответ 2
Android SDK будет хорошим местом для начала.
Например, я пытаюсь использовать идентификаторы области видимости в действии.
Если бы у меня был ListView, он просто был бы @android:id/list во всех действиях.
Если бы у меня было два списка, я бы использовал более конкретные @id/list_apple и @id/list_orange
Таким образом, общий (ids,...) повторно используется в R.java file, в то время как уникальные (иногда используемые повторно) получают префикс с общими , разделенными символом подчеркивания.
Подчеркивание - это одно, я заметил, например:
Ширина макета layout_width в xml и layoutWidth в коде, поэтому я стараюсь придерживаться ее как list_apple
Таким образом, кнопка Login будет login, но , если у нас есть два входа, затем login_foo и login_bar.
Ответ 3
Взято из Документация для Android. В этом вопросе есть еще больше.
Ответ 4
В ресурсах используется несколько соглашений:
- Для ресурсов, которые существуют как отдельные файлы, они должны быть 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_), все выделенные элементы выделяются underscore_separated и т.д.
Ответ 5
Чтобы ответить на ваш вопрос: Да, есть.
Вы можете найти многие из них, например, через google search. И нет такого понятия, как наилучшее соглашение об именах. Это всегда зависит от ваших потребностей и ваших атрибутов проекта (что наиболее важно для области).
Недавно я прочитал неплохое сообщение Идентификация обложек имен файлов Android:
Затем он подробно описывает каждый элемент и каждый тип ресурса.
Я бы сказал, что вы можете использовать это соглашение от небольших и средних проектов (личное использование, несколько месяцев контрактных приложений). Хотя, я бы не рекомендовал его для проектов на длительный срок, например, 50+ видов деятельности или 1000+ строк.
Соглашения о значениях ресурсов в проектах такого масштаба требуют большего изучения того, как они будут использоваться. Возьмите строки, например. Может быть затронут размер вашей команды, центр перевода, который вы используете (если есть), VCS, который вы используете (например, чтобы избежать конфликтов слияния) и т.д. Возможно, вы даже подумаете о разделении строк на несколько файлов.
Я предполагаю, что вы ищете что-то для начала. Поэтому я бы рекомендовал сообщение в блоге, о котором я упоминал. Это хорошо для начинающих, и вы можете определенно использовать его в качестве вдохновения для создания хороших соглашений об именах.
Также имейте в виду, что по мере роста проекта многие потребности и требования могут со временем меняться. Поэтому вполне нормально, что соглашения об именах, которые были подходящими в начале, не будут подходящими через 2 года. И это совершенно нормально. Вы не должны пытаться предсказать будущее. Просто выберите конвенцию и следуйте ей. Вы найдете, подходит ли он вам и вашему проекту. Если его нет, подумайте, почему он не подходит и начнет использовать что-то еще.
Ответ 6
Это обычная проблема для любого языка или фреймворка, но пока вы избегаете зарезервированных слов, вы должны быть уверены, что можете вспомнить, что вы назвали.
Я заметил, что Android накладывает ограничение на имена файлов ресурсов xml, но подчеркивания кажутся ок. ADT фактически утверждает
Имена файлов на основе файлов должны содержать только строчные буквы a-z, 0-9 или _.
Что-то, что меня сначала сбило с толку, было отсутствие пространств имен с идентификаторами, но это, как правило, можно игнорировать, если у вас есть два id, тот же Android будет просто повторно использовать определенный идентификатор.
Для id я использую трехбуквенный классификатор, за которым следует то, что он обозначает в верблюжьей нотации, например lblFoo для статической текстовой метки (или текстового), txtFoo для редактируемого текстового поля (edittext в Android). Сначала это может показаться странным, но я использовал его с VB6, и эти элементы управления назывались ярлыком и текстовым полем.
Вот некоторые из них, которые я обычно использую:
- btnFoo - кнопка
- pwdFoo - пароль
- lstFoo - list
- clrFoo - цвет
- tblFoo - таблица
- colFoo - column
- rowFoo - строка
- imgFoo - изображение
- dimFoo - размер
- padFoo - padding
- mrgFoo - margin
Я использую то же самое в коде в java файле, поэтому мне не нужно об этом думать, объем пакета позволит это довольно счастливо:
Button btnFoo = (Button)findViewById(R.id.btnFoo);
Если бы вы предпочли добавить небольшое расстояние, используя символ подчеркивания i.e btn_foo... Я бы, наверное, сделал бы это, если бы смог сломать старые привычки.
Есть те, кто может утверждать, что аббревиатура этих может быть не идеальной, и пуристы будут утверждать, что полное имя должно использоваться, но когда вы называете десятки элементов управления и меняетесь между различными системами и структурами, полные имена теряют значения, я использовал их более десяти лет в VB, С++, ASP.NET, WinForms на С# и VB.NET, Android и Python. Мне никогда не нужно запоминать, будет ли Android называть его текстовым полем или редактором. Все, что мне нужно знать, это то, что lblFoo - это статическая метка, а txtFoo - это то, что вводит пользователь.
В заключение отметим, что независимо от того, какое соглашение вы принимаете в отношении важных вещей, это правильное и последовательное определение элементов управления, чтобы вы не боролись с неопределенным значением по умолчанию, например, TextView5 или смесью различных соглашений
Ответ 7
Я не думаю, что существует стандартная конвенция, продвигаемая Google. Я видел разные способы, которыми люди называют материал, даже в разных официальных приложениях Google.
Независимо от того, что вам больше всего помогает, пытаясь понять 100 макетов (или чертежей, меню и т.д.) файлов в одной иерархии каталогов.
Ответ 8
Полезная ссылка для дизайнера и разработчиков - здесь
Размеры и размеры, соглашения об именах, стили и темы, девять патчей и т.д.
Ответ 9
Если вы соскучились в документации по Android, есть различные упоминания о "лучших практиках", но, безусловно, нет конкретных правил. Например, в Правилах создания значков, Google предлагает именовать значки с префиксом "ic_".
Хорошим местом для начала может быть Предоставление ресурсов.
Также вы можете найти в источнике SDK/примерах, а также в Блог разработчиков Android, если вы хотите увидеть, как разработчики Google делают что-то.
Ответ 10
Короткий ответ: если вы хотите учиться у разработчиков 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).
Иногда "имя_компьютера" дает нам достаточно информации, что особенно верно, если тип уже задан классом R (в R.string.myapp_name_string вторая строка "является избыточной" ). Однако явно добавляющий тип может улучшить понимание (например, для переводчиков может быть полезно различать тост или метку). Иногда части "имя" и "тип" можно поменять местами, чтобы разрешить фильтрацию на основе типов (R.string.photo_menu_* предоставит нам только элементы, связанные с меню для компонента фотографии).
Скажем, мы пишем действие для съемки, класс 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
Ответ 11
Я нашел удобное следующее соглашение об именах для строк:
[<action>]_<object>_<purpose>
Например, clear_playlist_text, delete_song_message, update_playlist_positivebutton_text. И "действие" здесь необязательно.
Ответ 12
вы можете прочитать документацию google для стиля кода, чтобы получить представление здесь
Ответ 13
Я обычно следил за соглашениями об именах java для идентификаторов ресурсов (а не для файлов для файлов), за исключением того, что я добавил "x" перед идентификаторами, например:
<TextView android:id="@+id/xTvName" android:layout_width="wrap_content" android:layout_height="wrap_content"></TextView>
В java мы можем использовать его просто (мы также можем запомнить просто)
TextView mTvName=(TextView)findViewById(R.id.xTvName);
Здесь mTvName (в общем, предлагаемые соглашения об именах для android) и xTvName, которые были названы в файле макета как часть идентификатора TextView Android (x для XML), я придерживался такого типа соглашений об именах для объектов вида, таких как кнопки и EditText и т.д.
в XML IDS: xViewTypeSpecificName
в Java: mViewTypeSpeficName
Вышеупомянутые соглашения облегчают мою жизнь, когда я создаю сложные макеты. Просто попробуйте сделать ваши имена максимально короткими, и лучше, если они понятны и значимы для других со-разработчиков (но это может быть невозможно каждый раз). Надеюсь, что мой опыт поможет другим, предложения приветствуются.
Ответ 14
В наших проектах Android есть много компонентов, таких как кнопки, ярлыки, текстовые поля. Так простое имя, например, "имя", это очень запутывает, чтобы идентифицировать "имя" - это метка или текстовое поле. В основном это происходит, когда вы поддерживаете проекты, разработанные некоторыми другими разработчиками.
Итак, чтобы избежать такого путаницы, я использовал следующие названия для кнопок TextBoxes или Labels
Пример:
btnName
labName
txtName
listName
Может быть, это полезно для вас.
Ответ 15
Существуют некоторые ограничения:
- Имя ресурса должно содержать a-z, 0-9, _
- Имя ресурса должно начинаться с a-z, _
Кстати, более целесообразно следовать рекомендациям или учиться на стандартном коде.