Clients compiled against version N of the Parcelable
and the AIDL interface will need to be supported by the Service
until the heat death of the universe, not just until N+1, unless you want to break a bunch of clients or are in position to force those developers to update their apps.
Sure, we can leave the old binder interface as-is
Any change to the AIDL itself means that you need a new service endpoint for the new protocol version, let alone changes to the Parcelable
definitions.
for example, interface 1.0 returns a Person. now we add a field, and we have a new binder interface 2.0 that returns Person2 objects, and so on.
Either:
Get it right the first time, so that you do not have an "oft-changing" public API, or
Use a
Bundle
for the "oft-changing" aspects, sinceBundle
is stable (e.g., aPerson
has aproperties
Bundle
for stuff you wish to glom onto your public API in between every-few-years major API revisions), orUse a
Bundle
in the first place, so your API is more passing around property bags, orSwitch to
Serializable
, despite it being perhaps a bit slower, as it has the notion of versioning, orDump the binding pattern entirely and use the command pattern, with extras serving as the property bag
Your alternative of JSON is roughly analogous to using a Bundle
in the first place, except that you don't have to fuss with your own marshaling/unmarshaling code with a Bundle
.
Parcelable
specifically avoids versioning for speed reasons. That's why Parceable
is not designed for durable storage, when classes might change between when the data was saved and when the data was read in.