Чи є угоди про те, як називати ресурси?

Чи є умови, як називати ресурси в 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

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

Підкреслення - це одне, що я помітив, наприклад:

Ширина макета layout_widthв xml та layoutWidthв коді , тому я намагаюся дотримуватися її якlist_apple

Отже, кнопка для входу буде login, але якщо у нас два входи, то login_fooі login_bar.

Взяте з документації на Android . Існує більше на тему.

Щоб відповісти на ваше запитання: Так, є.

Наприклад, багато з них можна знайти за допомогою google search . І немає такої речі, як найкраща конвенція про іменування. Це завжди залежить від ваших потреб та атрибутів вашого проекту (головне - сфери).

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

Потім він детально описує кожен елемент та кожен тип ресурсу.

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

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

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

Також майте на увазі, що в міру зростання проекту багато потреб і вимог можуть змінюватися в часі. Тож цілком нормально, що конвенції про іменування, які були придатні на початку, не підходять через 2 роки. І це зовсім чудово. Не слід намагатися передбачити майбутнє. Просто виберіть конвенцію і дотримуйтесь її. Ви дізнаєтесь, чи підходить він вам і вашому проекту. Якщо її немає, подумайте, чому це не підходить, і почніть використовувати щось інше.

У ресурсах є кілька умов:

• Для ресурсів, які існують як окремі файли, вони повинні бути відокремлені нижньою коробкою_underscore_sepse. Інструмент appt гарантує, що ваші файли мають лише малі регістри, оскільки використання змішаного регістру може спричинити проблеми у файлових системах, що не враховують регістр.
• Для ресурсів, задекларованих лише у значеннях / ... (атрибути, рядки тощо), звичайно, змішанаCase.
• Існує умова, яка іноді використовується для тегування імен з "класифікацією", щоб мати прості простори імен. Це, наприклад, де ви бачите такі речі, як layout_width та layout_alignLeft. У файлі макета атрибути як для представлення, так і для батьківського макета управління змішуються разом, навіть якщо вони різні власники. Конвенція "layout_ *" забезпечує відсутність конфліктів між цими іменами, і легко зрозуміти, яка сутність впливає на ім'я.

Ця конвенція "layout_blah" також використовувалася в кількох інших місцях. Наприклад, є атрибути "state_blah", які є перехідними станами, які може мати вид.

Також через ці дві конвенції (underscore_separated для файлів, змішанийCase для оголошених ресурсів) ви знайдете ряд невідповідностей. Наприклад, кольори можуть бути оголошені або з файлами, або як явні значення. Як правило, ми хотіли б дотримуватися підкресленого_секретування для всіх цих, але це не завжди буває.

Зрештою, ми не дуже хвилюємось щодо називання конвенцій для ресурсів. Найбільший, який ми дотримуємося, - це "змішане" для атрибутів і використання "layout_blah" для ідентифікації атрибутів парами макета.

Також перегляд публічних ресурсів тут повинен добре відчувати конвенції:

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

Ви побачите, що всі атрибути цілком узгоджуються (якщо ви розумієте конвенцію макета_), всі малюнки - всі підкреслені_ розділені тощо.

Це загальна проблема для будь-якої мови чи основи, але поки ви уникаєте зарезервованих слів, вам слід бути гаразд, припускаючи, що ви можете запам'ятати те, що ви називали.

Я помітив, що Android розміщує рецензію на імена файлів ресурсів xml, але підкреслення, здається, нормально. ADT фактично констатує

Імена ресурсів на основі файлів повинні містити лише малі літери az, 0-9 або _.

Щось, що спонукало мене спочатку, - це відсутність просторів імен з ідентифікаторами, але це, як правило, можна ігнорувати, якщо у вас два ідентичні ідентичні Android, вони просто використовуватимуть визначений ідентифікатор.

Для ідентифікаторів я використовую 3-літерний класифікатор з подальшим описом на позначення верблюда, наприклад lblFoo для статичної текстової мітки (або перегляду тексту), txtFoo для редагованого текстового поля (редагування тексту в Android). Спочатку це може здатися дивним, але я використовую його з VB6, і ці елементи управління називаються мітками та текстовими полями.

Ось ще декілька я зазвичай використовую:

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

Я використовую те саме в коді у файлі java, тому мені не доводиться думати про це, обсяг пакету дозволить це досить щасливо:

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

Ви можете, якщо ви віддаєте перевагу додати невеликий пробіл, використовуючи підкреслення, тобто btn_foo ... Я, мабуть, зробив би це, якби я міг порушити старі звички.

Є ті, хто може стверджувати, що скорочення цих можливостей не є ідеальним, і пуристи будуть стверджувати, що слід використовувати повне ім'я, але коли ви називаєте десятки елементів керування та змінюєтесь між різними системами та рамками, повні назви втрачають значення, я використовували їх уже понад десятиліття у 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_string2-му "рядку" є зайвим). Однак явне додавання типу може покращити розуміння (наприклад, перекладачам може бути корисно розрізнити тост або етикетку). Іноді частини "ім'я" та "тип" можуть бути замінені, щоб дозволити фільтрування на основі типу ( 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 (Це загалом для андроїд запропоновано конвенції іменування) та xTvName, які були названі у файлі компонування як частина id android TextView (x означає для XML), я дотримувався цього типу конвенцій іменування для об'єктів перегляду, таких як Buttons та EditText і т.д.

в XML IDS: xViewTypeSpecificName

на Java: mViewTypeSpeficName

Вищезазначені конвенції полегшують моє життя, коли я створюю складні плани. Просто спробуйте зробити свої імена максимально короткими за довжиною, і краще, якщо вони будуть зрозумілі та значущі для інших співавторів (але це може бути неможливо кожен раз), сподіваюся, що мій досвід допоможе іншим, пропозиції вітаються.

У наших андроїд-проектах є безліч компонентів, таких як кнопки, мітки, текстові поля. Настільки проста назва, як, наприклад, "ім'я", це дуже заплутано для визначення "ім'я" - це мітка або текстове поле. В основному це відбувається, коли ви підтримуєте проекти, розроблені іншими розробниками.

Щоб уникнути подібної плутанини, я використовував наступні імена для Buttons TextBoxes або Labels

Приклад:

 btnName
 labName
 txtName
 listName

Можливо, це вам корисно.

Існують деякі обмеження:

1. Назва ресурсу повинна містити az, 0-9, _
2. Назва ресурсу повинна починатися з az, _

До речі, доцільніше дотримуватися вказівок або вчитися зі стандартного коду.