This post is a bit of a technical ramble, I’ve no doubt some developers will love reading it, but it might not be the most interesting for others, in that case, feel free to check out other posts on the NextSketch blog!
Now, for the horror story. It all started in June…
An interesting issue that we faced when testing and deploying NextSketch to the field, was the concept of data validation, sanitation and Serialization.
That's a lot of "-tions", so let's break it down.
In the field, once data has been created in a particular format, users expect your app to be able to parse it, no matter how many revisions into the future your app is.
This was quite a problem given that we used Java's ubiquitous Serialization mechanism. The thing that makes Serialization different from just reading and writing something like XML is that Serialization forces you to eventually bind the contents of the file to a real life object.
And if said real life object has changed, then you run into all sorts of errors. In reality, something like serialVersionUID can only take you so far, which limits the flexibility of the overall code base, turning it into a rigid mess and limiting extensibility.
Also, sometimes it’s necessary to clean said data and patch it where holes exist. Serialization made this a nightmare because of its rigid rules. In NextSketch 2 (coming soon!), we're exploring the concept of Validation Passes. A series of checks that patches incorrect data in older data sets.
Overall, while Serialization is no doubt easy, it’s a real pain to work with in cases like these. I would recommend some sort of text based format like XML because you don’t have to bind an object to it and because it doesn’t hamper extensibility.
Thanks for reading!
NextSketch helps developers work with ideas in new ways by integrating simple diagramming into their IDE. Available for all IntelliJ IDEs, check it out at www.NextSketch.ca
Top comments (0)