Android에서 리소스 이름을 지정하는 방법에 대한 규칙이 있습니까? 예를 들어 버튼, textViews, 메뉴 등이 있습니다.
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 문서 에서 가져 왔습니다 . 주제에 더 많은 것이 있습니다.
귀하의 질문에 답하려면 : 예, 있습니다.
예를 들어 Google 검색 을 통해 많은 것을 찾을 수 있습니다 . 그리고 최고의 명명 규칙은 없습니다. 항상 필요와 프로젝트 속성 (가장 중요한 범위)에 따라 다릅니다.
최근에 Jeroen Mols에서 Android XML의 리소스 이름 지정에 대한 꽤 좋은 블로그 게시물을 읽었습니다 . 저자는 모든 리소스가 따라야하는 기본 원칙과이 규칙이 각 리소스 유형에 어떻게 적용되는지 언급합니다. 둘 다 Android 리소스 이름 지정 치트 시트 에 설명되어 있습니다 .
그런 다음 각 요소와 각 리소스 유형을 자세히 설명합니다.
이 규칙을 중소 규모의 프로젝트 (개인 사용, 몇 달 계약 신청)에서 사용할 수 있습니다. 비록 50 개 이상의 활동이나 1000 개 이상의 문자열이있는 장기간의 프로젝트에는 권장하지 않습니다.
대규모 프로젝트에서 자원 가치에 대한 규칙은 어떻게 사용 될지에 대한 더 많은 조사가 필요합니다. 예를 들어 문자열을 사용하십시오. 팀 규모, 사용중인 번역 센터 (있는 경우), 사용중인 VCS (예 : 병합 충돌 방지) 등에 의해 영향을받을 수 있습니다. 문자열을 여러 파일로 분할하는 것을 고려할 수도 있습니다.
나는 당신이 시작할 무언가를 찾고 있다고 가정합니다. 그래서 제가 언급 한 블로그 게시물을 추천하겠습니다. 초보자에게 유용하며 자신 만의 좋은 명명 규칙을 만들기위한 영감으로 확실히 사용할 수 있습니다.
또한 프로젝트가 성장함에 따라 많은 요구 사항과 요구 사항이 시간에 따라 변경 될 수 있습니다. 따라서 처음에 적합했던 명명 규칙은 2 년 후에는 적합하지 않을 것입니다. 그리고 그것은 완전히 괜찮습니다. 미래를 예측하려고해서는 안됩니다. 규칙을 선택하고 따르십시오. 귀하와 귀하의 프로젝트에 적합한 지 확인할 수 있습니다. 그렇지 않다면 왜 적합하지 않은지 생각하고 다른 것을 사용하십시오.
리소스에 사용되는 몇 가지 규칙이 있습니다.
이 "layout_blah"규칙은 다른 몇 군데에서도 사용되었습니다. 예를 들어 뷰가 가질 수있는 드로어 블 상태 인 "state_blah"속성이 있습니다.
또한이 두 가지 규칙 (파일의 경우 underscore_separated, 선언 된 리소스의 경우 mixedCase)으로 인해 여러 가지 불일치가 발견됩니다. 예를 들어 색상은 파일 또는 명시 적 값으로 선언 할 수 있습니다. 일반적으로 모든 항목에 대해 underscore_separated를 사용하고 싶지만 항상 그런 것은 아닙니다.
궁극적으로 우리는 리소스에 대한 명명 규칙에 대해 크게 걱정하지 않습니다. 일관성을 유지하는 가장 큰 것은 속성에 대한 "mixedCase"이고 레이아웃 매개 변수 속성을 식별하기 위해 "layout_blah"를 사용하는 것입니다.
또한 여기에서 공개 리소스를 살펴보면 규칙에 대해 좋은 느낌을받을 수 있습니다.
http://developer.android.com/reference/android/R.html
속성이 모두 상당히 일관성이 있고 (layout_ 규칙을 이해한다면) 드로어 블이 모두 underscore_separated 등을 볼 수 있습니다.
이것은 모든 언어 나 프레임 워크에 공통적 인 문제이지만 예약어를 피하는 한 당신이 무엇이라고 불렀는지 기억할 수 있다고 가정하면 괜찮습니다.
Android는 xml 리소스 파일 이름에 제한을 두지 만 밑줄은 괜찮은 것 같습니다. ADT는 실제로
파일 기반 리소스 이름에는 소문자 az, 0-9 또는 _ 만 포함되어야합니다.
처음에 나를 괴롭힌 것은 id가있는 네임 스페이스가 부족하다는 것이었지만, 동일한 Android가 정의 된 ID를 재사용 할 경우 두 개의 ID가 있으면 일반적으로 무시할 수 있습니다.
id의 경우 3 글자 한정자를 사용하고 그 뒤에 낙타 표기법에서 참조하는 내용을 사용합니다 (예 : 정적 텍스트 레이블 (또는 textview)의 경우 lblFoo, 편집 가능한 텍스트 상자의 경우 txtFoo (Android의 경우 edittext)). 이것은 처음에는 이상하게 보일 수 있지만 VB6 이후로 사용하고 있으며 해당 컨트롤은 레이블 및 텍스트 상자라고 불립니다.
내가 일반적으로 사용하는 몇 가지 더 다음은 다음과 같습니다.
나는 자바 파일 내의 코드에서도 똑같이 사용하므로 그것에 대해 생각할 필요가 없습니다. 패키지 범위는 이것을 매우 행복하게 허용합니다.
Button btnFoo = (Button)findViewById(R.id.btnFoo);
밑줄 (예 : btn_foo)을 사용하여 약간의 간격을 추가 할 수 있습니다. 예전 습관을 깰 수 있다면 아마 이렇게 할 것입니다.
이들을 축약하는 것이 이상적이지 않을 수 있고 순수 주의자들이 전체 이름을 사용해야한다고 주장하는 사람들이 있습니다.하지만 수십 개의 컨트롤에 이름을 지정하고 다른 시스템과 프레임 워크 사이를 변경하면 전체 이름이 의미를 잃게됩니다. VB, C ++, ASP.NET, C # 및 VB.NET의 WinForms, Android 및 Python에서 10 년 이상이를 사용해 왔습니다. Android가 텍스트 상자 또는 편집 텍스트라고 부르는지 기억할 필요가 없습니다. 내가 알아야 할 것은 lblFoo가 정적 레이블이고 txtFoo가 사용자가 입력하는 내용이라는 것입니다.
마지막으로 중요한 것은 어떤 규칙을 결정하더라도 컨트롤의 이름을 적절하고 일관되게 지정하는 것이므로 모호한 기본 ID (예 : TextView5 또는 다른 규칙의 혼합)와 씨름하지 않도록합니다.
짧은 답변 : 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
두 번째 "문자열"에서 중복 됨). 그러나 명시 적으로 유형을 추가하면 이해도를 높일 수 있습니다 (예 : 번역가가 토스트 또는 레이블을 구별하는 데 도움이 될 수 있음). 때때로 "이름"과 "유형"부분을 교체하여 유형 기반 필터링을 허용 할 수 있습니다 ( 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_"접두사가있는 아이콘 이름 지정을 제안합니다.
시작하기 좋은 곳은 리소스 제공 일 수 있습니다 .
또한 Google 개발자가 작업을 수행하는 방법을 보려면 Android 개발자 블로그 뿐만 아니라 SDK 소스 / 예제 를 살펴보십시오.
예를 들어 ID 앞에 "x"를 추가 한 것을 제외하고는 일반적으로 리소스 ID (파일 용 파일이 아님)에 대한 자바 명명 규칙을 따랐습니다.
<TextView android:id="@+id/xTvName" android:layout_width="wrap_content" android:layout_height="wrap_content"></TextView>
자바에서는 간단하게 사용할 수 있습니다 (간단하게 기억할 수도 있습니다)
TextView mTvName=(TextView)findViewById(R.id.xTvName);
여기에서 mTvName (일반적으로 안드로이드에서 제안하는 명명 규칙)과 레이아웃 파일에서 android TextView의 Id (x는 XML을 의미 함)의 일부로 명명 된 xTvName, 저는 Buttons 및 EditText 등과 같은 뷰 개체에 대해 이러한 유형의 명명 규칙을 따랐습니다.
XML IDS : xViewTypeSpecificName
자바 : mViewTypeSpeficName
위의 규칙은 복잡한 레이아웃을 만들 때 내 삶을 더 쉽게 만듭니다. 이름을 가능한 한 짧게 만드십시오. 다른 공동 개발자가 이해할 수 있고 의미있는 경우 (매번 가능하지 않을 수 있음), 내 경험이 다른 사람들을 도울 수 있기를 바랍니다. 제안을 환영합니다.