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.
@Parcelable #301
Description
Implement the Parcelable interface is a waste of time and it's always the same code :
for each attributes to be parceled
get the value
write it (according to its type)
end for
Same kind of code when reading a parcelable
And some glue !
A @parcelable annotation would be really appreciated and will save a lot of time to all of us
Activity
eric-taix commentedon Oct 6, 2013
Sorry everyone, I was working on another project so I had no time to work on AA...
Currently I'm writing some functional tests to verify if everything is OK before sending a pull request.
If you want to test the
@Parcelable/@NonParcelableannotation right now, just fork my repository (eric-taix/androidannotations) and use branch 301_parcelable.WonderCsabo commentedon Jan 9, 2014
I just found a library which does exactly the same thing: https://github.com/johncarl81/parceler . I think it should be considered both implementation and functionality. :)
johncarl81 commentedon Apr 12, 2014
Is there interest in integrating Parceler directly?
WonderCsabo commentedon Apr 18, 2014
I think that would be nice. @DayS what is your opinion?
DayS commentedon Apr 22, 2014
I think it's a wonderful idea :)
WonderCsabo commentedon Jun 1, 2014
Since Parceler cannot be integrated because it causes AA to depend on the whole transfuse framework, i started working in our implementation based on @eric-taix's work.
It seems the current implementation just generates the class, and does not take any
EComponentHolderinto account. I think this is not good, because one could want an enhanced component to beParcelable(for example Views are pretty general), it won't work. @DayS what do you think? Can we restrict the usage of this annotation to enhanced components? Or is there any way to use an annotation handler outside of an enhanced component?yDelouis commentedon Jun 2, 2014
I think it lacks an annotation to enhance real POJO (object which are not aware of the
Context).I'd like to have
@EBeanfor this kind of object and@EHelperinstead of our current@EBean. But we can't break our API.And what about annotating only the field with
@Parceledfor field we want to be put in the parcel ?It seems more easy to validate and to process for AA, and to understand for a developer than putting only one annotation for all fields. Then, it's more in the spirit of AA to have an annotation consider only what it's annotating (field, class or method).
WonderCsabo commentedon Jun 2, 2014
Actually the current implementation only works with POJOs.
Yeah, it would be more convenient to develop if we would annotate the fields, but it results in more annotations in the code. But how can we create a processor which works on POJOs and enhanced components, too? This would be the new
@EBeanwhat you are talking about?yDelouis commentedon Jun 2, 2014
Yes, we have to create a
holderfor enhanced POJOs, extendingBaseGeneratedClassHolder. So we need an annotation (starting by E) to declare that the class will be enhanced.And then, we declare that the class is
Parcelableby adding@Parcelableon the class or adding@Parceledon the fields.I agree, but it also easier to understand for a AA user. Then, private fields won't be parceled (the generated class won't be able to access them). Non parcelable fields either. How do you warn the user about this behaviour ? With an annotation on each field, you can return an error if the field is private or non parcelable.
WonderCsabo commentedon Jun 2, 2014
OK. Unfortunately i do not know AA infrastructure enough to do this change, nor i want to create that, this is too important. Can you implement that sometime?
DayS commentedon Jun 8, 2014
Why not but I'm not sure it worth adding feature. Parcelable could be an exception so if you have any other use case where another root annotation is needed, I'm listening :)
About parcelable, we'll need three annotations :
@EParcelableto enhanced a class and generate parcelable behavior@Parceledto mark a field to be handle by generated parcelable@Parcelableto inject the parcelable object in another enhanced classyDelouis commentedon Jun 16, 2014
The thing is that as
Parcelableis an interface, it shouldn't be responsible for generating the extending class. Indeed, imagine that, in the future, we have another interface likeParcelablethat we want to take into account, let's sayDatabasable. We don't want them to be dependent of each other. So, this way, both will generate an extending class. And we won't be able to use both annotations on the same class.That's why I think that a generating annotation should represent an "extending" relation, not an interface.
Like
EActivitymeans that the class extendsActivity,EServicemeans that the class extendsService,EBeanmeans that the class extendsObjectand has aContext. And I think, it lacks an annotation for a class extendingObjectwithout anyContext. That's why I proposed to renameEBeantoEHelperand add a newEBean.WonderCsabo commentedon Jun 16, 2014
@yDelouis Are you sure we have to break our API? Can't we leave
@EBeanas is and add a new name for theContext-less enhanced class?yDelouis commentedon Jun 16, 2014
Of course we can leave
@EBeanas it is.But I think this name doesn't fit well with what it is.
Any idea for the new enhanced class ?
WonderCsabo commentedon Jun 16, 2014
Maybe you are right. If we have an annotation for beans (POJOs), we should not call the annotation for not beans
@EBean. But i think @DayS should make a decision here.BTW i think we should focus are resources. First the current PRs should be finished and merged, i see you already started the plugin-system, etc.
DayS commentedon Jun 29, 2014
We can't change the behavior of
EBean. It'll be a pain in the ass for every developer using AA as they'll not understand why they don't have context anymore. There are only two options :EBean, release the 3.1. reintroduceEBeanwith new behavior and addEHelperthen release 3.2.But still, I can see all issues about
Ebeannot having context :)Right now, the only names I could think of are :
EUtil,EPojo,EObjectyDelouis commentedon Oct 6, 2015
Implemented in #1559.