Exception in @Click validator #66

Activity

1. pyricau commented on Jan 16, 2012

   

   pyricau

   on Jan 16, 2012

   Contributor

   More actions

   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 that R.id.btnDeviceDetails is not resolved, either because it is being built, or it R has 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 ?
2. JoanZapata commented on Jan 16, 2012

   

   JoanZapata

   on Jan 16, 2012

   ContributorAuthor

   More actions

   • Not tested with Maven, but happened in Eclipse.
   • Happened systematicly: it disappeared when @Click value removed, then it came back when value was reused. I simplified the code, but there was several @Click annotations 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.
3. pyricau commented on Jan 16, 2012

   

   pyricau

   on Jan 16, 2012

   Contributor

   More actions

   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.
4. pyricau commented on Jan 16, 2012

   

   pyricau

   on Jan 16, 2012

   Contributor

   More actions

   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 ?
5. JoanZapata commented on Jan 16, 2012

   

   JoanZapata

   on Jan 16, 2012

   ContributorAuthor

   More actions

   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.
6. pyricau commented on Jan 17, 2012

   

   pyricau

   on Jan 17, 2012

   Contributor

   More actions

   Ok :)

   Let me know. It's probably related to the environment (old sdk / adt ?).
7. pyricau commented on Jan 20, 2012

   

   pyricau

   on Jan 20, 2012

   Contributor

   More actions

   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);
               }
           }
       }
8. JoanZapata commented on Jan 20, 2012

   

   JoanZapata

   on Jan 20, 2012

   ContributorAuthor

   More actions

   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.
9. pyricau commented on Jan 20, 2012

   

   pyricau

   on Jan 20, 2012

   Contributor

   More actions

   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).
10. pyricau

    added 2 commits that reference this issue on Jan 26, 2012

    Fix to prevent issue #66, not really fixing it but leaving a nice war…

    ...

    08fbafa

    Merge pull request #79 from excilys/66_AvoidNPE

    ...

    0f8ea8a
11. pyricau commented on Jan 26, 2012

    

    pyricau

    on Jan 26, 2012

    Contributor

    More actions

    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.
12. pyricau

    closed this as completedon Jan 26, 2012