You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 26, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Feb 26, 2023. It is now read-only.
If @FocusChange annotation is used altogether with @EditorAction annotation on the same text view(or any TextView subclass), project fails to compile because of the code generated by Android Annotations.
...and the compilation fails because of the generated code which looks like this:
@Override
public void onViewChanged(HasViews hasViews) {
View view_edit_text = hasViews.findViewById(R.id.edit_text);
if (view_edit_text!= null) {
view_edit_text.setOnFocusChangeListener(new OnFocusChangeListener() {
@Override
public void onFocusChange(View view, boolean hasFocus) {
MainActivity_.this.onFocusChange();
}
}
);
view_edit_text.setOnEditorActionListener(new OnEditorActionListener() {
@Override
public boolean onEditorAction(TextView textView, int actionId, KeyEvent event) {
MainActivity_.this.onEditorAction();
return true;
}
}
);
}
}
As you can see view_edit_text variable is typed as an instance of View class, which of course does not have the setOnEditorActionListener method and therefore the generated code could not be compiled.
Workaround
I found a workaround how to get a compilable piece of code: inject the EditText using @ViewById(R.id.edit_text) annotation and the generated code is now compilable because in the generated code, there's the injected field used to call methods on, which has a correct type.
Inject EditText(or any TextView or it's subclass):
@WonderCsabo shouldn't it be enough to put the @EditorAction handler before the @FocusChange handler? i bet the @EditorAction one retrives the view as TextView so it should work?
I think that moving @EditorAction handler before @FocusChange handler would be good enough. I like that it would make the code look a little bit cleaner by having the right type directly from the variable declaration.
I also agree that ultimate fix would be to always cast it to a correct type. However, if a cast would happen on every method call, there might be a number of unnecessary casting(and downcasting as well e.g. from TextView to View), which makes the code look a little bit ugly.
If a cast would happen only when necessary that would be fine, although I still like the idea of having correct type directly from the variable declaration.
Activity
WonderCsabo commentedon May 11, 2016
Nice bug report. Wanna contribute this fix?
dodgex commentedon May 12, 2016
@WonderCsabo shouldn't it be enough to put the
@EditorActionhandler before the@FocusChangehandler? i bet the@EditorActionone retrives the view asTextViewso it should work?WonderCsabo commentedon May 12, 2016
That may fix this specific issue. However i guess the ultimate fix would be casting to the target type of the listener if needed.
branoh commentedon May 12, 2016
I think that moving
@EditorActionhandler before@FocusChangehandler would be good enough. I like that it would make the code look a little bit cleaner by having the right type directly from the variable declaration.I also agree that ultimate fix would be to always cast it to a correct type. However, if a cast would happen on every method call, there might be a number of unnecessary casting(and downcasting as well e.g. from
TextViewtoView), which makes the code look a little bit ugly.If a cast would happen only when necessary that would be fine, although I still like the idea of having correct type directly from the variable declaration.
WonderCsabo commentedon May 12, 2016
@branoh wanna contribute either of these fixes?
branoh commentedon May 12, 2016
@WonderCsabo I can try but I'm not very familiar with AA code structure, so it'll probably take me some time to fix it.