リソースに名前を付ける方法に関する規則はありますか?


104

Androidでリソースに名前を付ける規則はありますか?たとえば、ボタン、textViews、メニューなどです。


良い質問。関連トピックとして、カスタムRとandroid.Rのどちらを使用するか
rds


ディメンションリソースについて、私はこれら
Pravin Sonawane '27 / 07/18

回答:


28

公式の推奨があるかどうかはわかりません。

ウィジェットとコンテナを使用したレイアウトのIDには、次の規則を使用します。

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

私は、これらのレイアウトで使用するすべての寸法、文字列、数値、および色に対して同じ戦略を実行します。しかし、私は一般化してみます。たとえば、すべてのボタンに共通のtextColorがある場合、名前の前にレイアウトを付けません。リソース名は「button_textColor」になります。すべてのtextColorが同じリソースを使用している場合は、「textColor」という名前になります。スタイルの場合、これも通常のケースです。

私が使用するメニューリソース:

menu_<activity>_<name>

大文字は使用できないため、アニメーションが異なるだけです。ドローアブルxmlリソースについても同様です。


1
これを行うのは、長い名前を避けるために、レイアウトとウィジェットの名前を短くするだけです。たとえば、認証レイアウトのユーザー名編集ボックスは、「authentication_editbox_username」ではなく「au_eb_username」になります
Hossein Shahdoost

46

Android SDKから始めるのが良いでしょう。

たとえば、アクティビティ内でIDのスコープを設定しようとします。

もし私が持っていれば、ListViewそれは単に@android:id/listすべての活動に含まれるでしょう。
ただし、2つのリストがある場合は、より具体的@id/list_apple@id/list_orange

したがって、ジェネリック(ids、...)はR.java fileその間に再利用されますが、ユニークなもの(場合によっては再利用されます)には、アンダースコアで区切られたジェネリックなものが前置されます


アンダースコアは、たとえば次のようなものです。

レイアウトの幅があるlayout_width中で、XMLlayoutWidthコード私はとそれに固執しようとするので、list_apple

したがって、ログインボタンはになりますがlogin2つのログインがある場合はとlogin_fooなりlogin_barます。


あなたの答えから利益を得ることができなくてすみません。それはあまりにも多くの目標に向けて発砲し、私の目で断食することはできません。たとえば、2つのアクティビティの2つの異なるビューにある登録ボタンにどのように名前を付けるのでしょうか。
Stephane

@StephaneEybert、あなたはミックスにアクティビティ名を追加でき、なぜ別のアクティビティのビューにアクセスしたいのかを購入できます。:)
サミュエル

これは素晴らしくて単純で、xmlコードをきれいにします。しかし、大きなアプリをデバッグしようとしている場合、「閉じる」という名前の50個の異なるボタンを追跡しようとすると、イライラすることがあります。私はずっとそのレイアウトの名前で各ビューを前に置くことを好みます。
SMBiggs 2017

25

Androidのドキュメントから引用。この件に関してはまだまだあります。


12
私の2セント:icプレフィックスが好きではありません
AlikElzin-kilaka

1
「どのタイプの共有プレフィックスを使用する必要もないことに注意してください。そうすることは、あなたの便宜のためだけです。」これは、このチャートの下の線です。したがって、接頭辞は選択の問題です。
Tushar Vengurlekar 2014

プレーンな文字列の命名規則は何ですか?アプリケーションで使用する文字列は約30000です。気が遠くなるほどで​​す。
User3、2015

17

あなたの質問に答えるには:はい、あります。

あなたは例えばグーグル検索を介してそれらの多くを見つけることができます。そして、最高の命名規則などはありません。それは常にあなたのニーズとあなたのプロジェクト属性(最も重要なことはスコープ)に依存します。


