@Parcelable

[eric-taix]

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

[mathieuboniface]

Thank you Eric for making AndroidAnnotations better :)

I think it's a really good idea to smash a lot of boilerplate android code.

I think we also need a field exclusion mechanism. What do you think about exclude :

• transient fields
• fileds annotated using a new annotation @NonParcelable

We could also add a validation rule : The class annotated using @Parcelable should not implement android.os.Parcelable because that work is left to the subclass.

[pyricau]

Hey guys, I saw both of your tweets :) . This is of course a very good idea, but did you notice the Search field on the top of this page ? It's there for a reason ;-) .

Check out #14

😈 😈 😈

[eric-taix]

Sorry guys: it's my own fault! I was so furious yesterday night to spend so many time to code this stupid parcelable implementation. I'll try to find a solution for issue #14

[mathieuboniface]

Hey @pyricau ! You just shatter my dream :'(

[eric-taix]

Ok guys I have no time this night, but I just wrote some classes to verify how it could / should be done.

I created a gist: https://gist.github.com/3517619
It's quite easy to understand the code:

• MyBean and MyChild are my models
• MyBean_ and MyChild_ are the generated classes
• FirstActivity creates a new instance of MyBean and puts the instance into the extras of the intent
• SecondFragment receives the bundle, decodes the parcel and uses MyBean

Et voilà ! Of course there's some code to write to detect the attribute's type and to use the right method to encode / decode the parcel into the generated class.

I tested this solution, and it seems to work fine.
What are you thinking ?

[pyricau]

• I think you definitely have the right approach to developing new features in AA, which is starting by writing the annotations + generated code before implementing it :) .
• Looks quite good, but I wonder, why did you use a delegate pattern ? Here, you're creating a new MyBean_ instance that is a MyBean but delegates everything to another MyBean instance. This means that you need to create delegation methods from MyBean_ to MyBean for all methods of MyBean. And it's also a bit weird, to create the object twice.
• Should we really go for the getter way ? What about have default, protected or public attributes ? For data structures, this can make sense. Should we support both ?

[eric-taix]

You are absolutely right: this delegate pattern is a nonsense here. I also agree that the getter way is not required: we can only support default, public and protected attributes.

I'll modify the Gist tonight to reflect the changes we were talking about.

[eric-taix]

Sorry for the delay: I just updated the Gist: https://gist.github.com/3517619

[pyricau]

I noticed this line : aDate = new Date(in.readLong()); . Does that mean we should support a standard set of types such as java.util.Date ? If yes, do you know about any other type ?

[eric-taix]

No I think we don't have to support any set of types. In the example I used a Date and I know that a date is - in fact - a long. That's why I parceled it as a long. In my opinion we only have to support the following set of types:
1- primitive (byte, double, float, int, long, String) and primitive arrays
2- Parcelable and Parcelable arrays
3- Bundle
4- Serializable

For the Serializable we could display a warning (if possible) because it is very inefficient.

I read the API documentation about Parcelable and I created a new Gist to show you how we can write parcelables in a more generic way: https://gist.github.com/3643424
writeValue() / readValue() support one of the following types:

• null
• String
• Byte
• Short
• Integer
• Long
• Float
• Double
• Boolean
• String[]
• boolean[]
• byte[]
• int[]
• long[]
• Object[](supporting objects of the same type defined here).
• Bundle
• Map (as supported by writeMap(Map)).
• Any object that implements the Parcelable protocol.
• Parcelable[]
• CharSequence (as supported by writeToParcel(CharSequence, Parcel, int)).
• List (as supported by writeList(List)).
• SparseArray (as supported by writeSparseArray(SparseArray)).
• IBinder
• Any object that implements Serializable

[pyricau]

Here is the [Parcel doc](http://developer.android.com/reference/android/os/Parcel.html#writeValue(java.lang.Object).

There's a typo in your list : it's not Object. but Object[] (I was a bit surprised at first).

So, basically, yeah we can use writeValue() and readValue().

[eric-taix]

I worked on this issue this week-end: validators and the processor are done and seem to work - BTW JCodeModel is not really easy to understand and there's not many tutorials or examples on the web.

Now I'd like to add tests in functional-test-1.5 and to test them in functional-test-1.5-tests. Is there any documentation which explain how to do ?

[mathieuboniface]

Hi eric,

Thank you for handling that feature development ! And sorry again for the delay...

You're right JCodeModel is not well documented, however AndroidAnnotations source code contains a lot of usage example for this library.

Concerning the tests, there are not documented but once again, we have already wrote a lot of tests and you could just see how they are implemented.

[pyricau]

It would be interesting to see if we can take ideas from this : https://github.com/foxykeep/parcelablecodegenerator

[ened]

@eric-taix did you go further with this? If yes, please let us know the WIP repo so that someone could continue. :)