When developing Android applications, we often customize Views to achieve various cool effects. While achieving this amazing effect, we often define many attr attributes, so that we can configure the attribute value we want in XML. The following are various pitfalls that may be encountered when defining attribute values.
Everyone knows how to define the attr attribute, generally as follows:
<declare-styleable name="Sample"> <attr name="custom" format="string|reference" /> </declare-styleable>
First declare a styleable name. The name name is best known as the name. A styleable can have multiple attr attributes. Each attr contains a name. At the same time, it is necessary to specify the type that can be assigned. This is defined by format. After definition, you can use it in a custom view to achieve various effects of thrilling, as follows:
Used in xml:
< android: android:layout_width="130dp" android:layout_height="130dp" android:layout_gravity="center_horizontal" android:layout_marginTop="90dp" app:text="@string/custom_desc" />
Remember to declare xmlns:app="/apk/res-auto", app can be named as it is at will
Get the value in the code:
TypedArray a = (attrs, ); String value = (); ();
Depending on the format, there are also methods such as getDimension, getColor, etc. to get the value.
The above only describes the general definition, but it is not today's topic. Today's topic is a variety of pitfalls that may be encountered:
1: The project contains only one, and the Attribute "custom" has already been defined. Refer to the link
<declare-styleable name="Sample">
<attr name="custom" format="string|reference" />
</declare-styleable>
<declare-styleable name="Sample1">
<attr name="custom" format="string|reference" />
</declare-styleable>
As stated above, two styleables contain the same attribute custom at the same time. At this time, the Attribute "xxx" has already been defined during compilation, indicating that the same attribute is repeatedly defined. The same styleable name cannot be repeatedly defined in the same one, and the styleable name is inconsistent attir cannot be repeatedly defined. The attr format attribute does not affect the result of repeated definitions. Therefore, the following methods can be used to solve this problem:
a: Rename the same attribute name and change one of them to a different name
b: Extract the repeated definition attr as a public property, as follows:
<attr name="custom" format="string|reference" /> <declare-styleable name="Sample"> <attr name="custom" /> </declare-styleable> <declare-styleable name="Sample1"> <attr name="custom" /> </declare-styleable>
2: Multiple external projects are referenced in the project, and Attribute "custom" has already been defined
Different import projects may contain multiple, so it is very likely to be repeated when defining. It is divided into the following two situations:
a: Main project, the reference library contains the styleable name of the same name, such as:
Main project:
<declare-styleable name="Sample"> <attr name="custom" /> </declare-styleable>
Quote library:
<declare-styleable name="Sample"> <attr name="custom" /> </declare-styleable>
In this case, there will be no errors in the compilation and it can be compiled normally.
b: Main project, the reference library contains different named styleables, but has the same name attr, such as;
Main project:
<declare-styleable name="Sample"> <attr name="custom" /> </declare-styleable>
Quote library:
<declare-styleable name="Sample1"> <attr name="custom" /> </declare-styleable>
Attribute "custom" has already been defined during compilation. From this we can see that when referring to various libraries and modules in the project, each different module defines attr, and the following rules must be followed.
1: It is difficult to implement all of them, and it is very likely that they can be defined repeatedly for different teams and different products, so it is difficult to implement this method.
2: If you add module prefix when defining each module, the chance of repeating this method is much smaller, and renaming the duplicates during compilation is OK.
The above is all about this article, I hope it will be helpful to everyone's learning.