Andorid Custom attr of various pits _android

In the development of Andorid applications, often customize the view to achieve a variety of cool effects, in the implementation of this hanging effect, we tend to define a lot of attr properties, so that we can configure the value of the property we want in the XML, the following is the definition of the value of the property values may encounter various pits.

We all know how to define attr attributes, generally as follows:

<declare-styleable name= "Sample" >
  <attr name= "Custom" format= "String|reference"/>
</ Declare-styleable>

First declare a styleable name, name is best known by name, a styleable can have multiple attr properties, each attr contains a name, and you need to indicate the type of value that can be assigned, depending on the format. Once defined, it can be used in custom view to achieve the effects of a variety of hanging days, 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", app can be casually named
Get values in code:

TypedArray a = Context.obtainstyledattributes (Attrs, r.styleable.sample);
String value = a.getstring (r.styleable.sample.custom);
A.recycle ();

Depending on the format, there are getdimension,getcolor and other ways to get the value.

The above only describes the general definition of the way, but he is not today's subject, today's theme is likely to encounter a variety of pits:

1: The project contains only one attr.xml, appears Attribute "Custom" has already been defined, 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>

If you declare two styleable and include the same attribute custom, you will be prompted at compile time to "XXX" has already been defined, which represents the same attribute duplicate definition, same styleable Name cannot be repeated in the same attr.xml, styleable name inconsistency Attir cannot be defined repeatedly, attr the Format property does not affect duplicate definition results. You can therefore solve the problem by using the following methods:

A: Rename the same property name and change one of the names to a different name
B: Extract the duplicate definition attr as a public property in the following way:

<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: The project cited a number of external projects, the emergence of Attribute "custom" has already been defined
Different import projects may contain multiple attr.xml, which is most likely to be repeated in the definition, and he is divided into the following two cases:

A: main project, 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, compilation is not an error and can be compiled normally.

B: main project, reference library contains 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>

At compile time will appear Attribute "Custom" has already been defined. It can be concluded that in the project reference to various libraries, modules, the different modules defined attr, to follow the following rules,
1: All can not repeat the definition, all can not repeat difficult to achieve, different teams, different products are very likely to duplicate the definition, so this approach is difficult to achieve.
2: Different modules, defined with the module prefix, this way the repetition probability is much smaller, compile the duplicate rename on OK.

The above is the entire content of this article, I hope to help you learn.