Question regarding implementation of TextWatcher methods


#1

I was just wondering why in the code below, we are not required to add @Override annotations on the TextWatcher methods. Does this have something to do with the TextWatcher being an anonymous inner class?

[code] mTitleField.addTextChangedListener(new TextWatcher() {

		public void onTextChanged(CharSequence c, int start, int before, int count) {
			mCrime.setTitle(c.toString());
		}
		
		public void beforeTextChanged(CharSequence c, int count,int start, int after) {
			//Intentionally blank
		}

		public void afterTextChanged(Editable c) {
			//Intentionally blank
		}
		
	});

[/code]


#2

@Override annotations are never required, but they are good practice to save you from yourself. If you think you are overriding a method but you have a slight difference in the method signature so you’re not really overriding it. With @Override, you’ll get a build error.

Anyway, in your code, what you are doing is implementing abstract methods. As you are probably aware, abstract methods MUST be implemented by your concrete class. You will get a build error if you don’t implement them. This is not a situation in which @Override is going to help you. Implementing an abstract method is not the same as overriding a superclass method.

Someone tell me if I got that wrong. I’m much comfortable with firmware and C than SDKs and Java.


#3

Ah, I see what you’re saying. This is similar to how we created an abstract class SingleFragmentActivity and within it a protected abstract method which we could pass onto subclasses, which are then required to implement that method. If Overrides are not required, why does Eclipse autocomplete these required abstract methods with an @Override annotation? Is that just bad design?

Thanks for your quick response!


#4

That’s an interesting observation. You would probably enjoy this discussion from stackoverflow:

http://stackoverflow.com/questions/94361/when-do-you-use-javas-override-annotation-and-why

Read beyond the first answer.

Perhaps the @Override would be useful in the case you mentioned if the abstract class changed in the future to remove an abstract method. Then the compiler would tell you that you are no longer “overriding” (implementing would be a more accurate verb) a required abstract method.


#5

Thanks for the link, I guess it is useful as a way to catch any changes down the line as you said. Although, if nitpicking, it would be nice to have another annotation like “@Abstracted”…