ipc - android AIDL interface, parcelables and backwards compatibility -

we expose aidl service third party developers. we'd return parcelable objects service, have concerns backwards compatibility. this, mean clients compiled against version n of parcelable, , service compiled against version n+1 must work together.

from tests, simple flat objects (simple type fields only), backwards compatibility possible, long new fields parceled @ end of stream ... e.g.,

in.writeint(field1); in.writeint(field2); // new field 

however, when comes complex objects, things blow up. example,

class d implements parcelable {   int field1; }  class c implements parcelable {   list<d> ds; } 

if second field added class d,

class d implements parcelable {   int field1;   int field2; // new field } 

unmarshalling of class cs fail (i tried using parcel.writelist() , parcel.writeparcelablearray()).

this seems inconceivable case can't handled. sure, can leave old binder interface as-is, , create new binder interface returns objects of new class additional fields, service returns oft-changing classes, result in convoluted mess. example, interface 1.0 returns person. add field, , have new binder interface 2.0 returns person2 objects, , on.

this leaves using more forgiving format, json, pass ipc data.

any suggestions? thanks.

clients compiled against version n of parcelable , aidl interface need supported service until heat death of universe, not until n+1, unless want break bunch of clients or in position force developers update apps.

sure, can leave old binder interface as-is

any change aidl means need new service endpoint new protocol version, let alone changes parcelable definitions.

for example, interface 1.0 returns person. add field, , have new binder interface 2.0 returns person2 objects, , on.

either:

• get right first time, not have "oft-changing" public api, or

• use bundle "oft-changing" aspects, since bundle stable (e.g., person has properties bundle stuff wish glom onto public api in between every-few-years major api revisions), or

• use bundle in first place, api more passing around property bags, or

• switch serializable, despite being perhaps bit slower, has notion of versioning, or

• dump binding pattern entirely , use command pattern, extras serving property bag

your alternative of json analogous using bundle in first place, except don't have fuss own marshaling/unmarshaling code bundle.

parcelable avoids versioning speed reasons. that's why parceable not designed durable storage, when classes might change between when data saved , when data read in.