Andorid customizes various pits of attr

In the development of Andorid applications, View is often customized to achieve various cool effects. While realizing this effect, we often define many attr attributes, so that we can configure the desired attribute values in XML. The following are various pits that may be encountered in defining attribute values.

Everyone knows how to define attr attributes, as follows:

<declare-styleable name="Sample">
  <attr name="custom" format="string|reference" />
</declare-styleable>

First, declare an styleable name, name name is best known by name, an styleable can have multiple attr attributes, and every attr contains an name. At the same time, it is necessary to indicate the type that can be assigned, which is defined by format. After being defined, it can be used in the custom View to achieve various effects of hanging and exploding the sky, using the following:
Used in xml:

<com.sample.ui.widget.Custom
  android:id="@+id/custom_view"
  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= "http://schemas. android. com/apk/res-auto", and app can be named at will
Get the value from the code:

TypedArray a = context.obtainStyledAttributes(attrs, R.styleable.Sample);
String value = a.getString(R.styleable.Sample.custom);
a.recycle();

According to format, there are getDimension, getColor and other ways to obtain values.

The above only describes the way of 1 general definition, but it is not today's theme. Today's theme is various pits that may be encountered:

1: Only one attr. xml is included in the project, and Attribute "custom" has ES50been defined appears. Reference 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 styleable contain the same attribute custom at the same time. At this time, Attribute "xxx" has already been defined will be prompted at compile time, indicating that the same attribute is defined repeatedly, the same styleable name cannot be defined repeatedly with one attr. xml, styleable name is not 1, attir cannot be defined repeatedly, and attr format attribute does not affect the result of repeated definition. 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 duplicate definition attr as a public attribute 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 appears
There may be multiple attr. xml in different import projects, which is very likely to be duplicated in definition. He can be divided into the following two situations:

a: The main project, the reference library contains styleable name with the same name, such as:
Main project:

<declare-styleable name="Sample">
  <attr name="custom" />
</declare-styleable>

Reference library:

<declare-styleable name="Sample">
  <attr name="custom" />
</declare-styleable>

In this case, there will be no errors in compilation, and it can be compiled normally.

b: The main project, the reference library contains a different name styleable, but has the same name attr, such as;
Main project:

<declare-styleable name="Sample">
  <attr name="custom" />
</declare-styleable>

Reference library:

<declare-styleable name="Sample1">
  <attr name="custom" />
</declare-styleable>

Attribute "custom" has already been defined appears at compile time. It can be concluded that when referring to various libraries and modules in a project, each module defines attr according to the following rules.
1: All cannot be defined repeatedly, and it is difficult to realize all cannot be repeated. Different teams and different products are very likely to define repeatedly, so this method is difficult to realize.
2: Each different module is defined with module prefix, which is much less likely to be repeated. When compiling, the repeated rename will be ok.

The above is the whole content of this paper, hoping to help everyone's study.