Есть ли соглашения о том, как называть ресурсы?

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

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

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

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

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

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

menu_<activity>_<name>

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

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.

Взято из документации Android . По этому поводу есть больше.

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

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

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

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

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

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

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

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

В ресурсах используется несколько соглашений:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я использую то же самое в коде в java-файле, поэтому мне не нужно об этом думать, объем пакета позволит это вполне успешно:

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

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

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

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

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

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

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

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

Короткий ответ: если вы хотите поучиться у разработчиков 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  

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

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

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

Я нашел удобное следующее соглашение об именах для строк:

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

Например, clear_playlist_text, delete_song_message, update_playlist_positivebutton_text. И «действие» здесь необязательно.

вы можете прочитать документацию Google по стилю кода, чтобы получить представление здесь

Я обычно следовал соглашениям об именах 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, который был назван в файле макета как часть идентификатора Android TextView (x предназначен для XML), я следовал этому типу соглашений об именах для объектов просмотра, таких как кнопки и EditText и т. Д.

в XML IDS: xViewTypeSpecificName

в Java: mViewTypeSpeficName

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

В наших проектах для Android есть множество компонентов, таких как кнопки, метки, текстовые поля. Такое простое имя, как, например, «имя», очень сложно определить, что «имя» - это метка или текстовое поле. В основном это происходит, когда вы поддерживаете проекты, разработанные другими разработчиками.

Чтобы избежать такой путаницы, я использовал следующие имена для текстовых полей кнопок или меток.

Пример :

 btnName
 labName
 txtName
 listName

Может быть, это будет полезно для вас.

Есть некоторые ограничения:

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

Кстати, желательно следовать рекомендациям или учиться на стандартном коде.