Json file change - do we HAVE to delete old installation?

[universalenglishinch]

I am still learning Corona so I hire programmer for my work now.

One thing I don’t like is he keeps telling me I have to delete the previous installation before I can install the new installation.

I tell him, No other professional companies make you delete previous installations.  He should be able to handle it with code.

He said not if there is a change to the json file.  I tell him it doesn’t make sense.

Is he right?  If he makes change to json file then do I have to delete old installation before I can update new version?

I just worry we find an error in production - so all our customers would have to delete the installation first???  That sounds like a nightmare.

Please let me know if he is right.

Thanks!
 

[tomaswesterlund]

That is not correct.

I’m gonna tell you a little bit on how I make the users update my app (without deleting them):

I have an application that gets updated pretty frequently (because of new game forms, minor bug fixes etc.) and sometimes I don’t want the customer to have a to old version of the application so I make sure that when the application starts that the version of the application is checked against my server and there I set a minimum version required. If the version is to old they should update (they get redirected to Google/Apple Store) or otherwise the application starts up.

This method makes sure that if I do minor bugs I don’t force the users to update but if I implement a new game form or find a critical bug I can force the users to update.

Then in my code I make sure that all the parts (mostly the database) are updated correctly i.e. no rows are deleted, the whole database are not dumped or anything like that just updated.

Now, regarding your programmer:

I’m not sure what a JSON file is. JSON is a format on how to transport data. He might just referring to a text file with JSON data?

https://en.wikipedia.org/wiki/JSON

Tell him to explain better WHY he can’t update your application without deleting it first or hire a new one. We’ll gladly help your programmer with his problem, it just might be a simple misunderstanding.

Best regards,

Tomas

[Alan_PlantPot]

@Tomas You can save a file with a .json extension, so I assume that is what the programmer is referring to (you are correct that it is essentially a text file containing JSON data).  

@universalenglishinchina - if the programmer genuinely believes reinstalling is the only way to work around changes to the JSON data, then it sounds like your programmer is not very experienced.

My guess would be that the programmer is turning the JSON data into a Lua table, and every time they make changes to the overall structure of that table the easiest thing to do is to ask you to reinstall. If the app is still in an early stage of development then this is not a problem - if I’m honest I sometimes do the same myself. If the app is released, then you are correct that this is not suitable.

The programmer should add some Lua code to the app to check the structure of the JSON data, and if it does not match the expected structure then it should be adjusted in the Lua code accordingly and then re-saved.  

E.g. - initial json data

--myJsonFile.json {myvariable = "hello"} --myLuaFile.lua local mydata = json.decode("myJsonFile.json") local variable1 = mydata.myvariable --this is ok

Then the file is changed to:

--myJsonFile.json {myvariable1 = "hello", myvariable2 = "world"} --myLuaFile.lua local mydata = json.decode("myJsonFile.json") local variable1 = mydata.myvariable --this is no longer ok --should instead be something like this to account for the change: if mydata.myvariable then variable1 = mydata.myvariable elseif mydata.myvariable1 then variable1 = mydata.myvariable1 else variable1 = "" end

[roaminggamer]

I actually side with your developer on this.

During development, he may be making wild changes to how data is stored and organized.  It isn’t reasonable for him to be attempting backward compatibility with old data formats.  This will only inject extra effort and bugs into the design.

Additionally, by doing a clean installation, he and you both know that any bugs your find are not related to a change in data storage or some other junk left over from the last build.

Yes, once you get to a final build, the subsequent releases should be able to load old data files and handle differences between the old format and any changes.  i.e. Release 1 may use one format and release 2 may change it, but should still be able to load and convert release 1 data to the new format.

[universalenglishinch]

I understand for development, you want to do things quickly.  BUT

• He created all code
• It was NEVER released to the customer so no need for backward compatibility
• He said it was IMPOSSIBLE to do a build without doing a clean delete if there was a modification to the json file.
• He said, if a production error occurred he would make sure json file was not modified so that clean delete was not necessary. (I didn’t see how this was possible if a database change was necessary because of a bug found).

For all those reasons I posted this question.  I just didn’t see how he could be correct with his statements so I asked here. 

Thanks!

[rob]

Back to what Ed said, in my experience building my own apps settings files, which are saved in the documents directory does not get overwritten when you update the app. During the development process, as features are added and refactored that settings file will likely change and doing a clean start is a good thing.

Once it’s released, expecting people to delete their app isn’t real, and most developers will include code in updates that will update the settings files (typically saved as JSON) when the app starts to the new format.

Rob

[epicurus101]

This isn’t something that’s immediately relevant to me, but I’m interested for the future.  From the above I take it that if I publish an update to an app, and the user just installs the update without deleting the old build, all files in the documents directory are preserved, is that right?

Also, does that apply equally if you’ve switched framework?  I’ve published a game which I created in Codea, and I’m considering porting it to Corona and updating it. As long as I publish it as an update to the existing app, can I rely on the documents directory (with the user’s save file) from previous builds still being there?

[roaminggamer]

@epicurus101

#1 Will your files, settings, etc still be in ‘documents’ when you install an update.

Yes

#2 Can you change frameworks and install an update made with the new framework, but still be able to read the ‘documents’ folder?

Unless you mean you’re switching from another framework to Corona, my answer is " Heresy!  Heresy I say!"  ( I know you said to Corona, but I had to take the joke to its end.)

