A look at Android support Annotations

Transferred from: https://asce1885.gitbooks.io/android-rd-senior-advanced/content/shen_ru_qian_chu_android_support_annotations.html

Original link: http://anupcowkur.com/posts/a-look-at-android-support-annotations/

In the Android support Library19.1 release, the Android tools team introduced several cool annotation types for developers to use in the project. The support library itself also uses these annotations, which is a good omen. Let's take a good look at it. These annotations can be easily added to our project by Gradle:

Compile ' com.android.support:support-annotations:20.0.0 '

There are three types of annotations available for us to use:

• nullness annotations;

• resource type annotations;

• Intdef and stringdef annotations;

We will use code examples to explain the role of each type and how they are used in engineering.

nullness annotations

Parameters decorated with @nonnull annotations cannot be null. In the following code example, we have a null name variable that is passed as a parameter to the SayHello function, which requires that the parameter be a non-null string type:

 public  class  mainactivity extends   actionbaractivity {@Override   void   OnCreate (Bundle Savedinstancestate) { super  .oncreate (        Savedinstancestate);        Setcontentview (R.layout.activity_main);        String name  = null  ;    SayHello (name);  void   SayHello (@NonNull String s) {T Oast.maketext ( this , "Hello" + S,    Toast.length_long). Show (); }}

Because the parameter string s in the code uses the @nonnull annotation decoration, the IDE warns us of a problem with this place in the form of a warning:

If we assign a value to name, such as String name = "US Lord Duarte", then the warning disappears. function parameters that are decorated with @nullable annotations or return values can be null. Assuming that the user class has a variable named name, using User.getname () access, we can write the following code:

 Public classMainactivityextendsactionbaractivity {@Overrideprotected voidonCreate (Bundle savedinstancestate) {Super. OnCreate (savedinstancestate);        Setcontentview (R.layout.activity_main); User User=NewUser ("Our Lord Duarte"); Toast.maketext ( This, "Hello" +getName (user), Toast.length_long). Show (); } @Nullable String getName (@NonNull user user) {returnUser.getname (); }}

Because the return value of the GetName function is decorated with @nullable, it is called:

Toast.maketext (This, "Hello" + getName (user), Toast.length_long). Show ();

Not checking whether the return value of GetName is empty will likely result in crash.

Resource type annotations

Have you ever passed the wrong resource integer value to a function, and can you happily get the integer value you want? Resource type annotations can help us achieve this accurately. In the following code, our SayHello function expects to accept the ID of a string type and use the @stringres annotation adornment:

 Public class extends actionbaractivity {    @Override    protectedvoid  onCreate (Bundle Savedinstancestate) {        super. OnCreate (savedinstancestate);        Setcontentview (r.layout.activity_main);        SayHello (R.style.apptheme);    }     void int ID) {        toast.maketext (this, "Hello"+ getString (id), Toast.length_long). Show ();    }} 

And we passed a style resource ID to it, and the IDE will prompt the following warning:

Similarly, we put the warning in place using a string resource ID instead of a warning disappears:

sayHello(R.string.name);

Intdef and Stringdef annotations

The last type of annotation we want to cover is the IntelliJ-based "magic constant" check mechanism (http://blog.jetbrains.com/idea/2012/02/new-magic-constant-inspection/) (We don't need to know more about how this mechanism is implemented, but you can click on the link if you want to know).

Many times, we use integer constants instead of enumeration types (performance considerations), such as we have a Icecreamflavourmanager class, which has three modes of operation: Vanilla,chocolate and Strawberry. We can define a new annotation named @flavour and use @intdef to specify the type of value it can accept.

 Public classIcecreamflavourmanager {Private intflavour;  Public Static Final intVANILLA = 0;  Public Static Final intChocolate = 1;  Public Static Final intStrawberry = 2; @IntDef ({VANILLA, chocolate, strawberry}) Public@InterfaceFlavour {} @Flavour Public intGetflavour () {returnflavour; }     Public voidSetflavour (@Flavourintflavour) {         This. Flavour =flavour; }}

At this point, if we call Icecreamflavourmanager.setflavour using the wrong integer value, the IDE will make an error as follows:

The IDE will even prompt us to use valid values:

We can also specify an integer value as the flag bit, meaning that these integer values can be manipulated with or, using ' | ' or ' & '. If we define @flavour as the following flag bit:

true, value = {VANILLA, chocolate, strawberry})    public @interface  Flavour {    }

Then you can call the following:

Icecreamflavourmanager.setflavour (Icecreamflavourmanager.vanilla & icecreamflavourmanager.chocolate);

@StringDef usage is roughly the same as @intdef, except for string types.

For questions such as what new annotation types will be added in the future, or how these annotations are dependent, and how annotations interact with IntelliJ itself, you can view the URL: http://tools.android.com/tech-docs/support-annotations.

A look at Android support Annotations