Completing object construction after GSON deserialization

Question

I have successfully started using GSON to serialize and de-serialize a hierarchy of objects in my Android application.

Some of the objects being serialized have members which I must mark as transient (or otherwise use alternative GSON annotations to prevent them being serialized) because they are references to objects that I do not want to serialize as part of the output JSON string. Those references are to objects which must be separately constructed by some other means.

Once the structure is de-serialized back into Java objects, at some point I need to fill in those references. I could easily do this perhaps by using a series of setXXX() type methods, but until that is done, those objects are in an incomplete state. What I am therefore wondering is whether there is a more robust approach to this.

Ways I have thought of so far:

1. Have the objects throw a RuntimeException (or something more suitable) if they're in an incomplete state; that is, if they're asked to do some work when some initialization method wasn't called.

2. Separate out the serializable bits into a separate data model object. In other words, take out the stuff that can't be serialized. After GSON de-serialization, build up my 'real' objects using those data objects in their composition. This seems to defeat the convenience of using GSON somewhat.

3. Write a custom deserializer for GSON to handle the special creation of those objects.

Answer 1

Check out https://github.com/julman99/gson-fire

It's a library I made that extends Gson to handle cases like Post-serialization and Post-deserialization

Also it has many other cool features that I've needed over time with Gson.

Answer 2

I would likely take the second approach, because as I typically design my applications, anything that needs to be serialized/deserialized is really just plain old data, or POJOs if you prefer. If I find myself needing to customize/configure the serialization API to do what I want, I tend to simplify what's being serialized, so the serialization API doesn't need the extra configurations.

So, if I have a more complicated data model, parts of which aren't to be serialized/deserialized, then I extract from it a simpler set of POJOs, as a conceptually separate data model to participate in the serialization/deserialization. This does then indeed require an extra step to map between the two data models, but that's usually pretty simple, also.

If the third approach is preferred, then note also the Instance Creator feature, as it can provide another useful hook into customizing the deserialization process.