dave lery
asked on
Adding backward compatibility support for older json structure file
i have developed an app for android which stores a serialized domain model in a json file to the local storage. Now the thing is, sometimes i make changes to the domain model (new features) and want to have the option to **easily** load a previous structure of the json file from the local storage. How can i do this?
I thought of deserializing the object anonymously and use auto-mapper, but i want to hear other's opinions first before going this path.
If a code example of the domain model is needed (before and after), i'll provide. Thanks everyone.
I thought of deserializing the object anonymously and use auto-mapper, but i want to hear other's opinions first before going this path.
If a code example of the domain model is needed (before and after), i'll provide. Thanks everyone.
ASKER
Well, im looking for a more global way to do this rather than start comparing different domain models.
ASKER
Can you show me code example of your approach?
Can you give us an example of the sort of changes you make.
If you look at the components you have
a) An agent that reads / writes local storage for the data
b) A version of the data
What you want is to be able to launch a new agent that has new features but can still work off the older data.
The obvious answer is: never change anything - only extend. That way when an agent runs it does the following
1. Read localStorage
2. Use the data from LS to populate an internal data structure
3. Write internal data structure back to LS
That way you will always merge what you have in LS with what your application expects. The internal data model is populated with default data which is overridden by the data you retrieve from LS. Other values may be overridden as the application does what it does - but when it writes the data back to LS - it will now be the most recent structure.
The key to this working is don't change anything - only extend.
If you have to change something - then your app will need to look in more than one place for its value.
a) Is it in the new place (no)
b) Is it in the old place (yes) copy from old place to internal structure
Always merge from the version obtained in LS to the internal version - this way you don't carry across deprecated settings that are no longer needed.
If you look at the components you have
a) An agent that reads / writes local storage for the data
b) A version of the data
What you want is to be able to launch a new agent that has new features but can still work off the older data.
The obvious answer is: never change anything - only extend. That way when an agent runs it does the following
1. Read localStorage
2. Use the data from LS to populate an internal data structure
3. Write internal data structure back to LS
That way you will always merge what you have in LS with what your application expects. The internal data model is populated with default data which is overridden by the data you retrieve from LS. Other values may be overridden as the application does what it does - but when it writes the data back to LS - it will now be the most recent structure.
The key to this working is don't change anything - only extend.
If you have to change something - then your app will need to look in more than one place for its value.
a) Is it in the new place (no)
b) Is it in the old place (yes) copy from old place to internal structure
Always merge from the version obtained in LS to the internal version - this way you don't carry across deprecated settings that are no longer needed.
This question needs an answer!
Become an EE member today
7 DAY FREE TRIALMembers can start a 7-Day Free trial then enjoy unlimited access to the platform.
View membership options
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
Then when you get a JSON data structure, switch on the version number to determine correct parser to use.