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.
Possibly erroneous suggestion to ease up developement with AA #431
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.
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).
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.
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.
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.
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.
Activity
naixx commentedon Dec 16, 2012
Hi @PerfectCarl
What IDE do you use?
PerfectCarl commentedon Dec 16, 2012
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 :)
naixx commentedon Dec 17, 2012
Do you have this problem using ant or maven? It may be some configuration problem with IDE.
PerfectCarl commentedon Dec 17, 2012
no, just plain old eclipse.
mathieuboniface commentedon Dec 17, 2012
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)
See Last Comment (2012-10-09)
PerfectCarl commentedon Dec 18, 2012
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.
pyricau commentedon Dec 20, 2012
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
Next time it'd be great if you could collect more information. Opening the Eclipse
Window > Show View > Error Logusually 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.
PerfectCarl commentedon Dec 20, 2012
No worry :)
I'll try that, thanks.
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 !
pyricau commentedon Dec 22, 2012
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.