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()
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.
i would like to know if it's bad practice when you don't assign an ID to a View, which isn't referenced programmatically, within your xml layout?
Thanks!
Philipp
If a view neither needs to be referenced inside your code nor needs an ID for positioning purposes in the XML layout definition (for the android:layoutAbove/Below etc. properties of child views inside a relative layout), then there is no reason for you to assign an ID to it. I would say generally, it is considered good practice not to assign it, because the IDs you assign will be added to your project's R file, causing unnecessary bloat, however small it may be.
No.
If you are not going to use the view from code its better to not give it an I'd.
here are a few reasons:
Less xml code.
Less options on auto complete with the R.id.
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.
i got the following "problem".
I want to have an activity thats shows me the standings of some teams at a specific gameday.
therefor i would add a spinner and a TableLayout. At the first Start the activity should show the standings of the actual gameday but then you can choose any other gaymeday and the standing should get updated.
Whats the best way to create this activity?
assemble the whole TableLayout with all TableRows and TextViews, give them ids and update those views via id during runtime. Problem: huge unflexible hardcoded layout.xml
assemble the layout during runtime, add ids, update via ids
assemble the layout during runtime. on update remove old views and create new ones
assemble the layout during runtime. on update restart the activity
just whant to know which one is the best. or is there any other way to achieve that
thx Cheetah
If I were you, I'd actually use a GridView with an Adapter. This will abstract away all the handling of layout changes. You just have to worry about mapping your data to appropriate views. This example maps ImageViews to a GridView, but there's no reason you couldn't map to TextViews containing your data in a GridView. Also, because you're using an adapter, you can take advantage of all the Loader classes and they're asynchronous loading capabilities.
In addition, using the approach will allow you program to easily adapt as your dataset changes. You may want to add more data to the table in the future and this approach will allow you to easily do that without having to constantly change your xml layouts.
Does the number of views change? If no. Best way is to use the already existent views and update their values. Try to avoid recreating/reinflating views since that's an expensive task.