55

Just a quick question, what is the ids.xml used for when developing an Android app? I saw an example on the android resources webpage which contained:

<resources>
  <item name="snack" type="id"/>
</resources>

What would this be used for?

Alex Lockwood
  • 83,063
  • 39
  • 206
  • 250
sam
  • 2,469
  • 8
  • 37
  • 57

5 Answers5

35

id.xml is generally used to declare the id's that you use for the views in the layouts.

you could use something like

<TextView android:id="@id/snack">

for your given xml.

Alex Lockwood
  • 83,063
  • 39
  • 206
  • 250
Yashwanth Kumar
  • 28,931
  • 15
  • 65
  • 69
  • 23
    Any advantage in defining it in "ids.xml" as opposed to just doing... android:id="@+id/snack" ? – pyko Dec 24 '11 at 06:42
  • 5
    So, should i use android:id="@+id/newID" or declare newID on ids.xml file? What is the best solution? – Nguyen Minh Binh Jun 23 '12 at 06:18
  • 6
    you may use it for tags too `view.setTag(id, value)` to read that tag from your view later... – SparK Oct 22 '13 at 19:59
  • @pyko You may use it for special cases like testing for the presence of a specific optional view (which may never be defined), e.g. something like `android.R.empty`. – sstn Oct 07 '14 at 06:22
  • Another use case I found is for dynamically adding menu items from code, where you want to give it an ID but you don't have the menu item defined in a menu xml file, so you can't use "@+id/foo". So you define the id in the ids.xml file, then reference in code as R.id.foo. – Paul Feb 23 '16 at 16:19
  • The OP and possibly @Paul know that they are the same. – Martin Marconcini Mar 09 '18 at 18:52
  • IDs kept in ids.xml or id.xml could be used for dynamically created views as well. – Cyph3rCod3r Aug 08 '19 at 04:27
  • Is the value of R.id.akey immutable if I store it and compare to R.id.akey? – Marcos Vasconcelos Mar 24 '20 at 18:50
29

ids.xml has the following advantage: all ids were declared, so compiler can recognize them. If something like this:

<TextView
    android:id="@+id/text1"
    android:layout_width="fill_parent"
    android:layout_height="wrap_content"
    android:layout_alignBelow="@id/text2"
    android:text="...."/>
<TextView
    android:id="@+id/text2"
    android:layout_width="fill_parent"
    android:layout_height="wrap_content"
    android:text="...."/>

Can result in compiling error because text2 was refered before declared

Ngo Phuong Le
  • 440
  • 6
  • 9
  • You are right, I am having this exact issue. I know it is old post. In my situation, I have to put save button in the top of XML file but it will appear in the button in the screen I want other view to say ABOVE saveButton. I tried to let the save button to say BELOW that view but that did not work for me. – malhobayyeb Mar 31 '13 at 07:42
  • 1
    Though true, it doesn't really aid much. In this example - you could have put `android:layout_alignBelow="@+id/text2"` and in the second `TextView`, `android:id="@id/text2"`. – ataulm May 21 '13 at 11:31
  • 2
    That's a valid workaround, but declaring an id within a view other than the one being specified might not be the best stylistic choice. For the language to properly mirror your intent, the id should be declared within the view that uses it. – Todd Bauer Nov 15 '13 at 16:12
  • 1
    The example wont work. You need a `RelativeLayout` and then use `android:layout_below`, since `android:layout_alignBelow="@id/text2"` is not valid. Even then this will compile just fine without an `ids.xml`, making the explanation a bit confusing. – hamena314 Jul 01 '18 at 09:28
10

When creating views dynamically, predefining id's in ids.xml gives the posibility to reference a newly created view. After you use the setId(id) method you can access the view as if it had been defined in XML. This blog post has a nice example.

Jose_GD
  • 2,279
  • 1
  • 21
  • 34
8

Another application for id.xml is in respect to layouts and library projects. Let's say you specify a generic list of options in a library (dialog) layout

<CheckedTextView android:id="@+id/checked_option_one"...
<CheckedTextView android:id="@+id/checked_option_two"...
...

and handle these views in a generic (dialog) fragment

optionOneCheck = (CheckedTextView)rootView.findViewById(R.id.checked_option_one);
optionTwoCheck = (CheckedTextView)rootView.findViewById(R.id.checked_option_two);

If you remove any of the view declarations from a copy of the layout in a main project, you will get a "no such field" error exception at runtime.

The compiler doesn't complain, but at runtime the id isn't actually there/known.

Declaring the ids in id.xml and using

<CheckedTextView android:id="@id/checked_option_one"...
...

avoids the runtime error

mir
  • 371
  • 2
  • 5
  • 1
    "The compiler doesn't complain" - are you sure? At the very least, Lint complains if an ID is used which doesn't exist in the project. Regardless, avoiding that runtime error (by the method you've described) would be masking the symptom, but not the problem; you're trying to get a View based on an ID that isn't attached to a View. – ataulm May 21 '13 at 11:37
  • My answer refers to a situation where a base application is in a library project and branded versions use modified layouts with some of the views in the layout omitted by an overridden layout definition in the branded (main) app. As the full layout definition is still in the library project, the compiler finds the id, but at runtime it is not there. – mir May 24 '13 at 02:45
2

ids.xml is much more powerful. You can predefine values like

<item name="fragment_my_feature" type="layout"/>
<item name="my_project_red" type="color"/>

not only id. Actually you can use more resource types: https://developer.android.com/guide/topics/resources/more-resources

It's extremely helpful to predefine some layouts, colors etc. in root module for multi-module app. You can keep actual layouts, colors, etc. in specific app module which has root module as dependency.

PrzemekTom
  • 1,328
  • 1
  • 13
  • 34