자원의 이름을 지정하는 방법에 대한 규칙이 있습니까?

자원의 이름을 지정하는 방법에 대한 규칙이 있습니까?

---

Android에서 리소스 이름을 지정하는 방법에 대한 규칙이 있습니까? 예를 들어 버튼, textViews, 메뉴 등이 있습니다.

---

공식적인 권고가 있는지 모르겠습니다.

위젯 및 컨테이너가있는 레이아웃의 ID에 대해 규칙을 사용합니다.

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

이러한 레이아웃에서 사용하는 치수, 문자열, 숫자 및 색상에 대해 동일한 전략을 수행합니다. 그러나 나는 일반화를 시도합니다. 예를 들어 모든 버튼에 공통 textColor가있는 경우 이름 앞에 레이아웃을 붙이지 않습니다. 리소스 이름은 'button_textColor'입니다. 모든 textColors가 동일한 리소스를 사용하는 경우 'textColor'라는 이름이 지정됩니다. Styles의 경우 일반적으로 마찬가지입니다.

메뉴 리소스의 경우 다음을 사용합니다.

menu_<activity>_<name>

애니메이션은 대문자를 사용할 수 없기 때문에 다릅니다. 드로어 블 xml 리소스도 마찬가지입니다.

---

Android SDK는 시작하기에 좋은 곳입니다.

예를 들어 활동 내에서 ID 범위를 지정하려고합니다.

내가 가지고 있다면 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 문서 에서 가져 왔습니다 . 주제에 더 많은 것이 있습니다.

---

리소스에 사용되는 몇 가지 규칙이 있습니다.

• 별도의 파일로 존재하는 리소스의 경우 lower_case_underscore_separated 여야합니다. appt 도구는 대소 문자를 혼합하여 사용하면 대소 문자를 구분하지 않는 파일 시스템에서 문제가 발생할 수 있으므로 파일이 소문자로만되어 있는지 확인합니다.
• values ​​/ ... (속성, 문자열 등)로만 선언 된 리소스의 경우 규칙은 일반적으로 mixedCase입니다.
• 때때로 간단한 네임 스페이스를 갖도록 "분류"로 이름에 태그를 지정하는 데 사용되는 규칙이 있습니다. 예를 들어 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 등을 볼 수 있습니다.

---

귀하의 질문에 답하려면 : 예, 있습니다.

예를 들어 Google 검색 을 통해 많은 것을 찾을 수 있습니다 . 그리고 최고의 명명 규칙은 없습니다. 항상 필요와 프로젝트 속성 (가장 중요한 범위)에 따라 다릅니다.

---

최근에 Jeroen Mols에서 Android XML의 리소스 이름 지정에 대한 꽤 좋은 블로그 게시물을 읽었습니다 . 저자는 모든 리소스가 따라야하는 기본 원칙과이 규칙이 각 리소스 유형에 어떻게 적용되는지 언급합니다. 둘 다 Android 리소스 이름 지정 치트 시트 에 설명되어 있습니다 .

그런 다음 각 요소와 각 리소스 유형을 자세히 설명합니다.

---

이 규칙을 중소 규모의 프로젝트 (개인 사용, 몇 달 계약 신청)에서 사용할 수 있습니다. 비록 50 개 이상의 활동이나 1000 개 이상의 문자열이있는 장기간의 프로젝트에는 권장하지 않습니다.

대규모 프로젝트에서 자원 가치에 대한 규칙은 어떻게 사용 될지에 대한 더 많은 조사가 필요합니다. 예를 들어 문자열을 사용하십시오. 팀 규모, 사용중인 번역 센터 (있는 경우), 사용중인 VCS (예 : 병합 충돌 방지) 등에 의해 영향을받을 수 있습니다. 문자열을 여러 파일로 분할하는 것을 고려할 수도 있습니다.

나는 당신이 시작할 무언가를 찾고 있다고 가정합니다. 그래서 제가 언급 한 블로그 게시물을 추천하겠습니다. 초보자에게 유용하며 자신 만의 좋은 명명 규칙을 만들기위한 영감으로 확실히 사용할 수 있습니다.

Also keep in mind that as a project grows, many needs and requirements may change in time. So its completely normal that naming conventions that were suitable in the beginning will not be suitable after 2 years. And it's completely fine. You should not try to predict future. Just choose a convention and follow it. You will find if it is suitable for you and your project. If its not, think about why it is not suitable and start using something else.

---

This is a common problem to any language or framework, but so long as you avoid reserved words you should be ok assuming you can remember what you have called things.

I did note that Android places a restrction on xml resource file names but underscores seem to be ok. ADT actually states

File-based resource names must contain only lowercase a-z, 0-9, or _.

Something that tripped me up at first was a lack of namespaces with id's, but this can generally be ignored if you have two id's the same Android will just reuse the defined id.

For id's I use a 3 letter qualifier followed by what it refers to in camel notation e.g lblFoo for a static text label (or textview), txtFoo for an editable textbox (edittext in Android). This may seem odd at first but I've been using it since VB6 and those controls were called label and textbox.

Here are some more I commonly use:

