Possibly erroneous suggestion to ease up developement with AA

@rest

AA is now becoming my number 1 tool for android.
I love it and use it everywhere.

But I must say that sometimes, it fails to generate the classes. Especially when I changed a lot of things in my resources/layout (refactoring). It crashes and simply fail to generate/update newly added classes.
I noticed that it was very often related to user written classes that references the _generated classes (by AA).

I suspect that the build order is messed up.
In that case, the workaround is simple but cumbersome : remove some annotation/reference, and rebuilt the project.
Then add the annotation back again.

Here are some cases

Using the preferences :

    @Pref
    protected AppPref_ pref;

In the adapter classes :

    @Override
    public View getView(int position, View convertView, ViewGroup parent) {

        DistrictLvItemView itemView = null;
        if (convertView == null) {
            itemView = DistrictLvItemView_.build(context);
        } else {
            itemView = (DistrictLvItemView) convertView;
        }

        itemView.bind(getItem(position));

        return itemView;
    }

Pretty much everywhere :

    final Intent i = new Intent(this, Utils.get(DistrictLvActivity.class));
    this.startActivity(i);

The hack

So, I came up with a hack to prevent user classes to reference the _generated classes.
And the generation is a lot smoother : less crashes,

Here's my cheap hack :

    @SuppressWarnings("rawtypes")
    public static Class get(Class clazz) {
        if (clazz == null)
            return null;
        if (clazz.getCanonicalName().endsWith("_"))
            return clazz;
        String name = clazz.getCanonicalName() + "_";
        try {
            Class result = Class.forName(name);
            return result;
        } catch (ClassNotFoundException e) {
            new RuntimeException("Cannot find class for " + name, e);
        }
        return null;
    }

And you call it that way :

        final Intent i = new Intent(this, Utils.get(DistrictLvActivity.class));
        this.startActivity(i);

Well, I can't prove that it fixed everything because I can't use it with the @rest annotation nor the adapter thingy, but I feel like it's an improvement.

Next ?

I don't know what would be the correct path. I guess it depends of the number people that have those issues.

Anyway, I can resist to share my suggestions :

fixing the build order which could get complicated, because you may have have circle dependencies (and one pass code generators don't like that)
offering ways to prevent developer to reference _generated classes in user classes with new api
showing me how wrong I am (after all, all this is empirical evidence and wild guesses - I"m rushing to get my app out of the door, so I don't have much time for experimentations...).
do more testing : maybe the problem is fixed by 81ec0fc

Anyway, I love AA too much to pass up an opportunity to talk about it (or try to make it better).

Cheers,
Carl.

@PerfectCarl

Hi @PerfectCarl
What IDE do you use?

Eclipse 3.8 + AA 2.7
I also tried Eclipe 4.2 juno and haven't noticed any improvement.
So I went back to the evil I know :)

Do you have this problem using ant or maven? It may be some configuration problem with IDE.

no, just plain old eclipse.

Hi PerfectCarl,

I think you are facing a bug already reported on the Eclipse side, see #257 on AA or here on the Eclipse issue tracker.

As you can see in this issue (eclipse side), nobody is actually working on it.

See Comment 10 (2012-09-01)

There is nobody at present dedicated to working on APT; it's not so much an issue of "everybody wants their bug fixed" as it is "there is almost no one to fix bugs." It sounds like you're comfortable getting your hands a bit dirty in the compiler - if you're able to propose a patch, that would be great. If not, I'm hoping to be able to put in a few days on APT during a vacation later this fall, and this would certainly be a good bug to fix.

See Last Comment (2012-10-09)

Jay, can you take a look at this please ? TIA.

Thanks for your detailed report, mathieu.
And yes, it could very well be due that pesky bug.

At least, if the bug gets ever fixed, that will be a compelling reason to switch to Juno

(God, how I was disappointed with Juno. With all the usability issues in Eclipse, the dev team choose to recode the exact UI but themable. I haven't still recover from it)

Anyway, back to the topic at hand.
Next time, I'll try to pay more attention about the bug (exception, and the state of generated classes) to get a more precise report.

@PerfectCarl

Hi guys,

Sorry I'm showing up after the battle.. I had a lot on my plate recently.

Anyway, here are my thoughts:

First, thank you @PerfectCarl for reporting this and providing ideas and solution, it sure helps

It crashes and simply fail to generate/update newly added classes.

Next time it'd be great if you could collect more information. Opening the Eclipse Window > Show View > Error Log usually provides detail infos about what's going on under the hood. I don't know for sure if your problem are related to the "classic eclipse bug", or if it's something new. A good way to tell is to avoid having imports (using fully qualified names) for generated classes. If this makes the problems go away and never come back, then you nailed it :) .

Regarding the suggestion of having util classes that would magically find the corresponding class: I think it's an interesting idea, and definitely something you could include in your projects, but I'm not sure about having this as part of AA. We don't want people to forget that they are using generated class. The goal is to hide the boilerplate, but still be aware that it exists.

No worry :)

A good way to tell is to avoid having imports (using fully qualified names) for generated classes. If this makes the problems go away and never come back, then you nailed it :) .

I'll try that, thanks.

The goal is to hide the boilerplate, but still be aware that it exists.

Agreed.
The trouble is that the hack needs to use reflection Class.forName. I have no idea if performance suffers, but it contrasts with the AA spirit : no reflexion (we're on Android, man).
What I was looking for was a simple map (lookup table), generated by AA (or some code of mine) that could associate the user class with the generated class.
Is there a way to plug some code of mine in AA ?

I can sure develop a batch that browse the .apt_generated folder.
Is there cleaner way ?
I can sure maintain the map manually, but this is error prone. And could crash your app very badly.

Joyeux Noel !

Merry christmas :)

We could let AA generate that map, but not until we implement a way to maintain a list of all annotated classes under incremental compilation.

Navigation Menu

Repository navigation

Possibly erroneous suggestion to ease up developement with AA #431

Here are some cases

The hack

Next ?

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Possibly erroneous suggestion to ease up developement with AA #431

Description

Here are some cases

The hack

Next ?

Activity

naixx commented on Dec 16, 2012

PerfectCarl commented on Dec 16, 2012

naixx commented on Dec 17, 2012

PerfectCarl commented on Dec 17, 2012

mathieuboniface commented on Dec 17, 2012

PerfectCarl commented on Dec 18, 2012

pyricau commented on Dec 20, 2012

PerfectCarl commented on Dec 20, 2012

pyricau commented on Dec 22, 2012

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions