Re: Hierarchies of EBean

[Carl-Emil Kjellstrand]

I believe that since the annotation framework will create a subclass of your class where the actual implementation of the annotations lives you will not be able to subclass your own class, but you must rather subclass from the generated class_ and this will most likely not be allowed due the the generated class_ being final. This is the case for @EActivity annotated Activity's and you could check to see if its the same for @EBean as-well. Hope that helps a bit on the way :)

Regards,

 Carl

On Sat, Jun 30, 2012 at 11:31 AM, Fabio Collini <fabio....@gmail.com> wrote:

Hi, 

does Android annotations supports hierarchies of EBean?

I have a basic class annotated with EBean and some @Bean fields, if I create a class that extends it it doesn't work well. The init_ method of the child class doesn't contains the inizialization code for superclass @Bean fields. Am I doing something wrong?

I am creating a hierarchy because I am using an ICS feature in my app that supports Android 2.x too. It would be great if I could create two @EBeans using Android Annotations and annotate them with something like @EBean(version=14)  and @EBean(version=7). The right bean could be injected controlling the version of the device.

Thanks for this great library!

Regards, Fabio  

[Fabio Collini]

Hi, Ebean subclass is final too...

However in my opinion it's not difficult to implement, I think that now there is a for cycle on all annotated fields of a class. If this cycle checks also the superclass fields it should work. Obviously generated subclasses of parent and child classes are not related and with some duplicated code but it should work.

Regards, Fabio

Il giorno domenica 1 luglio 2012 11:44:34 UTC+2, Carl-Emil ha scritto:

I believe that since the annotation framework will create a subclass of your class where the actual implementation of the annotations lives you will not be able to subclass your own class, but you must rather subclass from the generated class_ and this will most likely not be allowed due the the generated class_ being final. This is the case for @EActivity annotated Activity's and you could check to see if its the same for @EBean as-well. Hope that helps a bit on the way :)

Regards,

 Carl

[Pierre-Yves Ricau]

Hello Fabio,

The @EActivity is currently the only component that can be extended, and I'm sometimes wondering if that was a good design decision. The main problem here is that it makes users rely on the generated code, and this may change from one release to another.

One way to solve this would be to avoid generation of intermediate subclasses, and directly collect annotations from all super classes and apply them all at once in the final generated class. However, annotation processing isn't made to work this way, you only collect annotations for classes that are being compiled (and the super classes may already be compiled).

Regarding your use case, I think being able to inject one implementation or another depending on the Android version is quite a good use case. But this information cannot live on "@EBean", because of incremental compilation : the information is needed at the place your inject, not on the component declaration. So that would be something added to @Bean.

2012/7/2 Fabio Collini <fabio....@gmail.com>

--
Pierre-Yves Ricau

http://www.piwai.info

[Fabio Collini]

Hi,

I have seen you fixed this issue in version 2.7, many thanks! Any idea when stable version will be available?

Now that bean hierarchies can be used would be great some thing like a factory to choose which implementation can be used. Or maybe Bean annotation could contain a reference to a resource string with concrete implementation to use. Using resources folders suffix concrete implementation could be choosed based on android version, density, ... Using library project resources could be overridden in other projects.

Thanks and regards

Fabio

[Pierre-Yves Ricau]

Hi !

A lot of things could be done regarding dependency injection and configurations, although we have to remember that we are doing this at compile time, not runtime. We have some priorities for now, such as getting the 2.7 out ASAP, and fixing the Eclipse compiler bug (https://bugs.eclipse.org/bugs/show_bug.cgi?id=387956), and then we'll start thinking about this :) .

2012/8/21 Fabio Collini <fabio....@gmail.com>

[Sebastian Mera]

So, AA does not support inheritance, do not work well with mocks and everything is final. I am wondering why I am still using it ...

[Kay-Uwe Janssen]

you can disable that the generated classes are final: https://github.com/excilys/androidannotations/wiki/CustomizeAnnotationProcessing#generatefinalclasses

And what exactly do you mean with does not support inheritance?