Actually, I don’t know.  You’d have to test this.  If you do, please share your results and some details on the from framework.

[rob]

I don’t have an answer for #2 either, but it would seem to me that if you use the same Bundle ID, it should be treated as the same app.

Rob

[tomaswesterlund]

That is not correct.

I’m gonna tell you a little bit on how I make the users update my app (without deleting them):

I have an application that gets updated pretty frequently (because of new game forms, minor bug fixes etc.) and sometimes I don’t want the customer to have a to old version of the application so I make sure that when the application starts that the version of the application is checked against my server and there I set a minimum version required. If the version is to old they should update (they get redirected to Google/Apple Store) or otherwise the application starts up.

This method makes sure that if I do minor bugs I don’t force the users to update but if I implement a new game form or find a critical bug I can force the users to update.

Then in my code I make sure that all the parts (mostly the database) are updated correctly i.e. no rows are deleted, the whole database are not dumped or anything like that just updated.

Now, regarding your programmer:

I’m not sure what a JSON file is. JSON is a format on how to transport data. He might just referring to a text file with JSON data?

https://en.wikipedia.org/wiki/JSON

Tell him to explain better WHY he can’t update your application without deleting it first or hire a new one. We’ll gladly help your programmer with his problem, it just might be a simple misunderstanding.

Best regards,

Tomas

[Alan_PlantPot]

@Tomas You can save a file with a .json extension, so I assume that is what the programmer is referring to (you are correct that it is essentially a text file containing JSON data).  

@universalenglishinchina - if the programmer genuinely believes reinstalling is the only way to work around changes to the JSON data, then it sounds like your programmer is not very experienced.

My guess would be that the programmer is turning the JSON data into a Lua table, and every time they make changes to the overall structure of that table the easiest thing to do is to ask you to reinstall. If the app is still in an early stage of development then this is not a problem - if I’m honest I sometimes do the same myself. If the app is released, then you are correct that this is not suitable.

The programmer should add some Lua code to the app to check the structure of the JSON data, and if it does not match the expected structure then it should be adjusted in the Lua code accordingly and then re-saved.  

E.g. - initial json data

--myJsonFile.json {myvariable = "hello"} --myLuaFile.lua local mydata = json.decode("myJsonFile.json") local variable1 = mydata.myvariable --this is ok

Then the file is changed to:

--myJsonFile.json {myvariable1 = "hello", myvariable2 = "world"} --myLuaFile.lua local mydata = json.decode("myJsonFile.json") local variable1 = mydata.myvariable --this is no longer ok --should instead be something like this to account for the change: if mydata.myvariable then variable1 = mydata.myvariable elseif mydata.myvariable1 then variable1 = mydata.myvariable1 else variable1 = "" end

[roaminggamer]

I actually side with your developer on this.

During development, he may be making wild changes to how data is stored and organized.  It isn’t reasonable for him to be attempting backward compatibility with old data formats.  This will only inject extra effort and bugs into the design.

Additionally, by doing a clean installation, he and you both know that any bugs your find are not related to a change in data storage or some other junk left over from the last build.

Yes, once you get to a final build, the subsequent releases should be able to load old data files and handle differences between the old format and any changes.  i.e. Release 1 may use one format and release 2 may change it, but should still be able to load and convert release 1 data to the new format.

[universalenglishinch]

I understand for development, you want to do things quickly.  BUT

• He created all code
• It was NEVER released to the customer so no need for backward compatibility
• He said it was IMPOSSIBLE to do a build without doing a clean delete if there was a modification to the json file.
• He said, if a production error occurred he would make sure json file was not modified so that clean delete was not necessary. (I didn’t see how this was possible if a database change was necessary because of a bug found).

For all those reasons I posted this question.  I just didn’t see how he could be correct with his statements so I asked here. 

Thanks!

[rob]

Back to what Ed said, in my experience building my own apps settings files, which are saved in the documents directory does not get overwritten when you update the app. During the development process, as features are added and refactored that settings file will likely change and doing a clean start is a good thing.

Once it’s released, expecting people to delete their app isn’t real, and most developers will include code in updates that will update the settings files (typically saved as JSON) when the app starts to the new format.

Rob

[epicurus101]

This isn’t something that’s immediately relevant to me, but I’m interested for the future.  From the above I take it that if I publish an update to an app, and the user just installs the update without deleting the old build, all files in the documents directory are preserved, is that right?

Also, does that apply equally if you’ve switched framework?  I’ve published a game which I created in Codea, and I’m considering porting it to Corona and updating it. As long as I publish it as an update to the existing app, can I rely on the documents directory (with the user’s save file) from previous builds still being there?

[roaminggamer]

@epicurus101

#1 Will your files, settings, etc still be in ‘documents’ when you install an update.

Yes

#2 Can you change frameworks and install an update made with the new framework, but still be able to read the ‘documents’ folder?

Unless you mean you’re switching from another framework to Corona, my answer is " Heresy!  Heresy I say!"  ( I know you said to Corona, but I had to take the joke to its end.)

Actually, I don’t know.  You’d have to test this.  If you do, please share your results and some details on the from framework.

[rob]

I don’t have an answer for #2 either, but it would seem to me that if you use the same Bundle ID, it should be treated as the same app.

Rob