最近、Jeroen MolsによるAndroid XMLでのリソースの命名に関する非常に優れたブログ投稿を読みました。著者は、すべてのリソースが従うべき基本原則に言及し、次にこの規則が各リソースタイプにどのように適用されるかについて言及します。どちらもAndroidリソースの命名に関するチートシートに記載されています

Androidリソースの命名に関するチートシート

次に、各要素と各リソースタイプを詳細に説明します。


小規模から中規模のプロジェクト(個人使用、数か月の契約申請)からこの規則を使用できると思います。ただし、50以上のアクティビティや1000以上の文字列を含む長時間のプロジェクトにはお勧めしません。

このような大規模なプロジェクトでのリソース値の規約では、それらがどのように使用されるかについてさらに調査する必要があります。たとえば、文字列を考えてみましょう。チームのサイズ、使用している翻訳センター(ある場合)、VCSの影響を受ける可能性があります使用している(マージの競合を回避するためなど)などの可能性があります。文字列を複数のファイルに分割することも考えられます。

私はあなたが最初に何かを探していると思います。だから私は私が言及したブログ投稿をお勧めします。初心者に最適で、独自の命名規則を作成するためのインスピレーションとして間違いなく使用できます。

また、プロジェクトが成長するにつれて、多くのニーズと要件が時間とともに変化する可能性があることにも留意してください。したがって、最初は適切だった命名規則が2年後には適切でなくなるのは、まったく正常なことです。そして、それは完全に元気です。あなたは未来を予測しようとするべきではありません。規約を選択してそれに従ってください。あなたとあなたのプロジェクトに適しているかどうかがわかります。そうでない場合は、それが適切でない理由を考えて、他の何かを使い始めます。


15

リソースで使用されるいくつかの規則があります。

  • 個別のファイルとして存在するリソースの場合、それらはlower_case_underscore_separatedである必要があります。大/小文字混合を使用すると大/小文字を区別しないファイルシステムで問題が発生する可能性があるため、apptツールはファイルが小文字のみであることを確認します。
  • values / ...(属性、文字列など)でのみ宣言されたリソースの場合、規則は一般にmixedCaseです。
  • 単純な名前空間を持つように「分類」で名前にタグを付けるために時々使用される規則があります。たとえば、layout_widthやlayout_alignLeftなどが表示されます。レイアウトファイルでは、所有者は異なりますが、ビューと親のレイアウト管理の両方の属性が混在しています。「layout_ *」の規則により、これらの名前の間に競合が発生せず、名前がどのエンティティに影響するかを簡単に理解できます。

この「layout_blah」規則は、他のいくつかの場所でも使用されています。たとえば、ビューが持つことができる描画可能な状態である「state_blah」属性があります。

また、これら2つの規則(ファイルの場合はunderscore_separated、宣言されたリソースの場合はmixedCase)があるため、多くの不整合が見られます。たとえば、色はファイルまたは明示的な値として宣言できます。一般的には、これらすべてに対してunderscore_separatedを使用しますが、常にそうなるとは限りません。

最終的には、リソースの命名規則についてあまり気にする必要はありません。一貫性を保つために重要なのは、属性の「mixedCase」と、レイアウトパラメータ属性を識別するための「layout_blah」の使用です。

また、ここにある公開リソースを閲覧すると、慣例がよくわかるはずです。

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

属性がすべて一貫していて(layout_規則を理解していれば)、ドローアブルはすべてunderscore_separatedであることがわかります。


12

これは、どの言語やフレームワークでもよくある問題ですが、予約語を避けている限り、何と呼んでいたか覚えていると想定してかまいません。

Androidはxmlリソースファイル名に制限を設けることに注意しましたが、アンダースコアは問題ないようです。ADTは実際に述べています

ファイルベースのリソース名には、小文字のaz、0-9、または_のみを含める必要があります。

最初に私がつまずいたのは、IDの名前空間がないことでしたが、IDが2つある場合、これは通常無視できます。同じAndroidは、定義されたIDを再利用するだけです。

