If you have a layout that has a bunch of views that won't be changed during runtime, for example a TextView used as a label, is it proper to remove the ID from it, or to label it like a view that you would use?
What about layouts? If I have a bunch or table rows in a table, should each have a unique ID or should I clear the field?
It seems to me like it removes a lot of clutter if I clear the IDs if views that I won't be changing but I don't want to do that if it's bad practice.
Thanks.
You only need to define an id for an UI component if you want to reference this component later from your program code (e.g. findViewById(R.id.my_textview) ).
Because you said the views won't change during runtime you don't have to define an id for every view.
It can even help you if you don't define an id, because it keeps the auto complete function of your IDE clean. If you have a lot of layouts (which contain lots of ui elements) and you define an id for each component then you will have a nearly endless list of component ids at the end.
#matt: if your are using canvas to draw the views and set layouts then id is not necessary from my knowledge and I never used id fro and I think its not bad practise.
Related
Is the android:id attribute required for all views in my layout? What is the best practice?
I would prefer to specify IDs in the rare instances that I need it (like x:Name in WPF), but it seems like Android and Eclipse like to have it on everything.
To put some more context in this, I believe the Android compiler automatically generates an ID attribute for every element (I could be wrong) in your xml layout file. But the purpose of having an ID attribute is so that you, the programmer, can either interact or refer to any given element.
For instance, you can set a layout (or table/row or...) to visible or invisible, or you can change the location of something on the screen...
Personally I don't bother putting an id on everything especially if my layouts spans several files and pages.
Views may have an integer id associated, but it's completely optional. You are going to need it if you want to be able to find specific views inside the view tree.
Moreover, ids need not to be unique across the entire view tree, but just in the part you are searching.
No. It's only important if you are putting the view in a RelativeLayout(and will use it to position other views) or want to get it via findViewById(), but it is not required.
I'm studying Android by looking at open source projects code, and what I noticed was that, in many cases, they give ids to almost all the views, even if they don't actually use those ids in code.
For example, they give ids to LinearLayout, RelativeLayout and so on, but they don't really use those ids in code.
Is there any reason why they do that?
Because I think giving ids to all the views only makes me confused about what id was what view.
Is it just a bad practice?
Thank you in advance!
Is there any reason why they do that?
No.
Technically there is no reason to do that if you are not going to use the id anywhere (either in Java or in the XML file).
For eg it could be a personal choice, just like naming variables or naming class depending on its purpose (here note that this could be a personal choice).
From the developer API guides:
Defining IDs for view objects is important when creating a
RelativeLayout. In a relative layout, sibling views can define their
layout relative to another sibling view, which is referenced by the
unique ID.
Again,
Because I think giving ids to all the views only makes me confused
about what id was what view.
You can easily sort out the confusion thing if you give proper name to the id's.
Like:
btn_create for Buttons
tv_mobile_number for TextViews
ll_main_activity for LinearLayouts
rl_details_fragment for RelativeLayouts and so on.
Is it just a bad practice?
Technically not. But it may save you from the pain of typing id's for each and every view and may even save some time for you as well.
As a side note, I usually prefer giving id's only when needed.
Hope this will help you. Cheers!
sure it some times confused, in my case I give id only to views that I will use in codes.
thank.
This question is more about best practices.
I'm working on some code that creates a UI from a dynamic XML file. It took me quite a while to discover that Dynamic Views have an ID of -1. Which means if you want to layout Dynamic Views in relation to other Dynamic Views you need to give them IDs on creation.
So I did that, but I don't really like the solution I came up with, and there's a chance that I could accidentally give the same ID to two elements.
Is there a way to let Android assign unique IDs to these dynamic views, or do I have to create some sort of ID tracking code myself?
Taken from here
From API level 17, you can call
View.generateViewId()
I assumed that each layout's element id's such as buttons, textviews, edittexts, etc. were unique and private to that layout. This being said, you set the Activity to use a certain layout, you should only be able to find view id's based on the id's set in that specific layout.
However, I am finding now that I can reference whatever view id I want from my Activity regardless of the physical layout I have specified with "setContentView(R.layout.THELAYOUTIWANTTOTARGET)". Is this behavior normal, I figured only id's of those elements on the layout I specified above would be available? Looking at R.java, I believe all the id's I specified on all layouts are made public variables, thus, no id's can have the same name or unexpected behavior may occur!
The implications for this on my project is that I must now change all id's in all layouts to be unique. I figured my supplier layout > title textview would have been different from my customer layout > title textview, is this not the case?
Thank you for clarifying!
Your assumption is correct. IDS are global, and for large projects it's sometimes a pain, leading to very long ID names. But that can also be used as an advantage, as you can reuse layouts on different activities.
For example, you can have a layout for a specific part of your activity (a custom buttons bar for example) that you may want to add to several activities. In this case, you can just inflate it into a specific ViewGroup of the first activity, and also in another ViewGroup in another activity. The methods to access specific buttons based on their ids can then be reused in both activities.
The method findViewById will only work on the activity you call it from. If a button (or any other component) exists on different activities, only the one in your current activity will be returned.
Yes, it is normal. As far as I know, there is no way to change it.
So yes, the implication that you will have to have different names for views in different layouts is correct.
EDIT:
Actually... scratch that. I was under the impression that it was necessary, but according to
http://developer.android.com/reference/android/view/View.html
it isn't even necessary to have id's be unique in a single file. Just make sure you aren't searching in a tree that has multiple ids that are the same or you will always get the first occurrence.
It makes sense too since it doesn't really matter if the views have the same ID in R. I will keep this in mind going forward.
I've just ventured into the fun world of Android development, but had a very quirky problem with the test app I was working on.
The app uses a TableLayout where each TableRow contains an EditText and some Buttons.
The TableRows can be added and removed at runtime. It all appeared to be working okay, until I accidentally tilted my device. The display responded and rearranged the layout, but suddenly all of the values were the same on each row.
After some head-scratching I figured out what was going on. Because of the orientation change Android was restarting the activity. When this happens Android tries to save and then restore your instance state, but it does this by storing data relative to the component id.
In my case, because the rows are all created from the same layout, then the EditText in every row has the same id. The result as far as I can tell, is that when the info is saved it is being overwritten for each row, so that the last row wins out.
When restoring there is only one value associated with that id and so it gets applied to every row!
In my case I was able to work around it as I didn't really need to keep the values anyway. In my onSaveInstanceState I DON'T call super.onSaveInstanceState, and likewise in onRestoreInstanceState.
So that finally brings me to my question!
What if I DID want those individual row values to be saved and restored? Is there an accepted way of generating unique ids on reused components (in my case the TableRow)?
If I were you, I would not use your_view.setId(your_new_id) on an EditText view, because this makes your app less stable: What if another view happens to have the exact same Id as your_new_id?
I would use your_view.setTag(some_unique_tag) and then use findViewWithTag(some_unique_tag) to look up the EditText view again.
findViewWithTag(some_unique_tag) could be any Object - I personally prefer String because then it's easy to make some descriptive and unique tags.
Remember, it's only the Views that you use .setTag on that has tags.
In addition to setId there is a generateViewId method in the View class. If you want it pre 17 versions you can just copy it from sources.
You could generate your TableRows in Java and use View.setId(). You might also put the table row in a XML layout file, load it via java & set the Ids - but seems more tricky.
http://developer.android.com/reference/android/view/View.html#setId(int)