Using same id names in different xml files in android - android

Can i use the same id names in in some other layout in a different xml file???
coz i have done dat that and maybe because of that m getting a nullpointer exception and my activity for that xml does not start...

Absolutely. You can use the same ID's for the same Widget type in any number of layouts that you desire. Just not the same ID in the same Layout XML. Without getting into the debate whether this is recommended or not of course.
What confuses several developers and I confess, when I started, it did confuse me too. When casting a Widget in the Activity, for example, I was often stumped me why I had just one matching ID when I had the same in a few different layouts.
The only thing you need to take care of is, for example, consider this scenarior:
I have two XML's named, say layout_1.xml and layout_2.xml and 2 corresponding Activities, named say, Act1 and Act2. Now, both have the same Widget, say the same TextView with the same ID in both XML's. (Although I am using this example, this is not hypothetical. This is actually how it is in an application of mine). This is quite contradictory to what NullPointer says in his comment. I think he meant you can't use the same ID in the same XML.
<TextView
android:id="#+id/txtFromName"
style="#style/UserName"
android:layout_width="fill_parent"
android:layout_height="0dip"
android:layout_weight="1"
android:ellipsize="marquee"
android:gravity="top|left|center"
</TextView>
Now, when I am casting this in my code, see what shows up in the suggestions when I start typing the findViewById(R.id.txtFrom...)
Why the NPE is perhaps when you use the same ID's in multiple XML files is probably due to some confusion on what the ID is. Keep the corresponding XML open and check the ID when casting and you should be good to go. If it still persists, I would suggest updating your post with your XML code, the Java code and the LogCat crash report.
I keep track of that by literally copying the ID and using the same name as an instance of the Widget when casting it. But, that's just my way I suppose.

Related

It is correct to set the equal id's in different xml files?