idには、3文字の修飾子を使用し、その後にキャメル表記で参照するものを続けます。たとえば、静的テキストラベル(またはtextview)にはlblFoo、編集可能なテキストボックス(Androidではedittext)にはtxtFooを使用します。これは最初は奇妙に思えるかもしれませんが、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、C#のWinForms、VB.NET、Android、Pythonで10年以上これらを使用しています。Androidがそれをテキストボックスまたはエディットテキストと呼ぶかどうか覚えておく必要はありません。私が知る必要があるのは、lblFooが静的ラベルであり、txtFooがユーザーが入力するものであることです。

最後の注意点の1つは、重要なことに決めた規則に関係なく、コントロールに適切かつ一貫した名前を付けることです。そのため、あいまいなデフォルトIDのTextView5などの規則やさまざまな規則の混合に取り組みません。


4

デザイナーと開発者のための便利なリンク- ここに

寸法とサイズ、命名規則、スタイルとテーマ、9パッチなど。


3

Googleが推進している標準的な規約はないと思います。公式のGoogleアプリでも、人が名前を付ける方法はさまざまです。

1つのディレクトリ階層内の100個のレイアウト(またはドローアブル、メニューなど)ファイルを理解しようとするときに、最も役立つものは何でも。


3

短い答え: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_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  

2

Androidのドキュメントをざっと見てみると、「ベストプラクティス」についてさまざまな言及がありますが、具体的なルールはありません。たとえば、アイコンのデザインガイドラインでは、「ic_」という接頭辞を付けてアイコンに名前を付けることをお勧めします。

開始するのに適した場所は、リソースの提供です。

また、Googleの開発者がどのように行っているかを確認したい場合は、SDKのソース/例やAndroid Developers Blogを調べてください。


1

私は文字列の便利な次の命名規則を見つけました:

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

たとえば、clear_playlist_text、delete_song_message、update_playlist_positivebutton_textなどです。ここでの「アクション」はオプションです。


0

あなたはここでアイデアを得るためにコードスタイルのGoogleドキュメントを読むことができます


9
この記事では、Androidのリソース規約については何も触れていません。
ユージーン

すみません、あなたの質問を誤解したようです。メニューファイルでは、単語を区切るためにアンダースコアを使用する必要があることを知っています。例:options_menu.xml
Kevin Qiu

0

私は通常、IDの前に "x"を追加したことを除いて、リソースIDのJava命名規則(ファイルの場合はファイルではありません)に従いました。次に例を示します。

<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推奨の命名規則です)と、レイアウトファイルでandroid TextViewのId(xはXMLを意味する)の一部として命名されたxTvNameです。ボタンやEditTextなどのビューオブジェクトについては、このタイプの命名規則に従いました。

XML IDS:xViewTypeSpecificName

Javaの場合:mViewTypeSpeficName

上記の規則により、複雑なレイアウトを作成するときの作業が楽になります。名前をできるだけ短くして、他の共同開発者にとって理解可能で意味のある名前にすることをお勧めします(ただし、毎回できるわけではない場合があります)。私の経験が他の人の役に立つことを願っています。提案は歓迎されます。


0

私たちのandroidプロジェクトには、ボタン、ラベル、テキストボックスなどの多くのコンポーネントがあります。たとえば「name」のような単純な名前は、「name」がラベルまたはテキストボックスであることを識別するのが非常に混乱します。主に、他の開発者が開発したプロジェクトを管理しているときに発生します。

このような混乱を避けるために、ボタンのテキストボックスまたはラベルに次の名前を使用しました

例:

 btnName
 labName
 txtName
 listName

これはあなたに役立つかもしれません。


-2

いくつかの制限があります。

  1. リソース名にはaz、0-9、_を含める必要があります
  2. リソース名はaz、_で始まる必要があります

ちなみに、ガイドラインに従うか、標準のコードから学ぶことをお勧めします。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.