In android developer examples, blogs, etc, I have seen multiple prefixes for the values of style attributes. Can someone please describe when to use what? For example, what is the difference between these 3 cases?
parent="#android:style/TextAppearance"
parent="TextAppearance.AppCompat"
parent="#style/TextAppearance.AppCompat"
What is the difference between these 2 cases?
<item name="colorControlNormal">#color/white</item>
<item name="android:colorControlNormal">#color/white</item>
Without any prefix references the style named on the same file.
#Style references your style.xml project file.
#android:style references defined Android API style.
More about Style Resource and Style and Themes.
About colorControlNormal vs android:colorControlNormal is the same explanation. If you use controlColorNormal you are defining the color applied to framework controls in their normal state in you app. If you use android:colorControlNormal you are overwriting the the color default applied to framework controls by the system.
You can think of # as signaling that a named resource is coming up.
#type/name identifies a resource of type type (string, color, layout, style etc) with name name defined in the app is coming up.
#+id/name identifies an id resource called name that will be created if it doesn't already exist (whereas #id simply refers to an id that already exists).
#android:type/name means that the named resource is part of the Android platform is coming up (it's not defined in the app -- it's provided by the device).
For style parents, the #style is optional. You can refer to styles directly by name. It's redundant because you can't derive a style from anything other than another style anyway.
Related
android:theme="#style/AppTheme"
I think "android" represents a function or a class?
What is "theme" called technically?
"#style" is the string and it's value being "AppTheme", I presume?
Well, this "code" is a XML attribute, and defines the visual style of your EG Activity.
android being a XML name space alias, usually used by Android XML schemas.
theme is the name of the attribute, that is defined in the name space declared previously as android.
#style is a reference to a group of "resources", in this case to predefined styles.
AppTheme is a predefined Style for the entire app.
See also #cricket_007 's link: https://developer.android.com/guide/topics/resources/accessing-resources.html#ResourcesFromXml
I've read (and confirmed with testing) that resource value names (Strings, Drawables, dimensions, etc.) should have a prefix at the beginning (generally the library's name) to avoid name conflicts, because a project that uses the library and declares a resource with a matching name will overwrite the library's resource.
What I'm unclear on is whether the names of attr attributes inside a <declare-styleable> should also be prefixed. Since they are wrapped within the <declare-styleable>, are they protected from over-writing? Within Java code, their resource names are automatically prefixed with the name of the <declare-styleable>, but when used within XML files, they are not.
I'm guessing that their usage is context sensitive. That in my custom Preference's code, when I call context.obtainStyledAttributes() with a specific styleable, it is only at that point that the XML attributes are interpretted as specific types. If I declare a Preference styleable attribute named "min" of type float and use it in my project, it will not matter that there is an attribute named "min" in the v7.preference library's SeekBarPreference styleable of type int, because SeekBar doesn't use my styleable when calling obtainStyledAttributes().
So if my assumption is correct, there's no reason the compiler would be consolidating attributes by name like that. But custom attribute styling is a complex beast in Android, and I'm not sure if I'm missing something in my testing. It would be nice to omit the prefixes in my library's attribute names for ease of use/documentation.
If the <declare-styleable> is defining attributes for a Style, then I think it's still safe from conflicts, because Styles don't merge. They only reference each other from their own attributes. If I understand them correctly--they are somewhat convoluted to me.
On a related note, is there any reason view IDs should be prefixed? I'm thinking yes, because my library view exists within a project's view structure and a user of the library calls findViewById() on an ID that matches one of mine, I could envision scenarios where the search turns up my view first and trips them up. But Google's own appcompat libraries take no such precaution, so I'm unsure.
After studying documentation and AOSP source code, I've come to the conclusion that yes, you should prefix attribute names.
Resource attributes are not <declare-styleable> local. They are all global. When you declare a resource attribute (which can be done inside or outside of a <declare-styleable>), you name it and give it a format type:
<attr name="my_attribute" format="string" /> <!-- This is a declaration -->
When you reference a resource attribute (which is only done from within a <declare-styleable>), you list its name but not its format.
<attr name="my_attribute" /> <!-- This is a reference -->
Lint shows an error if you try to declare two attributes with the same name.
The fact that you can declare an attribute from within a <declare-styleable> is merely a convenience for code conciseness. It does not imply a limited scope. If you are planning to use the same attribute in multiple styleables, it's probably good practice to put its declaration outside of any <declare-styleable>, so it can be found easily.
One oddity I've noticed is that Lint doesn't show an error if two different libraries have overlapping attribute declarations. I suppose it doesn't cause an issue if they both have the same format type. I haven't checked to see what happens if they don't.
As for why Google doesn't prefix attribute names in AppCompat, I figure they want it to be very easy to use, and almost interchangeable with AOSP xml code, so they want the attribute names to match similar attribute names in AOSP. And so they deemed the simplicity of use outweighs the risk. What I suspect they overlook is how disjointed and lacking their documentation is on setting up and using styleables and attributes, so it's not obvious what to watch out for when setting up our own custom views and preferences.
Can anyone explain the question mark means in Android XML attributes?
<TextView
style="?android:attr/windowTitleStyle"
More attributes
/>
The question mark means it's a reference to a resource value in the currently applied theme. See the linuxtopia Android Dev Guide or the android.com Dev Guide for more about it.
\? escapes the question mark.
The ? lets you refer to a style attribute instead of a specific hard-coded resource. See "Referencing style attributes" in the Android Dev Guide for details.
So, how is this actually useful? It makes the most sense when considering multiple themes containing the same custom resource attribute.
Say you have movie-related themes like MyThemeTransformers and MyThemeHobbit, and both have an attribute called movieIcon. And that movieIcon attribute points to a different #drawable resource, say robot.png or hobbit.png, in each theme definition.
You can refer to "?attr/movieIcon" anywhere the theme is in effect (like in a toolbar or dialog or whatever kind of View layout), and it will automatically point to the correct drawable when you switch between themes. You don't need any theme-dependent logic to use the different drawables. You just define the movieIcon attribute for each theme and the Android framework takes care of the rest.
I was looking for how to highlight a selected item in a list when displaying a contextual action bar for the selection, and the solution I found was to set the android:background attribute of my row layout xml to "?android:attr/activatedBackgroundIndicator".
How does setting this work though?
what is the mechanism involved?
what do the syntax elements like "?", "attr", "activatedBackgroundIndicator" mean?
where is the meaning of "activatedBackgroundIndicator" defined?
If you are in a forensic mood here is how to dig and find out what is going on.
android:background="?android:attr/activatedBackgroundIndicator"?
Intuitively this means set the background to some drawable.
But lets decompose this further to see how we get to our mysterious drawable.
To be precise it means "set the background attribute to what the attribute "activatedBackgroundIndicator" refers to in the current theme.
If you understand "refers to in the current theme" part, you have basically understood everything that is going on behind the covers.
Basically, activatedBackgroundIndicator is not an actual drawable but a reference to a drawable. So where is "activateBackgroundIndictor" attribute actually defined?
Its defined in your sdk directory in a file name attrs.xml. For example:
path_to_android_sdk/platforms/android-17/data/res/values/attrs.xml
If you open that file, you will the declaration as follows:
<attr name="activatedBackgroundIndicator" format="reference" />
attrs.xml is where you declare all the attributes that you are later going to use in your view xml. Note we are declaring the attribute and its type and not actually assigning a value here.
The actual value is assigned in themes.xml. This file is located at:
path_to_android_sdk/platforms/android-17/data/res/values/themes.xml
If you open that file, you will see the multiple definitions depending on what theme you are using. For example, here are the definitions for themes name Theme, Theme.Light, Theme.Holo, Theme.Holo.Light respectively:
<item name="activatedBackgroundIndicator">#android:drawable/activated_background</item>
<item name="activatedBackgroundIndicator">#android:drawable/activated_background_light</item>
<item name="activatedBackgroundIndicator">#android:drawable/activated_background_holo_dark</item>
<item name="activatedBackgroundIndicator">#android:drawable/activated_background_holo_light</item>
Now we have our mysterious drawables. If you pick the first one, it is defined in the drawable folder at:
path_to_android_sdk/platforms/android-17/data/res/drawable/activated_background.xml
If you open that file you will see the definition of the drawable which is important to understanding what is going on.
<selector xmlns:android="http://schemas.android.com/apk/res/android">
<item android:state_activated="true" android:drawable="#android:drawable/list_selector_background_selected" />
<item android:drawable="#color/transparent" />
</selector>
Here we are defining a drawable with two states - default state is just transparent background and if the state is "state_activated" then our drawable is "list_selector_background_selected".
see this link for background information on on drawables and states.
"list_selector_background_selected" is a 9 patch png file that is located in the drawable-hdpi folder.
Now you can see why we defined activatedBackgroundIndicator as a reference rather than linking directly to the drawable file - it allows you to pick the right drawable depending on your theme.
I wondered this as well at one point. A large amount of the Android resources seem to be like a black-box and can't see them directly. I may be missing them someplace, but I can't find them in the SDK source code. Here is what I do know.
android:background will take a drawable.
The syntax is in the style
Must be a reference to another resource, in the form "#[+][package:]type:name" or to a theme attribute in the form "?[package:][type:]name"
In this case the ? signifies to look at a theme in package android and it is of type attr where the name is activatedBackgroundIndicator.
You should be able to access this in the code-behind with android.R.attr.activatedBackgroundIndicator as well.
A list of Android attr properties can be found at R.attr
activatedBackgroundIndicator is a defined drawable in Android 3.0+ as
Drawable used as a background for activated items.
It's basically just a standard item defined in the OS. I can't seem to find in in the Android source, but here is a link to the documentation. activatedBackgroundIndicator
This is a form of attaching a value from a theme. The value is technically not known during resource compilation because the theme values may not be known at that point. Instead the value is resolved at runtime based on the actual theme taken from (most commonly) ContextThemeWrapper.
This provides a way of reusing resource values. I'm not talking performance-wise here, but rather organization and maintenance-wise. The attribute acts as it were a variable with the promise that it will hold an actual value at runtime.
This approach also allows for greater customization - instead of hardcoding the value of e.g. window background drawable it gets the actual drawable from a theme, supplying a chosen attribute as the key. This lets you override the value for that attribute. You simply need to:
Create your own theme (which is just a fancy name for a "style" resource), most commonly deriving from one of default themes.
Supply your own value for the attribute in question.
The platform will automatically use your value provided that you have specified your theme for an activity or application. You do this like described in the question. The general syntax of theme-attribute references is described here: Referencing style attributes. You will also find an example and description of the whole mechanism there.
Edit
One thing that should be noted is the actual attribute names and their existence in various platform versions. It's fairly common for new attributes to be introduced in next platform versions - for example some were added in version 3.0 for the purpose of ActionBar styling.
You should treat attribute names as part of the API - in other words, they are part of the contract you are allowed to use. This is very similar to classes and their signatures - you use LocationManager class for the purpose of obtaining last device location because you know from some source (tutorials, reference, official guides, etc.) what's the purpose of this class. Similarly, the attribute names and their purpose are (sometimes well, sometimes miserably) defined in the Android Platform documentation.
Update: There is a more detailed version available from the API Guide so I'd like to quote it.
A style attribute resource allows you to reference the value of an attribute in the currently-applied theme. Referencing a style attribute allows you to customize the look of UI elements by styling them to match standard variations supplied by the current theme, instead of supplying a hard-coded value. Referencing a style attribute essentially says, "use the style that is defined by this attribute, in the current theme."
To reference a style attribute, the name syntax is almost identical to the normal resource format, but instead of the at-symbol (#), use a question-mark (?), and the resource type portion is optional. For instance:`
Original Answer:
numan salati already offered an perfect answer but it have not addressed the "?" syntax. Here's a quote from API Guide Accessing Resources
To reference a style attribute, the name syntax is almost identical to the normal resource format, but instead of the at-symbol (#), use a question-mark (?), and the resource type portion is optional. For instance:
?[<package_name>:][<resource_type>/]<resource_name>
Can anyone explain the question mark means in Android XML attributes?
<TextView
style="?android:attr/windowTitleStyle"
More attributes
/>
The question mark means it's a reference to a resource value in the currently applied theme. See the linuxtopia Android Dev Guide or the android.com Dev Guide for more about it.
\? escapes the question mark.
The ? lets you refer to a style attribute instead of a specific hard-coded resource. See "Referencing style attributes" in the Android Dev Guide for details.
So, how is this actually useful? It makes the most sense when considering multiple themes containing the same custom resource attribute.
Say you have movie-related themes like MyThemeTransformers and MyThemeHobbit, and both have an attribute called movieIcon. And that movieIcon attribute points to a different #drawable resource, say robot.png or hobbit.png, in each theme definition.
You can refer to "?attr/movieIcon" anywhere the theme is in effect (like in a toolbar or dialog or whatever kind of View layout), and it will automatically point to the correct drawable when you switch between themes. You don't need any theme-dependent logic to use the different drawables. You just define the movieIcon attribute for each theme and the Android framework takes care of the rest.