Java Annotations in Your Android App

In Java, elements that start with an at-sign (@) are annotations. In the following code, the @Override annotation reminds Java that the method immediately below the annotation has the same name and the same parameter types as a method in the parent class. The use of the @Override annotation is optional. If you remove all @Override lines, the code works the same way.

package com.allyourcode.company;

import java.text.NumberFormat;

import java.util.Locale;

public class FullTimeEmployee extends Employee {

<strong> public double salary;</strong>

static NumberFormat currency = NumberFormat.getCurrencyInstance(Locale.US);

public FullTimeEmployee() {

}

public FullTimeEmployee(String name, String jobTitle, double salary) {

this.name = name;

this.jobTitle = jobTitle;

this.salary = salary;

}

<strong> public double pay() {</strong>

<strong> return salary;</strong>

<strong> }</strong>

<strong> </strong>

@Override

public String getPayString() {

return name + ", " + currency.format(pay()) + "\n";

}

}

Why use the @Override annotation? Imagine leaving off the annotation and mistakenly putting the following getPayString method (and no other getPayString method declaration) in the code:

public String getPayString(<strong>double salary</strong>) {

return name + ", " + currency.format(salary) + "\n";

}

You might think that you've overridden the parent class's getPayString method, but you haven't! The Employee class's getPayString method has no parameters, and your new FullTimeEmployee class's getPayString method has a parameter. Android Studio looks at this stuff in the editor and says, “Okay, I guess the developer is inheriting the Employee class's parameterless getPayString method and declaring an additional version of getPayString. Both getPayString methods are available in the FullTimeEmployee class.”

Everything goes smoothly until you run the code. The Java virtual machine sees the statement

textView.append(<strong>ftEmployee.getPayString()</strong>);

in the main activity and calls the parameterless version of getPayString, which the FullTimeEmployee class inherits from its parent. That parent's method returns the useless Pay not known message. On the emulator screen, you see Ed, Pay not known for the full-time employee. That's not what you want.

The problem in this hypothetical example isn't so much that you commit a coding error — everybody makes mistakes like this one. The problem is that, without an annotation, you don't catch the error until you're running the program. That is, you don't see the error message as soon as you compose the code in the Android Studio editor.

Waiting until runtime can be as painless as saying, “Aha! I know why this program didn't run correctly.” But waiting until runtime can also be quite painful — as painful as saying, “My app was rated 1 on a scale of 5 because of this error that I didn't see until a user called my bad getPayString method.”

Ideally, Android Studio is aware of your intention to override an existing method, and it can complain to you while you're staring at the editor. If you use the @Override annotation in conjunction with the bad getPayString method, the editor underlines @Override in red. When you hover the mouse over the word @Override, you see this message. That's good because you can fix the problem long before the problem shows up in a run of your code.

When Android Studio creates a toString method, it puts another annotation — the @NonNull annotation — at the top of the method declaration. In Java, any reference type variable that doesn't point to anything has the value null. Consider the following cases:

• If you write String greeting = "Hello", the greeting variable points to the characters code>H, e, l, l, o.
• If you write String greeting = "", the greeting variable points to a string containing no characters. No, the string has no characters in it, but yes, it's still a string. If you execute

greeting.length()

you get the number 0.

• If you write String greeting = null, the greeting variable doesn't point to anything. In this case, if you execute

greeting.length()

your app crashes and you see a NullPointerException in Android Studio's Logcat pane.

The @NonNull annotation reminds Android Studio that the value returned by the new toString method must not be null. If Android Studio detects that the method returns null, you see a little yellow mark along the editor's rightmost edge. If you hover over that mark, you see a 'null' is returned by the method warning.