Will updating an app with a modified plist screw up the user's data?

cocos2d for iPhone » Programming » cocos2d support (graphics engine)

Will updating an app with a modified plist screw up the user's data?

(31 posts) (10 voices)

Started 3 months ago by KeitZer
Latest reply from KeitZer

Tags:

No tags yet.

12 Next »

KeitZer
Member

Because I plan to use a coin/currency system in my game, where coins can also be bought with real money.

The plist i'm referring to is going to store data like which upgrades they've gotten, levels unlocked, etc.... And I don't want people complaining "blah blah, spent $5 or whatever and it reset my game, lost all my items, etc"

So ... if I add rows to the plist that's already been created, and update my app, will it reset the user's plist to the now larger, default plist? Or will it just add those rows to their plist.

Because the last game I did, I made a separate one, but I can't really do that here.

edit: i'm asking because i DO plan to update with more items, levels, etc, and I don't want to change my code that much when I do so (because in all honesty, I shouldn't)

Posted 3 months ago #
bryce
Member

You should be copying the plist to the users documents (or better yet library) directories so they don't get overwritten when you do an update. If you didn't, you're going to overwrite their data when they update their app.

You should add code to add the additional rows if they don't exist during startup and not overwrite the entire plist.

just my 2c

Posted 3 months ago #
KeitZer
Member

hmm.... doesn't apple automatically save the plist when they download the app?

Because I know when i do testing, sometimes the app crashes because of the plist and i have to delete the app from my device.

Idk... i'll look more into it, hopefully I can without issues

Posted 3 months ago #
Birkemose
Moderator

Apple will not overwrite anything you have saved, the layout prevents it. The only way to make things go away, is if the user wipes the app from his device.

Posted 3 months ago #
MichaelB
Member

If you're storing things that people buy, a plist in the documents folder isn't very secure. You might look at using the Keychain to store the data, much safer from somebody tampering to get more game-cash. And I believe that data in the Keychain will stick around even if the app is deleted and re-installed.

(Or iCloud key-value store would let purchases and unlocks transfer between devices too, which is nice.)

Posted 3 months ago #
xmawiel
Member

Will data stored using NSFileManager in NSCoding be stored in the iCloud without using NSUbiquitousKeyValueStore?
Also, will NSCoding data still be there if user deletes our apps and reinstalls it? Is there a better way to store data without using CoreData?

Posted 3 months ago #
Birkemose
Moderator

@MichaelB
I am sorry, but I will have to say rubbish.
There are no security issues with storing data in plain plist's
You must be thinking "Android"

@KeitZer
Just to clarify. Apple will not overwrite anything you have previously saved, on an update to a newer version. That can only happen if the user wipes the app, so it is all your responsibility.

Posted 3 months ago #
MichaelB
Member

I suppose security isn't the right word, it's ease of editing the data in the file. If it's just a plain plist without anything else, a jailbroken iPhone could get a file manager app to access and edit the data. I think you can backup to a computer and edit there then restore to change the file too.

If a plist, this would help for most cases.
[[NSFileManager defaultManager] setAttributes:[NSDictionary dictionaryWithObjectsAndKeys:NSFileProtectionComplete, NSFileProtectionKey, nil] ofItemAtPath:path error:nil];

All depends how much you want to make sure people couldn't edit the data.

Posted 3 months ago #
Wayne
Member

I use something from my microcontroller assembly days where I always store a "magic number" with my stored data. I only change this number when the format/structure of the game stored data has changed. For example if I've added some new feature that changes say "player health" to "player energy" and "player strength". Then on app launch, I check this magic number. If it's different from the magic number that was stored, then I know the player data needs to be reformatted. I then reformat the data before game start, and save the new data and magic number. Different magic numbers are also set to reformat the player data differently to match the new version too.

Posted 3 months ago #
KeitZer
Member

@MichaelB

I'm planning to have coins obtainable in-game, as well as purchased (consumable style), so the only thing i'm storing is how many coins they have (as an Integer in a plist), and which items they have (each item is it's own row in a plist with a YES or NO value)

@Birkemose
Cool stuff, that makes things easier on my end.

Posted 3 months ago #
KeitZer
Member

So uh... just to be triple-sure, if I add a data row (of type String, let's say) to the GameData.plist that's already been saved to their device, will the update add the data row? or will the application not update the row, and crash when trying to reference it?

Posted 3 months ago #
KeitZer
Member

Well, that's exactly what happened when I tried it on my device... Loaded the app up, stopped it, added a row to the plist, added a line of code to retrieve the information [tempArray addObject:[plistDict valueForKey:@"itemSunglasses"]]; and it broke, saying the object cannot be nil.

edit: i checked, and the key in the plist, and the in the line of code above are the exact same (no spelling errors)

=(

how would i be able to tell the device (or whatever) that there's more data in the plist than before, but also keep the old data that was already there, because like I said, i DO plan to update with more items/levels, which would require me to add rows to the plists already made

Posted 3 months ago #
rakkarage
Member

if you make a schema and if core data deals with plists core data can handle this for you?
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreDataVersioning/Articles/Introduction.html
else maybe you have to detect version and do migration yourself?

Posted 3 months ago #
KeitZer
Member
what if I made a new plist for every version, and a new method in my PListData class that took all the data from the old plist (say, version 1.0's), and dumped it into the respective keys for the new version's plist?

like:
```
if (![PListData updatedToVersionTwo])
{
    [PListData transferFirstPlistToVersionTwo];
}
else if (![PListData updatedToVersionThree])
{
    [PListData transferSecondPlistToVersionThree];
}
else
{
    break;
}
```
etc, looping until their game is completely up-to-date (that way it covers all the people that update from version 1.0 to say, 1.5)

edit: for my next game i'm probably going to use NSUserDefaults, lol

edit2: Or would it just be easier to make a separate Plist for each update, housing the respective items/levels for that update....

like, instead of trying to force some massive plist to be the one I use, i could just have multiple ones, each version'd off with their respective items/levels listed
Posted 3 months ago #
ildu
Member

I'm a little confused. I thought the general divide was that you use .plist for stuff that doesn't mix with user data and then another format, say XML, to contain anything having to do with user data. The XML structure you couldn't change (for fear of losing the user's history), but the .plist you could change along with the code that uses it. So, when adding for example a new level to your app, you would add the level parameters as a new item to XML, containing information that is either not going to change or is unique to the user, such as is this level unlocked or not. Then you would add the fixed attributes of the level to the .plist, such as the position coordinates of the level link in the level select screen. XML - Data that you don't intend to change and data that is unique to the user, .plist - Data that has nothing to do with the user.

Is this about correct? How would this system work in KeitZer's case where you need to add for example a currency system? I would imagine you add a value set in the user data XML to store the currency or one for whether an extra feature is unlocked or not. The code then checks for the those values where appropriate and the .plist only complements that data if necessary, cataloging for example how much a new feature or addon costs (but nothing beyond that).

Am I completely off the track? Creating a new .plist for each version would seem very unpractical and you would also need to build a system that manages the update of the file.

Posted 3 months ago #
KeitZer
Member

Well this got me thinking... how does TexturePacker do it? Since they use Plists to store the data, but when you re-publish a sprite sheet, it also updates the plist, but it doesn't crash....

So they apparently have a field called SmartUpdate, that has something that looks like this: $TexturePacker:SmartUpdate:b96af3dce3e3762da (and a bunch more stuff like that after)

Does this get checked when reloading the app or something? Since it's obvious that cocos2d works with it

Posted 3 months ago #
Birkemose
Moderator
@ildu
You certainly can use a plist for user data. For small amount of data, you normally use NSUserDefaults. For larger amounts of data, you can then use plists, but as they are keyed by strings, they obviously are not very fast, so for large amounts of data, you would chose a dedicated database. SQL-lite is common I think.

@KeitZer
I am not really sure what you mean? TexturePacker modifies the plist, and xcode then compiles it all, and place it in a read-only bundle. Why should it crash?
I use a small wrapper I made of NSDictionary which adds a default value, so if the entry does not exist, it simple returns a default. Looks something like:
```
userGold = [ DATABASE readInteger:@"usergold" default:0 ];
```
Until the user have bought gold, it will simply return 0. When the user buys some gold, you would then do like:
```
[ DATABASE writeInteger:@"usergold" value:( goldJustBought + [ DATABASE readInteger:@"usergold" default:0 ] ) ];
```
Posted 3 months ago #
callispo
Member

@Birkemose, I ran into this issue with my app. Updating existing plists. How I implemented it was I added a version number field to my plist file. When the app is launched, I search for existing plists configurations. If there arent any, I create new files by copying them from my bundle. If a plist already exists, I look for version number information, and then run the loop from existing version number, to the version number specified in bundle's plist, updating the existing plist to a newer version each time.

This way, I dont mess up with the existing data and every time I make changes to config file, I only have to write a function that would update the the previous version to current one.

Posted 3 months ago #
KeitZer
Member

@callispo that sounds like exactly what I want

@birkemose I say TexturePacker because they use plists to reference their data, and when a plist is already on your device, but you re-publish a sheet, it modifies the plist, but the device reads it just fine, however when I go to modify the plist, the device crashes.

Maybe it makes a new one every time and I just don't realize it.

Posted 3 months ago #
Andreas Loew
Member

The smart update field is a feature of TexturePacker. It stores a hash that contains the texture packer version, the parameters the plist was created with and hashes over the times of the source images.

If you republish in TexturePacker it checks if the parameters + file dates etc. match that hash. If it matches the rebuild of plist & image file is skipped. This is used to speed up build times - especially when using TP inside an Xcode project.

But this field has nothing to do with cocos2d - cocos2d does not even know that it exists.

Posted 3 months ago #
Andreas Loew
Member

@KeitZer How do you try to modify the plist? You can't overwrite it in it's position since it is stored in a read only section on the device. If you want to modify it you have to copy it to the documents folder or temp - depending if you want it to be included in the backups or you can regenerate them.
At least you can't write them in-place.

Posted 3 months ago #
KeitZer
Member

What i mean by modify is... say I add a data row (of type string, with value NO) to the already-on-the-device plist... when i go to run the app (or theoretically update the version), the app crashes because the data row is technically not there (as it didn't update/modify the old plist with the new data row)

I'm just trying to think of an easy of way updating my apps so the user doesn't lose their progress/items

Posted 3 months ago #
Birkemose
Moderator

@KeitZer
You sound seriously confused.
The bundle files ( the files which are shipped with your add, ex the plists from TexturePacker ) are all read-only. You can not modify them. I think this is where you go wrong. That TexturePacker can create a new plist in the development environment, has nothing to do with the fact, that the files are changed to read-only when you build the app.

Posted 3 months ago #
KeitZer
Member

@Birkemose so does that mean I can use a .pvr.ccz / plist combo with TexturePacker (as my sprite sheets), I release the app with, say, 10 sprites on it.. and update with 2 more on the sheet / plist, will the app crash? or will it read it no problem?

Since (from what it seems), that's exactly the same thing as updating my OWN plist with new information (and not actually modifying any of the old data)

Posted 3 months ago #
Birkemose
Moderator

@KeitZer
It will read no problem. No, it is not the same. You can NOT modify a bundle file programmatically.

Posted 3 months ago #
KeitZer
Member

But I'm not trying to do it programmatically... I'm manually adding the data rows in Xcode using the "plist editor" they have built into Xcode 4

Posted 3 months ago #
Andreas Loew
Member

If you add say 5 sprites in TexturePacker and create a new plist and pvr.ccz you also need to rebuild the complete bundle. That is go to Xcode, press build. If you want to put that on on the AppStore you need to upload the new complete bundle. So everything should be fine.

If you want to save user's progress you must create separate data files you can store in the documents folder of your installed app. These will be kept untouched when upgrading the application.

But you can't modify any of the files on the device which are part of the bundle somebody downloads through Appstore. You can only modify them in Xcode and upload a new bundle to AppStore.

Posted 3 months ago #
Andreas Loew
Member

If you manually add data to the generated .plist file in Xcode and save it to the device it should be fine - but not of much use.
If you manage to add the lines without creating an invalid plist or screw up the information (e.g. try to change coordinates) the data should be there.
But you won't be able to make use of it except you read the data on your own.

Cocos2d reads the plist and extracts all values it needs - ignoring other data.

If you want to access your new data you need to write your own reading functions.

But in this case I doubt if this is useful. Why add to an automatically created data file and go through the hustle to update it manually? Why not keep the data in a separate file?

Posted 3 months ago #
KeitZer
Member

Ok... so for adding new sprites/level background, I should make a new sprite sheet...

and for new user data (eg, new items to the store), I should make a new plist (and handle the loading/saving of the new plist?)

Sorry if it's taken so long, I just want to be 100% certain I do it right, and no users complain if something goes wrong.

Posted 3 months ago #
Andreas Loew
Member
Ok... so for adding new sprites/level background, I should make a new sprite sheet...

Right - or add to an existing one

and for new user data (eg, new items to the store), I should make a new plist (and handle the loading/saving of the new plist?)

That depends on how you handle the data. But I would strictly advice not to mix data like object's price, amount, whatever with the sprite sheet. Keep graphics and object's data separated! You can of course reference data from the sprite sheet.

E.g. if you have a hamburger and a coke in your store, create a sprite sheet with both sprites and create a data file:
```
<key>hamburger</key>
<dict>
    <key>displayName</key>
    <string>Mac Whoooper</key>
    <key>price</key>
    <string4.99</key>
    <key>iconsmall</key>
    <string>hamburger/small.png</key>        
    <key>icondetail</key>
    <string>hamburger/big.png</key>           
</dict>
```
Posted 3 months ago #

RSS feed for this topic

12 Next »

Reply »

You must log in to post.