For ex. I have 2 Activities.
In first: setContentView(R.layout.activity_first);
In second setContentView(R.layout.activity_second);
activity_first.xml contain View with id android:id="#+id/my_view", and activity_second.xml contain another View. To that View I can set the same id (android:id="#+id/my_view") and all works great.
But the way to set equal id's in different xml files correct? May be I miss some google post about that situation?
There is no harm in setting the same ids to different views as long as they are not in the same view. From the developers site,
An ID need not be unique throughout the entire tree, but it should be unique within the part of the tree you are searching (which may often be the entire tree, so it's best to be completely unique when possible).
It is recommended that you use different ids for different layouts. On the long run, when you will have a lot of layouts and a lot of ids it will get very complicated to differentiate them.
There is no problem with same id.It will work properly. But for a good programming this habit is bad.

managing ID's in android layout file

I don't know whether i am asking the right question or a wrong one.
it may sound foolish but still i feel to clear my basic doubts.
the question is:
i have three different layout files for a single activity.
depending upon the purpose for which the activity is started, it will take one of these layout files as its content.
these layouts have various fields in common.
i have a question that in these different layout files can i have the same "id's" for the common fields.
for ex: i have a save button for all the three layouts.
in all those three layout files..... can i have (For the button)
android:id="#+id/save_button"
the same ID attribute in all the three files.
i require this because i have too many elements(components) in my layout files.
if they can be identified with common names (as they serve the same purpose in their respective layouts) there would be very less names/ids to remember, which will make my program easy to be readable and less things for me to remember.
else i will have to write the same code for components with same functionality.
thankyou in advance.
your answers will help me clear my doubts. please correct me if i am moving with wrong concepts.
Not only is this allowed, but I would encourage it. Using the same id across files allows you to create new layout files without having to change any of the code referencing the button. As long as the id is descriptive of what it relates to, then it shouldn't cause any problems.

CheckedTextView Attributes ID and checkMark

Just start developing with android and think instead of reading a book a webinar could be better because a webinar could also teach me short ways and how an android developer thinks when writing the code but now got a problem
<CheckedTextView
android:id="#android:id/text1"
android:checkMark="?android:attr/listChoiseIndicatorMultiple"
</>
I dont understand the above code up to now see lots of different id definitions some of them was for resources and start with #resource/name, and some of those id definitions was like #+id/name just for creating a new id for the component but this time it is using android:id/text1 and I dont understand why it is using it in that manner
Besides, the checkMark thing make me confuse more what are all those ?android:attr/listChoiseIndicatorMultiple means?
Could you please explain me and show me some resource where can I find all those magic attributes so I can cope next time by myself and hope someday can answer other newbie questions
Thanks a lot in advance, and all comment will be appreciated.
Well, reading the docs has always been helpful to me:
Android Developer Site
XML Layout specific docs
#android:id/text1 is just a format used when the id has been previously defined. When you put a + in there that means the framework should create the resource id if it doesn't already exist.
It's normal to use #+id/thisid when defining a new view in a layout, and then use #id/thisid to reference the aforementioned view from another part of the layout (say, in a RelativeLayout where you need to tell one widget to be below another).
A question mark before the ID indicates that you want to access a style attribute that's defined in a style theme, rather than hard-coding the attribute.
#android:id/text1 basically this is used when you create any android component like button, layout, textviews etc.
but when you need any external component which is general for different platform like any color, image etc then you can declare it as #resource/name.
actually there is nothing different just keep one thing in mind that in #android:id/text1, id will simply work as an class name will contains other objects like textview, imageview or any other.
now if you declare #resource/name then in that also instead of id class name will be resource. actually when you will use it in java then these(#android:id/text1) will be converted into object hierarchy.

Any way to organize android 's id "#+id/"

I am wondering is there a way to organize my widget's android:id . My app has a couple of Activies and couple of layout. It is hard to keep track of all the names of buttons and textviews. My IDE would spring up a list of all the R.id.xxx from previous layouts . Is there a way to sort them like with directory or periods, ie android:id="#+id/abc.efg" or android:id="#+id/abc/efg" . Sort of like sub structuring them or nesting them.
A simple way I keep track is by changing the "id" prefix to something else
ex.
A layout for ActivityOne might have layout IDs as
android:id="#+activity1/textview"
And "TestActivity" could be
android:id="#+test/textview"
I am trying to always use some convention on the id naming. For example use type-of-component prefixes: *btn_somethig* for all Buttons, *et_something* for all EditText and so on... When you're looking for a particular ID, just fill-in first the type of the component.
AFAIK no. I always go by a naming convention based on what I'm looking for. Usually it's, type_of_id_type_of_object_name. So a layout could be layout_relative_layout_main_panel. A sub-view like a TextView would be view_text_view_text1 or something. The detail is app-specific though.

New to android, have a question about layouts in general

I'm making a new application and its basically filled with information about Warcraft.
I have similar apps on my phone that have similar information and when I looked inside their .apk they only had like 10 layouts.
The app that I am making already has 5 layouts and it seems like I will need about 50-60 layouts.
So now my question is it normal to have that many layouts? Or do I have to learn to make one general layout and keep reusing it? For example, like if I need to display information about a topic for instance the classes in warcraft which are 10 different classes with 2-3 different guide pages on average for each class, would I need to make a different layout for each page or is their a better way of doing it?
I would really appreciate any input/suggestions.
What I recommend is having one layout for every type of screen (basically one per Activity) and use Java to fill in all of the info. Use getResources().getString(int id) and pass something from R.string. That means you need to keep all of your information in a strings.xml file in your values folder (located in /res/values). List all of your views in the layout XML file and then find them by ID and set their values.
It's best to keep all of your string resources in a separate XML file and not hard code them into the layout (otherwise it's a pain to replace every instance of a word you realized you misspelled or something). If you don't know how to write XML, that's okay since there are tools in Eclipse, but I HIGHLY recommend learning it.
You can re-use layouts without any problems. In fact for maintaining the code it is a very good idea to do so. No one wants to maintain 50+ layouts and associated code.

Categories

Resources