Stability for production

[teotigraphix]

Hi,

Reading over what you have written this seems to solve a lot of headaches using frameworks you have mentioned that I have dealt with in the past.

I am about to start another project in android with a custom file format of my own and I am wondering if you feel this code is production ready?

Thanks.

[cesar1000]

Hey Michael,

Yes, the code is production ready. Twitter for Android has been using it for 2+ years but serializing all sorts of data models into parcels and the database, I we've found it to completely cover our needs. Also, we're maintaining it actively, so feel free to check it out and let us know if you have any have any questions! Also, contributions are welcome 😄

[teotigraphix]

Nice, thanks for the reply. Reading everything you have it seems like one of those obvious solutions that for what it does could have been done years ago. :)

I really like how simple the API is and the versioning, so yeah I am pretty much going to adopt this for my Android music app format in java. (I have used Kryo, AMF and native Java serialization, tried JSON for things, didn't scale well)

[cesar1000]

Yeah, it's solved so many issues for us. The migration from Serializable/Externalizable was painful, but that's not a problem for new apps!

Also, we have a small IntelliJ plugin that generates serializers for us and we may open source. And by "we", I mean @amandeepg :)

[teotigraphix]

That would be nice, the generator. :) (The boiler plate code for this is a bit but it's where it should be at least, in the vo class IMHO).

I know when using Kryo I pretty much made a crutch for myself with @ Annotations, and in the end I disliked the implementation. It's a great framework but seriously coupled in a couple areas that I didn't need the depth for.

Question, naively thinking, say if I was going to try and read my file from C in the future, I have everything I need in your docs right?

[cesar1000]

Yeah, we'll look into publishing an experimental plugin soon. It's not comprehensive, but it does do a lot of the work and that's something already :)

In my experience, most serialization frameworks attempt to cover all potential use cases for serialization, while the use case of serializing model objects to a database of a parcel is way simpler. Maintaining serializers manually and selecting them explicitly is not a lot of work, and the resulting framework is flexible and performant.

The docs don't specify the format, but the code is quite readable. I did write a native implementation of the deserializer a while back in order to compare performance, and I could share that if it helps.

[teotigraphix]

That would be nice, if/when just for some pointers. It's mainly thinking ahead for me and if/when Android gets serious about DSP that I would use JUCE or something(currently using Caustic audio engine) to load my sequencer, synth data into and be able to reuse some project files.

So purely speculative but it would be great to see a native desreializer for this(as an example).

[cesar1000]

Yeah, I could clean up and share at that point.