• btnFoo - button
• pwdFoo - password
• lstFoo - list
• clrFoo - color
• tblFoo - table
• colFoo - column
• rowFoo - row
• imgFoo - image
• dimFoo - dimension
• padFoo - padding
• mrgFoo - margin

I use the same in code within the java file too so I don't have to think about it, package scope will allow this quite happily:

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

You could if you prefer add a little spacing using underscore i.e btn_foo ... I probably would do this if I could break old habits.

There are those who may argue that abbreviating these may not be ideal and the purists would argue that the full name should be used, but when you are naming dozens of controls and changing between different systems and frameworks, the full names lose their meanings, I have used these for over a decade in VB, C++, ASP.NET, WinForms in C# and VB.NET, Android and Python. I never need to remember if Android calls it a textbox or an edittext. All I need to know is that lblFoo is the static label and txtFoo is what the user types input into.

One final note is that no matter what convention you decide upon the important things is naming controls properly and consistently, so that you don't wrestle with vague default id's e.g TextView5 or a mixture of different conventions

---

I don't think there is any standard convention promoted by Google. I've seen all kinds of different ways people name stuff, even within different official Google apps.

Whatever helps you the most when trying to make sense of a 100 layout (or drawables, menus, etc.) files in one directory hierarchy.

---

Useful link for designer and developers - here

Dimensions and sizes, naming conventions, styles and themes, nine-patch and so on.

---

A short answer: if you would like to learn from Android developers, a good example is the support library v7 (https://dl-ssl.google.com/android/repository/support_r21.zip)

Otherwise, here's what I have considered for naming resources:
1. finding resources easily when writing code
2. understanding resources easily when reading code
3. making names useful for translators (R.string.* resources only)
4. reusing layouts with <include/> (R.id.* resource conflicts)
5. dealing with library projects

Logically, arranging resources should be no different than grouping java classes into packages (or putting files into folders). However, since Android resources have no namespaces, prefixes must be added to the resource name to achieve the same (e.g. com.example.myapp.photo becomes com_example_myapp_photo).

I suggest to divide the app into separate components (activities, fragments, dialogs, etc.) with short unique names that can be used as resource prefixes. In this way we're grouping resources with related functionality together, which makes them easy to find (point 1) and we're at the same time avoiding naming conflicts with both <include/> and library projects (points 4 and 5). Note that resources common to multiple components can still have a prefix (such as R.string.myapp_ok_button).

After the prefix, the name should tell us what the resource is used for (action to be performed, content to be displayed, etc.). Choosing a good name is important for understanding (points 2 and 3).

Sometimes "component_name" will give us enough information, which is especially true if the type is already given by the R class (in R.string.myapp_name_string the 2nd "string" is redundant). However, explicitly adding type can improve understanding (e.g., it can be helpful for translators to distinguish between a toast, or a label). Sometimes the "name" and "type" parts can be swapped to allow type-based filtering (R.string.photo_menu_* will give us only menu-related items for the photo component).

Let's say we're writing an activity for taking pictures, class com.example.myapp.photo .PhotoActivity. Our resources could look like this (grouped by the component "photo"):

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  

---

If you poke around in Android's documentation, there are various mentions of "best practices", but there are certainly no concrete rules. For example, in Icon Design Guidelines, Google suggests naming icons with a "ic_" prefix.

A good place to start may be Providing Resources.

Also dig around in the SDK source/examples as well as on the Android Developers Blog if you want to see how the Google developers do things.

---

I found handy next naming convention for strings:

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

For example, clear_playlist_text, delete_song_message, update_playlist_positivebutton_text. And "action" here is optional.

---

you can read the google documentation for code style to get an idea here

---

I generally followed the java naming conventions for resource ids(not for files for files) except I added "x" in front of the ids for example:

<TextView android:id="@+id/xTvName" android:layout_width="wrap_content" android:layout_height="wrap_content"></TextView>

In java we can use it simple(we can also rememberin simple)

TextView mTvName=(TextView)findViewById(R.id.xTvName);

Here mTvName(It is in general android suggested naming conventions) and xTvName which was named in layout file as part of android TextView's Id(x meant for XML),I followed this type of naming conventions for view objects such as Buttons and EditText etc.

in XML IDS:xViewTypeSpecificName

in Java:mViewTypeSpeficName

The above conventions makes my life easier when I create complex layouts. Just try to make your names as much as possible short in length and it is better if they are understandable and meaningful to other co-developers(but it may not possible every time),Hope that my experience will help others,suggestions are welcome.

---

In our android projects there are lots of components like buttons, labels, textboxes. So simple name like for example "name" this is very confusing to identify "name" is label or textbox. Mainly it happen when you are maintaining projects developed by some other developers.

So to avoid this kind of confusion I used following names for Buttons TextBoxes or Labels

Example :

 btnName
 labName
 txtName
 listName

May be this is helpful for you.

---

There are some restrictions:

1. Resource name should contains be a-z,0-9,_
2. Resource name should start with a-z,_

그건 그렇고, 지침을 따르거나 표준 코드에서 배우는 것이 더 좋습니다.

참고 URL : https://stackoverflow.com/questions/7165582/are-there-conventions-on-how-to-name-resources