When I started developping android applications, I had a tendency to define custom R values wherever I need, in particular in layout files. For instance:
findViewById(R.id.customerName).setText(customer.getName())
with layout:
<TextView android:text="TextView" android:id="#id/customerName"
android:layout_height="wrap_content" android:layout_width="fill_parent" />
Now I realize, it might be better to use android.R instead.
findViewById(android.R.id.text1).setText(customer.getName())
with layout:
<TextView android:text="TextView" android:id="#android:id/text1"
android:layout_height="wrap_content" android:layout_width="fill_parent" />
What practice do you follow? What are the advantages and disadvantages of each?
android.R is meant for utilizing resources built in to the operating system.
There are many images/layouts/etc... that come with the operating system that you can just reference using android.R
if you are referencing your own resources that you have created, most always use R. and in most situations I recommend trying to stay away from the built in resources as they change version to version.
Custom. The system-provided IDs come with a risk of referring, in code, to a resource that is not present in the project. Customs IDs exist iff there's a corresponding resource - a drawable, a view, a layout or what have you.
There is no big advantage or disadvantage of the framework id vs the custom id in layouts.
Advantages of using framework identifiers:
Avoid the creation of more identifiers. Saves one field in the apk (and there is an apk size limit).
Must be used in some situations, like ListActivity
Drawbacks of using framework identifiers:
Don't provide a descriptive name
In both practices
The code will work in the future
Missing references are discovered at runtime, and hidden at compile time
I thought the the samples in the SDK would help me take a decision, and (guess what?) it doesn't. The Notepad and LunarLander applications use the android.R.id for the view identifiers, whereas the ApiDemos project uses custom identifiers.
Best practice for GestureBuilder which mixes both approaches? (#+id/addButton and #android:id/empty)
IHMO, worse practice for HelloActivity and JetBoy which define #+id/text #+id/Button01... This is not descriptive and could have been replaced by (#andoid:id/button1, or by #+id/startButton)
You need your own R.java class as it contains references to all of your resources (layouts, images, strings, etc.)
If you want to get a reference to a View with id of "myView", you would use R.id.myView.
If you want to get a reference to built-in Android resources, you would use android.R.id.text
Take a look at the following page:
http://developer.android.com/guide/topics/resources/accessing-resources.html
Related
There are 100+ layouts in a resource folder on android, I can go through them one by one and look at the preview in android studio. They all utilise code like:
tools:text="text for preview"
tools:visibility="visible"
Is there a way to inflate all those one after another in a list/linear layout? And upgrade the tools:xyz attribute to be shown as the real android:xyz attribute in this view
Context&Purpose: To show them in the app under a debug menu dedicated specifically to show available layouts. This is to communicate with both other developers and people without android studio.
I want to avoid doing it manually as it needs to be maintained and that can end very badly for debug functionality such as this. (And that it is a lot of layouts does not help either of course)
After writing it down it feels unlikely, but maybe someone out there have a nice angle on this?
Depending on the complexity of each layout, inflating a hundred of them at once could be quite taxing. You may run out of memory, or get a fair bit of jank. If you are OK with this, then I would say try using the include tag in your debug screen layout
A simple/naive implementation would be something like
<LinearLayout
android:orientation="vertical"
android:layout_width="match_parent"
android:layout_height="match_parent">
<include layout="#layout/A"/>
<include layout="#layout/B"/>
<include layout="#layout/C"/>
<include layout="#layout/D"/>
...
</LinearLayout>
I probably wouldn't recommend doing this, but it might get the job done.
As far as the second part of your question, using tools values as actual values, I don't think there is a way to accomplish this. In fact the tools values are not even available during run time as they are stripped out during the build process.
I am trying android data-binding and I am really amazed with its capabilities. It really shifts all the getters and setters of views to a single place (layout files or custom binding adapters) .
But, I don't understand what is the use of the namespace here? I was reading a recent article from George on Medium here, and he mentioned that:
Anything in the application namespace doesn’t need any namespace in the parameter, but for attributes in the android namespace, you must give the full attribute name including the “android.”
So, if I don't give a namespace, it works. My custom attributes are namespaced with xmlns:app="http://schemas.android.com/apk/res-auto" . I really don't know what that means.
Say I have a text view where I am doing this like this (hardcoded strings just for example) :
<TextView
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:text='#{"Created By:" + user.name + " on " + user.time}' />
It's really good as I can provide arguments here:
<TextView
android:layout_width="match_parent"
android:layout_height="wrap_content"
app:createdBy="#{user.name}"
app:createdAt="#{user.time}" />
And handling that code in Java by setting that text to the same as on above example. This provides an easy to use and understandable code for the layout files.
But, this arguments can collide sometimes. If I am using this at 2 different places with 2 different formats like Created by User A on 7/10/2016 and From User A (7/10/2016). This both can requires same arguments as I showed in second example. How can I distinguish them?
I can also provide third argument like app:format and so that my custom binding function can understand, but can namespaces play the important role here? Can I provide a custom namespaces for multiple data-binding elements and handle them accordingly in my binding adapters? Or namespaces will just be ignored as George mentioned in his article?
In the official documentation they have used bind: namespace and in binding adapter methods they have provided namespace there. I am little bit confused about namespaces' role in data-binding.
XML is very flexible and allows you to provide any number of namespaces. Android, however, isn't (yet) flexible enough to handle more than two -- android and your application's namespace. Android data binding doesn't distinguish between any application namespace name. e.g. bind: or app: doesn't matter because they all refer to http://schemas.android.com/apk/res-auto.
So, the answer to your question is "No." Namespaces won't really help. You could use the android namespace -- assuming there aren't unfortunate collisions. That only extends your flexibility from one to two and I'm pretty sure you want something better than that.
This specific example is perfect for string formatting expressions:
<TextView
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:text='#{#string/createdBy(user.name, user.time)}' />
<TextView
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:text='#{#string/fromUser(user.name, user.time)}' />
But generally speaking, you'll have to either use different attributes names for different uses or add an attribute for the differentiator as you suggested.
Is it not possible to simplify the name of a custom element in an Activity XML file?
<com.library.CustomView
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res/com.example.library.customview"
android:id="#+id/myView"
app:newAttr="value" />
Say for example I have a CustomView control. Do I always have to put "com.library." in front of "CustomView" or is it possible to use xmlns:custom in a FrameLayout so that I don't need to?
This is what I would like to see (if possible):
<CustomView
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res/com.example.library.customview"
android:id="#+id/myView"
app:newAttr="value" />
No. You must specify the fully qualified name of the custom view class. The custom attribites belong to a different namespace. So you nee to have
http://schemas.android.com/apk/res/[your package name].
That is why you have
xmlns:app="http://schemas.android.com/apk/res/com.example.library.customview"
It is necessary to specify fully qualified name of the custom view and hence
<com.library.CustomView
http://developer.android.com/training/custom-views/create-view.html
The docs does not mention any other solution.
Edit:
There seems to be a workaround as mentioned in the below link. Notice comments on both answers. The authors feels there is a little overhead involved. So its left you to use the below although i recommend you to follow the above method mentioned in the docs.
Using custom Views in XML without using fully-qualified class name
So I'm trying to decide whether it would be worth it to refactor out my current use of id's in all of my android layouts to an ids.xml file, or to just leave my view code the way it is (with multiple views sharing ids and both views using "#+id/id_name).
Is there a significant compile/runtime performance benefit to refactoring out the ids to the ids.xml file? How about if the application gets bigger?
Related resources:
http://developer.android.com/guide/topics/resources/more-resources.html#Id
Thank you for your time.
I used <item type="id"> resources in my app because I have TextEdit views that serve a similar purpose in more than one Activity.
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
I would like to do something like
<TextViewPlus
android:id="#+id/settings_title_text"
android:layout_width="wrap_content"
android:layout_height="match_parent"
android:text="#string/settings />
instead of
<com.my.really.super.long.package.name.that.wont.autocomplete.TextViewPlus
android:id="#+id/settings_title_text"
android:layout_width="wrap_content"
android:layout_height="match_parent"
android:text="#string/settings />
I figure I could just put custom Views in the (default) package, but that seems like a bad idea. (EDIT: And upon testing this, it doesn't work anyway) Is there a "good" way to do this?
No, AFAIK you will have to go with the full name.
LayoutInflater.setFactory(LayoutInflater.Factory) allows you to specify an object that performs custom view object creation given the tag name at run time. This could be used to achieve what you want to do. I'd call getFactory() first to retrieve the existing default factory object and use that for any view names that are not your custom views.