Skip to content
This repository was archived by the owner on Feb 26, 2023. It is now read-only.
This repository was archived by the owner on Feb 26, 2023. It is now read-only.

Exception in @Click validator #66

Description

@JoanZapata

User code:

import android.app.Activity;
import android.content.Intent;
import android.view.View;

import com.googlecode.androidannotations.annotations.Click;
import com.googlecode.androidannotations.annotations.EActivity;

@EActivity(R.layout.main)
public class Main extends Activity {

    @Click(R.id.btnDeviceDetails)
    void startDeviceDetails(View v) {
        startActivity(new Intent(this, DeviceInfoActivity_.class));
    }

}

Exception happening:

Unexpected error. Please report an issue on AndroidAnnotations, with the following content: java.lang.NullPointerException
    at com.googlecode.androidannotations.helper.IdValidatorHelper.idsExists(IdValidatorHelper.java:58)
    at com.googlecode.androidannotations.helper.IdValidatorHelper.idListenerMethod(IdValidatorHelper.java:130)
    at com.googlecode.androidannotations.validation.ClickValidator.validate(ClickValidator.java:49)
    at com.googlecode.androidannotations.validation.ModelValidator.validate(ModelValidator.java:53)
    at com.googlecode.androidannotations.AndroidAnnotationProcessor.validateAnnotations(AndroidAnnotationProcessor.java:332)
    at com.googlecode.androidannotations.AndroidAnnotationProcessor.processThrowing(AndroidAnnotationProcessor.java:284)
    at com.googlecode.androidannotations.AndroidAnnotationProcessor.process(AndroidAnnotationProcessor.java:259)
    at org.eclipse.jdt.internal.compiler.apt.dispatch.RoundDispatcher.handleProcessor(RoundDispatcher.java:139)
    at org.eclipse.jdt.internal.compiler.apt.dispatch.RoundDispatcher.round(RoundDispatcher.java:121)
    at org.eclipse.jdt.internal.compiler.apt.dispatch.BaseAnnotationProcessorManager.processAnnotations(BaseAnnotationProcessorManager.java:159)
    at org.eclipse.jdt.internal.apt.pluggable.core.dispatch.IdeAnnotationProcessorManager.processAnnotations(IdeAnnotationProcessorManager.java:134)
    at org.eclipse.jdt.internal.compiler.Compiler.processAnnotations(Compiler.java:810)
    at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:428)
    at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:364)
    at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.compile(IncrementalImageBuilder.java:321)
    at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:301)
    at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.build(IncrementalImageBuilder.java:134)
    at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildDeltas(JavaBuilder.java:265)
    at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:193)
    at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:627)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:170)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:201)
    at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:253)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:256)
    at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:309)
    at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:341)
    at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:140)
    at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:238)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

It works well with:

@Click
void btnDeviceDetails(View v) {
    startActivity(new Intent(this, DeviceInfoActivity_.class));
}

Activity

  1. pyricau commented on Jan 16, 2012

    @pyricau
    Contributor

    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
    ContributorAuthor
    • 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
    Contributor

    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
    Contributor

    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
    ContributorAuthor

    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
    Contributor

    Ok :)

    Let me know. It's probably related to the environment (old sdk / adt ?).

  7. pyricau commented on Jan 20, 2012

    @pyricau
    Contributor

    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
    ContributorAuthor

    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
    Contributor

    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. added 2 commits that reference this issue on Jan 26, 2012
  11. pyricau commented on Jan 26, 2012

    @pyricau
    Contributor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions