When looking at the examples of defining style parent I noticed two different approaches are used for explicit parenting:
Number one:
<style name="MyButton" parent="android:Widget.Button"/>
Number two:
<style name="MyButton" parent="#android:style/Widget.Button"/>
As far as I could see, they both seem to work. I wonder if both of these approaches are correct or there is one I should stick to?
Both are correct, but stick to this:
<style name="MyButton" parent="#android:style/Widget.Button"/>
As this accesses your current compileSdkVersion's resource directory.
Related
UPDATE: As pointed out in the comments, 'Widget.AppCompat.EditText' is the correct parent style for an AppCompatEditText subclass. In my case, the real issue was I had forgotten to assign a value to our control's default style attribute in our theme, so our control wasn't getting any style to use as a default.
However, this question still could use an answer as to how one properly identifies which style to use as a parent when defining your own default styles when subclassing the standard controls. As such, I've also renamed its title.
As such, I'm leaving this open in hopes someone can answer that question since it will help any who wish to do something similar.
We're trying to define a common look-and-feel for all AppCompatEditText controls used throughout the app. As such, rather than having to manually apply the 'style' attribute on each usage, we're instead trying to replace the default style with our own.
Replacing the default style is actually the easy part. What isn't is knowing what the parent style for our style should be set to so we still have all aspects of the original style which we haven't explicitly overwritten with those in ours.
Digging in the source code for AppCompatEditText, it shows the default style to be stored in R.attr.editTextStyle but I'm not sure where now to look to see what value is stored in it.
Experimenting too didn't get us anywhere. No matter what we have tried so far, we lose the default appearance completely. No underline, no background, no padding, nothing. Just the values we've set, which means it's not picking up the parent style.
We've tried the following without success...
<style name="ZinEditText" parent="android:Widget.EditText">
<item name="zinTypeface">light</item>
<item name="android:textSize">#dimen/defaultTextSize</item>
<item name="android:lineSpacingMultiplier">#dimen/defaultLineSpacing</item>
</style>
<style name="ZinEditText" parent="Widget.AppCompat.EditText">
<item name="zinTypeface">light</item>
<item name="android:textSize">#dimen/defaultTextSize</item>
<item name="android:lineSpacingMultiplier">#dimen/defaultLineSpacing</item>
</style>
<style name="ZinEditText" parent="Base.V7.Widget.AppCompat.EditText">
<item name="zinTypeface">light</item>
<item name="android:textSize">#dimen/defaultTextSize</item>
<item name="android:lineSpacingMultiplier">#dimen/defaultLineSpacing</item>
</style>
<style name="ZinEditText" parent="Widget.Holo.EditText">
<item name="zinTypeface">light</item>
<item name="android:textSize">#dimen/defaultTextSize</item>
<item name="android:lineSpacingMultiplier">#dimen/defaultLineSpacing</item>
</style>
As I said, none of the above seemed to work.
So how does one find the actual parent style to use?
To address the immediate issue, the default style for an AppCompatEditText is Widget.AppCompat.EditText. The second example you've shown is the correct one:
<style name="ZinEditText" parent="Widget.AppCompat.EditText">
...
This needs to be set as the editTextStyle in your app theme.
<style name="AppTheme" parent="#style/Theme.AppCompat">
<item name="editTextStyle">#style/ZinEditText</item>
...
Finding these default styles and attributes is not well documented anywhere officially, as far as I'm aware. The official documentation for Styles and Themes simply directs one to the various R.attr pages for the framework and support packages, to "discover" what's available. However, a generally reliable way to find this for most Views that allow a default style is to inspect the source code.
A View subclass will often implement at least three constructors: one that takes only a Context; one that takes a Context and an AttributeSet; and one that takes a Context, an AttributeSet, and an int for defStyleAttr, a default style attribute. This attribute is what we're looking for. It will usually have a sensible name, like editTextStyle, textViewStyle, checkboxStyle, etc. If you already know the name, you can skip checking the View class for it.
In Views that chain their constructors, this attribute will be normally be in the call to the three-parameter constructor from the two-parameter one. In AppCompatEditText, we can see that the name of this attribute is editTextStyle.
public AppCompatEditText(Context context, AttributeSet attrs) {
this(context, attrs, R.attr.editTextStyle);
}
After we've got the name for the attribute, we then head to the res/values/ directory for the platform or support package the View is in. The default value will be in the relevant themes*.xml file for your app's parent theme.
For the platform themes, there is a base themes.xml, and a few others for specific theme versions, such as Holo and Material.
For support library Views, these theme files will be under the package-specific res/values/ directory, and the default attribute value may be in themes.xml or themes_base.xml.
In v7 appcompat, our app's exact parent theme is likely in v7/appcompat/res/values/themes.xml, though most of the themes there are just direct aliases for base themes; i.e., they don't override any of their parents' attribute values. The default for AppCompatEditText is actually in v7/appcompat/res/values/themes_base.xml. There are separate entries for different themes - the regular, and the light - but they are both the same.
<item name="editTextStyle">#style/Widget.AppCompat.EditText</item>
This is enough to determine which style to use as our parent, but should we want to check out the style specifics, we can then refer to v7/appcompat/res/values/styles.xml, where we find that style's parent:
<style name="Widget.AppCompat.EditText" parent="Base.Widget.AppCompat.EditText"/>
which leads us to v7/appcompat/res/values/styles_base.xml:
<style name="Base.Widget.AppCompat.EditText" parent="Base.V7.Widget.AppCompat.EditText" />
<style name="Base.V7.Widget.AppCompat.EditText" parent="android:Widget.EditText">
<item name="android:background">?attr/editTextBackground</item>
<item name="android:textColor">?attr/editTextColor</item>
<item name="android:textAppearance">?android:attr/textAppearanceMediumInverse</item>
</style>
In appcompat-v7:22.2.0, two resource hierarchies declared in values.xml are confusing to me.
For example, below styles are found in same file: values.xml in appcompat-v7:22.2.0
<!-- From: file:/usr/local/google/buildbot/repo_clients/https___googleplex-android.googlesource.com_a_platform_manifest.git/lmp-mr1-supportlib-release/frameworks/support/v7/appcompat/res/values/styles.xml -->
<style name="TextAppearance.AppCompat.Widget.ActionBar.Title"
parent="Base.TextAppearance.AppCompat.Widget.ActionBar.Title"/>
<style name="TextAppearance.Widget.AppCompat.Toolbar.Title"
parent="Base.TextAppearance.Widget.AppCompat.Toolbar.Title"/>
There is effectively no difference.
From line 323 of styles_base.xml:
<style name="Base.TextAppearance.Widget.AppCompat.Toolbar.Title"
parent="TextAppearance.AppCompat.Widget.ActionBar.Title">
</style>
The Toolbar.Title base style is just an alias to the ActionBar.Title style. I am assuming that Google organized it like this because they are attempting to replace the word "Action Bar" with the word "Toolbar" in our vocabulary, but wanted to make these styles easy to find.
What's the difference between the resource hierarchy of the two: Appcompat.Widget and Widget.AppCompat?
Someone just decided to name them differently. Since both styles have an explicit parent, neither one will inherit any attributes by default anyway. My guess is that it is simply a mistake.
I'm not sure what is the best way to develop interfaces in Android.
is it better to clean the layout file by moving inline attributes to a style file? As far as I know, in HTML it is better to use classes and ids inside HTML, and use them in style.css file. What about android?
I found this, maybe it helps someone else.
When to use Styles
The first problem we must address is a simple one: when should you use a style instead of inline attributes?
Rule #1: Use styles when multiple Views are semantically identical.
This rule is best illustrated with a few examples:
You're creating a calculator. Each button should look the same, so it makes sense to create a `CalculatorButton` style.
You've got a couple screens with multiple text formats - say, headers, subheaders, and text. You can unify their look by creating `Header`, `Subheader` and `Text` styles.
You've got thumbnails all over your app. You want them all to look the same. The `Thumbnail` style is born.
The common thread in all these examples is that these Views are not just using the same attributes - they play the same role across the app. Now, when you want to tweak the look/feel of any of these Views, you can just edit the style and change them all at once. It saves you time, effort and keeps your Views consistent.
Want to save even more work? Use resource references!
Rule #2: Use references within styles when appropriate.
You could define a style this way:
<style name="MyButton">
<item name="android:minWidth">88dp</item>
<item name="android:minHeight">48dp</item>
</style>
What if you wanted minWidth to vary based on screen size? You could just duplicate the style once per screen size (say, sw600dp and sw900dp), but then you're having to duplicate the minHeight attribute as well. What if you want both attributes to change? Suddenly you've got tons of MyButtons defined everywhere, each one duplicating all other attributes. It's a recipe for disaster; it's so easy to forget to change one attribute in one of the many copies.
Styles are just an alias to a series of attributes. It's a lot easier to just define the style like this:
<style name="MyButton">
<item name="android:minWidth">#dimen/button_min_width</item>
<item name="android:minHeight">#dimen/button_min_height</item>
</style>
Now you can just modify a single attribute for each resource qualifier. It's absurd to think about duplicating a layout just to change, say, the width of one View in portrait vs. landscape. You'd use a dimension for that. The same applies for styles.
I don't mean to imply you should always use resource references in styles; just that you should use it if you need multiple values switched on resource qualifiers.
This isn't to say that sometimes you won't need to duplicate a style across resource qualifiers, but you can keep it to a minimum. Usually the only reason to do so is because of platform changes (e.g., the change from paddingLeft and paddingRight to paddingStart and paddingEnd).
Multiple Styles
It would be wonderful if you could apply multiple styles to a single View, like CSS.
You can't. Sorry.
But you can, in a couple of cases, get an approximation of multiple styles.
Rule #3: Use themes to tweak default styles.
Themes provide ways of defining the default style of many standard widgets. For example, if you want to define the default button for the app, you could do this:
<style name="MyTheme">
<item name="android:buttonStyle">#style/MyButton</item>
</style>
If you're just tweaking the default style, the only tricky part is figuring out the parent of your style; you want it to match the appropriate theme for the device, but that varies based on OS version.
If you're using an AppCompat theme, you should use their styles as the parent since they handle differences across platforms as well. For example, they have a Spinner style:
<style name="MySpinner" parent="Widget.AppCompat.Spinner" />
If the style doesn't exist in AppCompat (or you're not using it), the problem is a bit trickier, since you need the parent to switch based on the theme. Here's an example of a custom Button style that uses Holo normally, but Material when appropriate.
You'd put this in /values/values.xml:
<style name="ButtonParent" parent="android:Widget.Holo.Button />
<style name="ButtonParent.Mine">
<item name="android:background">#drawable/my_bg</item>
</style>
Then, in /values-v21/values.xml:
<style name="ButtonParent" parent="android:Widget.Material.Button />
Setting up the correct parent will ensure consistency with both your app and the platform.
If you truly want to define all necessary attributes (instead of just tweaking the defaults), you could skip parenting entirely.
Rule #4: Use text appearance when possible.
TextAppearance allows you to merge two styles for some of the most commonly modified text attributes. Take a look at all your styles: how many of them only modify how the text looks? In those cases, you could instead just modify the TextAppearance.
First, you need to define your TextAppearance:
<style name="MyTextAppearance" parent="TextAppearance.AppCompat">
<item name="android:textColor">#0F0</item>
<item name="android:textStyle">italic</item>
</style>
Notice how I've set a parent - text appearances won't merge, so you need to make sure to define all attributes. You can use any appropriate TextAppearance as the parent.
Now you can use it in a TextView:
<TextView
style="#style/MyStyle"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:textAppearance="#style/MyTextAppearance" />
Notice that I can still apply a style to this TextView, getting me a whopping TWO styles for one view! Not as good as true multiple styles, but I'll take what I can get.
You can use TextAppearance in any class that extends TextView. That means that EditText, Button, etc. all support text styling.
Common Pitfalls
I've explained all the times when I use styles. Unfortunately, it is easy to abuse styles in ways that will hurt you in the long run. Here's a few anti-patterns to avoid.
Rule #5: Do NOT create a style if it's only going to be used once.
Styles are an extra layer of abstraction. It adds complexity. You have to lookup the style to see the attributes they apply. As such, I see no reason to use them unless you're going to use the style in multiple places.
Which would you rather see when you open up a layout: This?
<TextView style="HelloWorldTextView" />
Or this?
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="#string/hello_world" />
It's so easy to create a style later if you need to do so. Don't plan ahead too much.
Rule #6: DO NOT create a style just because multiple Views use the same attributes.
The main reason to use styles is to reduce the number of repeated attributes, right? Why not just use a style whenever multiple Views use the same attributes?
The problem with this attitude is that those Views, if they are not used in the same context, may eventually want to differ in how they look. And at that point, your base style becomes difficult to edit without unintended side effects.
Think about this scenario: you've got a few TextViews that the same text appearance and background. You think, "hey, I'll create a style, that'll cut down on code duplication." Everything is hunky dory at first, but eventually you want to tweak how some of the TextViews look. The problem is, by now that style is used all over the place, so you can't edit it without some collateral damage.
Fine, you say - I'll just override the style directly in the layout XML. Problem solved. Then it happens again. And again. Eventually that style is meaningless because you're having to override it everywhere. It ends up adding extra work instead of making life easier.
That's why I specified in rule #1 that you should use styles when the Views are semantically identical. This ensures that when you change a style, you really do want every View using the style to change.
Implicit vs. Explicit Parenting
Styles support parenting, wherein a child style adopts all attributes of a parent style. It would be rather limiting if they did not.
Suppose I want every Button in the app to look the same, so I make a ButtonStyle. Later, I decide half the Buttons should look slightly different - with parenting, I can just create ButtonStyle.Different, getting the base style + the tweaks.
It turns out there are two ways of defining parents, implicitly and explicitly:
<!-- Our parent style -->
<style name="Parent" />
<!-- Implicit parenting, using dot notation -->
<style name="Parent.Child" />
<!-- Explicit parenting, using the parent attribute -->
<style name="Child" parent="Parent" />
Simple enough, right? But what do you think happens here, when we define parents with both methods?
<style name="Parent.Child" parent="AnotherParent" />
If you answered that the style has two parents, you are wrong. It turns out that it only has one parent: AnotherParent.
Each style can only have one parent, even though there are two ways to define it. The explicit parent (using the attribute) takes precedence. This leads me to the next rule:
Rule #7: DO NOT mix implicit and explicit parenting.
Mixing the two is a recipe for confusion. Suppose I have this layout:
<Button
style="#style/MyWidgets.Button.Awesome"
android:layout_width="match_parent"
android:layout_height="match_parent" />
But it turns out that my style is defined thus:
<style name="MyWidgets.Button.Awesome" parent="SomethingElse" />
Even though it looks like my Button is based on MyWidgets.Button, it's not! The style name is misleading and the only way to discover that is to do extra work and dig into your style files.
The common temptation is to keep using dot notation with explicit parenting so that your styles look hierarchically related:
<style name="MyButton" parent="android:Widget.Holo.Button" />
<style name="MyButton.Borderless" parent="android:Widget.Holo.Button.Borderless" />
Object-oriented styles! They look so pretty, right? But looks are all you're getting - an illusion that styles are related when they are not. The deception is that MyButton.Borderless is related to MyButton, but they have nothing in common! Let's remove the confusion by removing the dots from the name:
<style name="MyButton" parent="android:Widget.Holo.Button" />
<style name="MyBorderlessButton" parent="android:Widget.Holo.Button.Borderless" />
I lose out on the hierarchy looking pretty, but I gain a lot of utility in code.
Styles vs. Themes
Styles and themes are two different concepts. While styles apply to a single View, themes are applied to a set of Views (or to a whole Activity).
For example, suppose you are using AppCompat and you want to set the primary color for the screen. For this, you must theme the entire Activity:
<style name="MyTheme">
<style name="colorPrimary">#color/my_primary_color</style>
</style>
Themes use the same data structure as styles - even using the style tag - but they are, in fact, used in totally different circumstances! They don't operate on the same attributes - for example, you can define a textColor on a View, but there is no textColor attribute for a theme. Likewise, there exists colorPrimary in themes, but in styles they go unused. Thus:
Rule #8: DO NOT mix styles and themes.
Two common mistakes I've seen:
Applying a theme (as a style) to a `View`:
It just makes no sense because a `View` can't use any of the theme attributes anyways. Nothing happens.
Combining the themes/styles in your hierarchy via parenting. I've seen this as a result of people trying to maintain the illusion of hierarchy using dot notation:
Stupid! So, stupid! It does not make any sense and sometimes misfires in strange ways. Just don't do it!
As of Lollipop, you can apply themes to a View and all its children2. Even in that circumstance, you shouldn't mix up the two, though you could use them both in parallel:
<View
style="#style/MyView"
android:theme="#style/MyTheme" />
AppCompat has a simulacrum of View theming for the Toolbar, but that's all you'll get for a while until Lollipop is the minimum supported version of your app. In other words - you can have fun with this feature in a couple years. :P
Conclusion
The unifying element of these rules are to be careful and thoughtful when using styles. They can save you time, but only if you know when to use them.
Font: this article
I am in bit confusion to adding parent style to new style. But both are working. But i want to know which is correct way first one or second one? or is there any other way ?
<style name="customView" parent="viewline">
<item>....
and
<style name="customView" parent="#style/viewline">
<item>....
Thanks
Both are correct as you said. At here there is no any drawback to use any of them.
<style name="customView" parent="viewline">
denotes that the parent style is in same file. And
<style name="customView" parent="#style/viewline">
denotes that parent style is somewhere (may be i another file) in style directory. Thats it.
I tried changing the appearance of a spinner and I partly succeeded. I'm doing this via overriding parts of the theme. I managed to change the text size of the spinner item (i.e. the text size in the drop down button) with my themes.xml and styles.xml:
My themes.xml file looks like this:
<?xml version="1.0" encoding="utf-8"?>
<resources>
<style name="CustomTheme" parent="#android:Theme.Holo.Light">
<item name="android:windowActionBar">false</item>
<item name="android:windowNoTitle">true</item>
<item name="android:spinnerItemStyle">#style/CustomSpinnerItem</item>
</style>
</resources>
My styles.xml file looks like this:
<?xml version="1.0" encoding="utf-8"?>
<resources>
<style name="CustomSpinnerItem" parent="#android:Widget.TextView.SpinnerItem">
<item name="android:textAppearance">#style/CustomTextAppearance</item>
</style>
<style name="CustomTextAppearance">
<item name="android:textSize">30dp</item>
</style>
</resources>
However I cannot find the attributes that are responsible for the text appearance of the items in the dropdown list of the spinner. I tried dropDownItemStyle amongst other things. In my opinion the attribute names are not self-explanatory, so I wanted to know whether there is a documentation of what attribute does what in a style to find out which attributes to override. I found it very cumbersome to trace back all the styles used in a theme via the themes.xml and styles.xml of the platfrom and then try to find the right attributes via trial and error.
I know that one can change the appearance by passing layouts to the adapter, however, this is not really what I was looking for, since (as far as I know), you can only use inheritance in styles and not in layout xml files. If I created a custom layout for the adapter I'd have to create 9-patch images etc., which I think is a bit too time consuming in case I only want to change the text size.
Of course it's possible that I misunderstood the whole concept, since I'm new to Android ;)
You probably have found out the answer since you asked but for others looking at similar questions:
I do not know of a list of attribute names with good explanation of what they do (R.attr's page mostly gives information that is already in the name) but the way I do it is:
Start from the element I give to setDropDownViewResource(), in my case: android.R.layout.simple_spinner_dropdown_item and find.
Find its layout definition in \sdk\platforms\android-17 (specific platform version to avoid redundant results).
Get its style from the layout file. In this case: ?android:attr/spinnerDropDownItemStyle
We now have the attribute name we need.
It's better to do it that way rather than try to guess what attribute to use because you know which attribute the system itself use so it's very likely to be the correct one (unless there's a bug).
If I created a custom layout for the adapter I'd have to create
9-patch images etc.
Well, no, the layout determines what kind of GUI element you would have (a textfield, a spinner, an imagebutton, a custom element...), not how they are styled (nine-patch backgrounds, text colors...), so you still would have to mess with styles to get the right appearance.
For example, for visual consistency I ported the button, checkbox and spinner style from Theme.Holo to Gingerbread, yet I did not mess with layout, all I did was the aforementioned steps plus looking up the result (spinnerDropDownItemStyle in the above example) in themes.xml, which gave me the style name (e.g.: Widget.Holo.DropDownItem.Spinner).
Then I looked that up in styles.xml and imported it (and any parent*) in my project's styles.xml, searching and copying any Holo specific reference in my project and adjusting the namespace accordingly (add android: to attributes and replace ?android:attr with #style for what I copy to my styles.xml file).
So far I haven't had to mess with layouts at all (even the presence of radio buttons in spinner dialogs on Gingerbread is determined by an xml attribute: android:checkMark).
If a style has no parent attribute (like Widget.Holo.DropDownItem.Spinner) then its parent is the same style minus the last element (e.g.: Widget.Holo.DropDownItem)