Androidでリソースに名前を付ける規則はありますか?たとえば、ボタン、textViews、メニューなどです。
Androidでリソースに名前を付ける規則はありますか?たとえば、ボタン、textViews、メニューなどです。
回答:
公式の推奨があるかどうかはわかりません。
ウィジェットとコンテナを使用したレイアウトのIDには、次の規則を使用します。
<layout>_<widget/container>_<name>
私は、これらのレイアウトで使用するすべての寸法、文字列、数値、および色に対して同じ戦略を実行します。しかし、私は一般化してみます。たとえば、すべてのボタンに共通のtextColorがある場合、名前の前にレイアウトを付けません。リソース名は「button_textColor」になります。すべてのtextColorが同じリソースを使用している場合は、「textColor」という名前になります。スタイルの場合、これも通常のケースです。
私が使用するメニューリソース:
menu_<activity>_<name>
大文字は使用できないため、アニメーションが異なるだけです。ドローアブルxmlリソースについても同様です。
Android SDKから始めるのが良いでしょう。
たとえば、アクティビティ内でIDのスコープを設定しようとします。
もし私が持っていれば、ListView
それは単に@android:id/list
すべての活動に含まれるでしょう。
ただし、2つのリストがある場合は、より具体的@id/list_apple
で@id/list_orange
したがって、ジェネリック(ids、...)はR.java file
その間に再利用されますが、ユニークなもの(場合によっては再利用されます)には、アンダースコアで区切られたジェネリックなものが前置されます。
アンダースコアは、たとえば次のようなものです。
レイアウトの幅があるlayout_width
中で、XMLとlayoutWidth
でコード私はとそれに固執しようとするので、list_apple
したがって、ログインボタンはになりますがlogin
、2つのログインがある場合はとにlogin_foo
なりlogin_bar
ます。
Androidのドキュメントから引用。この件に関してはまだまだあります。
あなたの質問に答えるには:はい、あります。
あなたは例えばグーグル検索を介してそれらの多くを見つけることができます。そして、最高の命名規則などはありません。それは常にあなたのニーズとあなたのプロジェクト属性(最も重要なことはスコープ)に依存します。
最近、Jeroen MolsによるAndroid XMLでのリソースの命名に関する非常に優れたブログ投稿を読みました。著者は、すべてのリソースが従うべき基本原則に言及し、次にこの規則が各リソースタイプにどのように適用されるかについて言及します。どちらもAndroidリソースの命名に関するチートシートに記載されています:
次に、各要素と各リソースタイプを詳細に説明します。
小規模から中規模のプロジェクト(個人使用、数か月の契約申請)からこの規則を使用できると思います。ただし、50以上のアクティビティや1000以上の文字列を含む長時間のプロジェクトにはお勧めしません。
このような大規模なプロジェクトでのリソース値の規約では、それらがどのように使用されるかについてさらに調査する必要があります。たとえば、文字列を考えてみましょう。チームのサイズ、使用している翻訳センター(ある場合)、VCSの影響を受ける可能性があります使用している(マージの競合を回避するためなど)などの可能性があります。文字列を複数のファイルに分割することも考えられます。
私はあなたが最初に何かを探していると思います。だから私は私が言及したブログ投稿をお勧めします。初心者に最適で、独自の命名規則を作成するためのインスピレーションとして間違いなく使用できます。
また、プロジェクトが成長するにつれて、多くのニーズと要件が時間とともに変化する可能性があることにも留意してください。したがって、最初は適切だった命名規則が2年後には適切でなくなるのは、まったく正常なことです。そして、それは完全に元気です。あなたは未来を予測しようとするべきではありません。規約を選択してそれに従ってください。あなたとあなたのプロジェクトに適しているかどうかがわかります。そうでない場合は、それが適切でない理由を考えて、他の何かを使い始めます。
リソースで使用されるいくつかの規則があります。
この「layout_blah」規則は、他のいくつかの場所でも使用されています。たとえば、ビューが持つことができる描画可能な状態である「state_blah」属性があります。
また、これら2つの規則(ファイルの場合は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の名前空間がないことでしたが、IDが2つある場合、これは通常無視できます。同じAndroidは、定義されたIDを再利用するだけです。
idには、3文字の修飾子を使用し、その後にキャメル表記で参照するものを続けます。たとえば、静的テキストラベル(またはtextview)にはlblFoo、編集可能なテキストボックス(Androidではedittext)にはtxtFooを使用します。これは最初は奇妙に思えるかもしれませんが、VB6とそれらのコントロールがラベルとテキストボックスと呼ばれて以来、私はそれを使用しています。
以下は、私がよく使用するものです。
私は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などの規則やさまざまな規則の混合に取り組みません。
短い答え: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
2番目の「文字列」は冗長です)。ただし、タイプを明示的に追加すると、理解が深まります(たとえば、翻訳者がトーストまたはラベルを区別するのに役立つ場合があります)。「名前」と「タイプ」の部分を入れ替えて、タイプベースのフィルタリングを可能にすることができます(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のドキュメントをざっと見てみると、「ベストプラクティス」についてさまざまな言及がありますが、具体的なルールはありません。たとえば、アイコンのデザインガイドラインでは、「ic_」という接頭辞を付けてアイコンに名前を付けることをお勧めします。
開始するのに適した場所は、リソースの提供です。
また、Googleの開発者がどのように行っているかを確認したい場合は、SDKのソース/例やAndroid Developers Blogを調べてください。
私は通常、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
上記の規則により、複雑なレイアウトを作成するときの作業が楽になります。名前をできるだけ短くして、他の共同開発者にとって理解可能で意味のある名前にすることをお勧めします(ただし、毎回できるわけではない場合があります)。私の経験が他の人の役に立つことを願っています。提案は歓迎されます。
私たちのandroidプロジェクトには、ボタン、ラベル、テキストボックスなどの多くのコンポーネントがあります。たとえば「name」のような単純な名前は、「name」がラベルまたはテキストボックスであることを識別するのが非常に混乱します。主に、他の開発者が開発したプロジェクトを管理しているときに発生します。
このような混乱を避けるために、ボタンのテキストボックスまたはラベルに次の名前を使用しました
例:
btnName
labName
txtName
listName
これはあなたに役立つかもしれません。