Handling serialization on older clients when model updates

[mneubrand]

Hi,

We're currently developing an Android app which uses SFS2X on the backend wit a custom server extension. Our game uses putClass and class serialization fairly extensively to communicate back and forth. The problem is that those classes change sometimes when a new version gets released (attribute added, etc.) which leads to serialization errors on older clients (NoSuchFieldException, etc.).

We don't want to force everybody to upgrade to a new version every time we do this but rather have old clients ignore new fields. In other games we use JSON and Jackson for de/serialization and we can just tell its serializer disable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES) to achieve this. Is there any way of doing something similar in SFS or do we need to force upgrades every time we change our model?

Thanks,
Markus

[Lapo]

Hi Markus,
unfortunately no. The client and server classes must match the same fields. Not firing the errors would open the doors to all sort of problems, including hacking attempts.

Changing the model on the server requires and update of the client too. If you're finding yourself changing the model this often there's a chance or two you haven't planned it accurately or simply it's structure in a too restrictive way for your continuous updates.

I would suggest to use classes for objects that are unlikely to change that often and SFSObjects (which work as key-value containers) for the mutable data.

[mneubrand]

Hi,

While we try to avoid them model changes happen inevitably during a products lifetime (especially early on in beta). Using SFSObjects as workaround would be a lot of work. How could simply ignoring non-existing fields on the client lead to hacking attempts or other problems?

To get the behavior we want all we have to do is catch the NoSuchFieldException directly in DefaultSFSDataSerializer.setObjectField instead of letting it propagate up to sfs2pojo. It would be great if the client library could just support behavior like this out of the box.

Thanks,
Markus

[Lapo]

Hi Markus,
the problem that you are bringing up is no small potato

Making the object serialization resilient to inconsistencies would cause lots of programming error to go undetected. If you forget to set a field or two the serializer won't budge and you'll never know what's going on.

To get the behavior we want all we have to do is catch the NoSuchFieldException directly in DefaultSFSDataSerializer.setObjectField instead of letting it propagate up to sfs2pojo. It would be great if the client library could just support behavior like this out of the box.

This kind of flexibility can be achieved using the SFSObject. All it takes is writing the toSFSObject() method for your model classes, which in turn will give you the ultimate control over which fields are expected both sides of the communication.