Repository navigation
Exception in @Click validator #66
Description
Activity
Thanks for reporting this.
I think that bug probably appeared when we introduced support for multiple ids in
@Click. If I remember correctly, we already had that kind of bug when using arrays of values. We need to check that, but I think some compilers return "null" instead of returning an empty array when a value is not provided (I'm not sure if it's "some compilers", or a specific compiler).Looking at com.googlecode.androidannotations.helper.IdValidatorHelper.idsExists(Element, Res, IsValid) :
public void idsExists(Element element, Res res, IsValid valid) { int[] idsValues = annotationHelper.extractAnnotationValue(element); if (idsValues[0] == Id.DEFAULT_VALUE) { idExists(element, res, true, true, valid, idsValues[0]); } else { for (int idValue : idsValues) { idExists(element, res, false, true, valid, idValue); } } }
annotationHelper.extractAnnotationValue(element);returns null.Why does it return null, since you have used
@Click(R.id.btnDeviceDetails)? I'm not sure, but it could be thatR.id.btnDeviceDetailsis not resolved, either because it is being built, or itRhas been removed by a clean build, or you did a typo...Could you please give more details regarding the context, ie :
- Does that happen in Eclipse only, Maven only ?
- Did it happen once, or is it systematic ?
- What version of AndroidAnnotations are you using ? Could you confirm you still have this with latest 2.3 snapshot ?
- Not tested with Maven, but happened in Eclipse.
- Happened systematicly: it disappeared when
@Clickvalue removed, then it came back when value was reused. I simplified the code, but there was several@Clickannotations on the class, all carrying the same bug. - 2.2, I can't confirm with 2.3 yet since I can't spend much time right know, but I can try to reproduce this later.
About R: the bug was happening on an incremental build, meaning the R class was generated, and it couldn't be a typo since the value was R.id.btnDeviceDetails is resolved and doesn't show compilation error.
That's very surprising, because it works well in our functional tests.
I would be great if you could isolate that in a separate project.
Also, don't hesitate to tell us your eclipse version, android sdk version, android ADT plugin version, etc.
Could you also check the generated code to see if @Eactivity(R.layout.myLayout) and @ViewById(R.id.someId) really work and the ids are used in the generated code ?
I've been unable to reproduce the bug using the exact same layout file / method names / etc... with AndroidAnnotations 2.2 at home. I don't know what to think. I'll see if we can reproduce it tomorrow on the same project again.
Ok :)
Let me know. It's probably related to the environment (old sdk / adt ?).
I think we should fix that by adding a compilation error when null is returned. Something like this :
public void idsExists(Element element, Res res, IsValid valid) { int[] idsValues = annotationHelper.extractAnnotationValue(element); if (idsValues == null) { valid.invalidate(); // Add a compile error } else if (idsValues[0] == Id.DEFAULT_VALUE) { idExists(element, res, true, true, valid, idsValues[0]); } else { for (int idValue : idsValues) { idExists(element, res, false, true, valid, idValue); } } }
Are we sure
annotationHelper.extractAnnotationValue(element);is doing the right thing ?The compile time error is a good idea (better than crash), although I don't think we should consider it as a "fix" and close the issue. But the compile error could refer to this issue #66 and ask people to report this if it happens.
One can never be sure, but
annotationHelper.extractAnnotationValue(element);should work. I think the error will ask to report the error (but no reference to an issue number :) we shouldn't do that).The pull request #79 has fixed the crash, AA will now issue a warning instead. We can't do much more until we have a systematic way to reproduce the problem.
User code:
Exception happening:
It works well with: