Shulou(Shulou.com)06/02 Report--

This article mainly explains "What is the inheritance relationship of Style in Android". Interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Let's let Xiaobian take you to learn "What is the inheritance relationship of Style in Android"!

Android Styles and Themes are very similar to CSS in Web development, making it easy for developers to separate page content and layout rendering. Style and Theme are defined exactly the same way in Android, with only conceptual differences: Style works on individual views or controls, while Theme works on activities or entire applications. Because of the different scope, Theme also needs to contain more items defining attribute values than Style. But in this article, I call Style and Theme both Style.

Android Style has a flaw compared to CSS for the Web in that it can only specify a value for an object via android:theme="@style/AppTheme" or style="@style/MyStyle." CSS, on the other hand, can define multiple styles on DOM elements through class attributes to achieve combined effects. However, Style also has a function that CSS does not have, that is, inheritance. (Of course CSS also gains inherited capabilities through tools such as LESS and SASS.)

Introduction to Style Inheritance

According to the Android Developers official documentation, there are two ways to define Style inheritance: one is through the parent flag parent Style;

#00FF00

The other is to prefix the parent Style with its name and then pass it by ". "Connect the name of the newly defined Style:

#FF0000

The second way to practice multi-level inheritance is to *** concatenate substyles:

30sp

Compared with ***, Android's restriction on the second method is that Style must be defined by itself, or the parent Style and child Style must be defined in the same program, and cannot be a Style that references a third party or system. After all, references to the system's Style need to be prefixed with android: as a namespace.

Secondly, when using Style, for the Style defined in the second way, it must refer to its complete name, that is, it must contain the complete prefix and name:

Android has no restrictions on *** definitions, so all styles defined in the second way can be converted to ***:

30sp

As long as the name in parent corresponds to the actually defined Style name. However, if you change the name of Style to ***, it will be easy to conflict if it is too concise.

The effect of mixing two inheritance methods

As mentioned above, the effect of the two inheritance methods of Style is consistent, so what effect would it be if the two methods were mixed together to define a Style? Let's analyze it with practical examples below.

First define some custom attributes (attr) required for the experiment (this can reduce the interference of system attributes, because the system will always define values for its attributes, so it may not be able to distinguish whether the effect of *** comes from the system or the defined value)

Then define a subclass of TextView, and get the value of the above custom attribute in it and give TextView to render:

import android.util.TypedValue; import android.widget.TextView; /** * @author Ider */ public class StyledTextView extends TextView { public StyledTextView(Context context) { this(context, null); } public StyledTextView(Context context, AttributeSet attrs) { this(context, attrs, 0); } public StyledTextView(Context context, AttributeSet attrs, int defStyleAttr) { super(context, attrs, defStyleAttr); final TypedArray a = context.getTheme() .obtainStyledAttributes(attrs, R.styleable.CustomStyle, defStyleAttr, 0); final CharSequence text = a.getText(R.styleable.CustomStyle_customText); final int color = a.getColor(R.styleable.CustomStyle_customColor, Color.RED); final float size = a.getDimensionPixelSize(R.styleable.CustomStyle_customSize, 70); a.recycle(); setText(text); setTextColor(color); setTextSize(TypedValue.COMPLEX_UNIT_PX, size); } }

Then it is necessary to define the Style required for the study

@android:color/holo_orange_dark Hello World 30dp www.iderzheng.com @android:color/holo_blue_dark blog.iderzheng.com

In the Style defined above, SuperStyleOne works by adding prefixes to child Styles, while SuperStyleTwo works by assigning parent. You can see that SubTwo and SubThree mix two ways.

*** Use custom classes and set different Styles in Activity Layout View

After running, the effect is as follows:

*** and the second are the usage of Style standards, and we can see that they correctly obtain the defined attribute values, and the child Style also correctly inherits and overrides the attribute values of the parent Style.

For the third and fourth, the color rendered is the default red (Color.RED) used in the code, and the font value is also derived from the use value in the code, so it is significantly smaller than the first two. This means that they do not inherit the font sizes and colors defined in SuperStyleOne. However, the content defined in SuperStyleTwo is correctly displayed by the third, indicating that SubTwo successfully inherits the content of the parent Style specified by parent. And the fourth one shows that the overlay effect is also correct.

Until I did this experiment, I assumed that both would work simultaneously, except that the parent designation had higher priority than the prefix. That is to say, Android will first find the value of an attribute from the current Style definition. If it is not found, it will go to the parent Style specified by parent to find it. If it is not found, it will go to the parent Style specified by prefix to find it. However, the above results show that when parent is used to specify the parent Style, the prefix mode does not work, but only as the name of the Style. Android Style does not support multiple inheritance. Style inheritance can only be single-line down the hierarchy.

On the other hand, it is easier to understand the Style defined by the system. For example, if you open themes_holo.xml, you will see that many of the same contents are defined "redundantly" under Theme.Holo and Theme.Holo.Light. But because Theme.Holo.Light specifies its parent Style as Theme.Light with parent, Theme.Holo.Light does not inherit any attribute values from Theme.Holo, so such redundancy is necessary.

... ... ... ...

Theme.Holo.Light is used as the name of Style only for clarity.

At this point, I believe that everyone has a deeper understanding of "what is the inheritance relationship of Style in Android". Let's actually operate it! Here is the website, more related content can enter the relevant channels for inquiry, pay attention to us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.