I'm going to need to update my iPhone app on the app store at some point.
I’m using secure storage functions (s3eSecureStoragePut) for save data that creates an appdata.i3d file.
When I update the app I want to preserve the players save data, how can I ensure this done?
s3eSecureStorage is a bit misleading, it is not secure and this is a historical name related to the Brew and Symbian platforms. Essentially all this is doing is writing to a file so it will be preserved on app updates assuming you don't write over it.
Related
Apologies if this has been asked before but I couldn't find anything specific to my situation..
I've been tasked with creating a new version of an app already on the market place.
Unfortunately, the client only has access to the binary and not the source code as the previous development team didn't provide this information.
The client has been unable to get in touch with the previous development team so I can assume getting a hold of the original source code is off the table.
I was wondering, in a case like this, how does the iOS upgrade procedure work?
As an additional question, is it possible for the new app to access the data stored by the old app and if so, can anyone point me in the right direction on how to go about doing this please?
Thank you!
To make the update you must have the same bundleIdentifier as the current version. This will be displayed in iTunes Connect.
To get the stored data, you should use a tool called iFunBox.
Here's a little tutorial on how you can do it:
Steps for using iFunBox
Download the current version of the app
You should also use the apps functions, so the app saves the data you wish to extract.
Connect your iDevice to your Mac/PC
Download and install iFunBox (link here: http://www.i-funbox.com)
Launch the program and navigate to your device
Press "User Applications", then your application
Find the data the app stores
The NSUserDefaults plist-file is located in "Library" -> "Preferences" and is called com.yourCompany.appName.plist
A lot of apps also stores files in yourApp/Documents/
You can also explore the apps folder and look for the data you need. Hope this helps :)
If you have access to the iTunes Connect account, with which this app was published the problem is not too large: you can update app with any binary that have the same application id (bundle identifier) and larger version number.
You definitely can have access to the data of previous version - either it's stored in NSUserDefaults or app Documents folder etc., but you should have a clue of its format (e.g. keys of NSUserDefaults) - some reverse engineering of binaries can help.
You must know the bundleIdentifier and use the same otherwise the apps wont update.
The version number must also be higher than the current one
Also the data saved in the old app can be read but you need to know in which format it is.
How do I keep the users data when they get an update.
I use the Marmalade SDK to develop an app and I saved the user data to bin files and text files, I used the ram:// prefix when saving the files.
If I delete the app and get it from the app store again with the could symbol It had lost all its user data. I would like to release an update that doesn't delete the users data. The app does not come with any user data files, the app creates them as you use it.
Edit: Marmalade is cross platform but my question is for iOS only and the app has been publish, I am asking with respect to an existing app.
Deleting the app from the device, also removes it's sandbox. So any user data stored locally is deleted. This is expected behaviour.
If the user data comes from the web, then you just need to download it again.
Have you read the tutorial for dealing with files?
I have never used that sdk but:
rom for the read-only portion of your apps data area and is read only.
ram for the writable portion of your apps data area. This drive is the only drive that is guaranteed to exist across platforms
rst for a removable memory card on the phone or tablet
raw for paths that will be passed directly to the underlying operating system without modification. (not supported on all platforms)
tmp for a system temp folder, outside of the s3e data area. (system temporary folder and currently only available on iOS)
So maybe you could try rst:// and get the expected result?
I just learned the basics of integrating SQLite3 into an iPhone app, but I still don't really know where or when to use it. Is the SQLite database just locally created on the device or will every app have its own database? If I for example want an app where the user can upload a recipe to the database, will other devices be able to fetch that recipe from the database or do I need something else to make that such of app? Sorry for the noob question but I can't find an answer..
An SQLite database, in iOS, is stored locally. That means that every iOS device has his own independent SQLite database.
Usually, in the case of the recipe you mencioned, you need a backend to sync information with other devices. You can update your SQLite database or just browse the information without a SQLite database behind.
Aditionally, in iOS you have one tool under your belt that it can be used to persist information locally : Core Data. There are some tools that can be used to sync core data information with a server like Parse.
Your app will have its own sqlite database. Your app can have 100 sqlite databases if it wants. It's just a file like any other file your app works with. It will be specific to your app in your app's sandbox. It will not be shared across devices. Just like any other file.
A SQLite database is just a file that you would put in your app's directory, and iOS apps are sandboxed so that one app can't read the files of another app.
If you need to share data from your app, you can have your app implement a URL prefix, and you read the data in your app, but share it using the system defined mechanism. Have a look here, here, and here for more guidance on the subject.
I would like to create a NSPersistentDocument in Mac OS X and read this document as a UIManagedDocument on iOS 7.
Is this possible?
Are both file formats compatible?
Thank you!
Interesting question - I can confirm that the basic core data files are compatible. I have a Mac app and an iOS app using the same file that gets synced using iCloud. The app is a document based app and currently I have been storing the actual database file in iCloud so the whole file gets sync'ed by iCloud.
This works fine but obviously if a user opens the file on two devices and is not careful about saving and closing there is a possibility their changes may be overridden.
Apple has approved the Mac app which uses standard NSPersistentDocument to create and save files. Unfortunately they have rejected the iOS apps with some obscure reference to not conforming to their data storage guidelines, saying that documents must be stored in /Documents directory if they need to be backed up to iCloud. Well if the user has selected iCloud then I store the files in the iCloud location provided by the API calls.
Anyway I am still waiting to hear back from them about what is specifically wrong with this approach since it seems to be the same one used by Pages and other document based apps.
If I try using UIManagedDocument then iOS creates a folder structure and stores the database inside this folder structure. The Mac app File->Open dialog then shows this folder structure as well as a file that essentially looks like a the normal sqlite file. But then perhaps OS X 10.8.4 does not implement the latest iCloud/Core Data stuff - who knows...
EDIT
Here is a link to code examples and videos showing OSX and iOS app integration using Core Data and iCloud. http://ossh.com.au/design-and-technology/software-development/uimanageddocument-icloud-integration/
I agree this is definitely possible. I'm using NSPersistent document on OS X 10.8/10.9/10.10 with a binary core data format (no wrappers - plain files). On iOS i'm using UIDocument. Core data works fine in both environments.
Apple says NSPersistentDocument does not support iCloud. It is more correct to say it isn't fully supported. Most of the NSDocument support (which includes iCloud Document Library access from 10.8) will work. Handling of conflicted files on open works.
You can't enable auto save (which is listed as a requirement for iCloud Documents in the iCloud Design Guide). Autosave works asynchronously and is definitely not supported by NSPersistentDocument.
So if you handle file saving, and conflicts, it is possible to use NSPersistent document. There are some quirks: so, for example, if an iCloud change arrives on OS X for a document that is open, the normal NSDocument response would be to automatically reopen the document. This doesn't happen - and there is no warning the file has changed until you are about to save the file. But at least there is a warning. On iOS it is easier to detect changes as they happen by using UIDocumentStateChangedNotification.
I am creating a quiz style app for iOS using phonegap. The app allows users to create then take the quizzes.
Currently I am using a HTML 5 database using phonegap APIs to store the test and results data. I am concerned though that the database can now be deleted by iOS 5.1 when the device storage gets full.
Is there anyway to mark the webkit cache folder where the database is stored so that it is never deleted? If this is not possible are there any suggestions for another way to store data that will always be persistent.
Yes, it's a pity that Apple did that in iOS5.1
It's possible to change the location of WebKit data calling a private API. You should be able to set the location to a secure folder like Documents. I did not test this solution yet, but look at this post : How do I enable Local Storage in my WebKit-based application?
Phonegap team is also working on that problem: https://issues.apache.org/jira/browse/CB-330
Antoher way is to use SQLite (same as WebSQL) with a phonegap plugin. That plugin save the database in the Document folder, that mean that the DB is not deleted and is saved by iCloud.
Here is the Native SQLite phonegap plugin : https://github.com/davibe/Phonegap-SQLitePlugin
Regarding this plugin, it's a little but slower than WebSQL in some case, and there are some differences between the WebSQL API, but here is an adaptor:
https://gist.github.com/2009518
You should also migrate the old WebSQL db file (stored in Library/WebKit or Caches directory) to the Document folder. Here is a code to do that :
https://gist.github.com/2009491
And if the data are important, you should save it to a server. I wrote a small lib to synchronize the SQlite DB to a server :
https://github.com/orbitaloop/WebSqlSync
There is a fix for both issues with Webkit storage and iOS 5.1
Storage moved from /Webkit to /Cache
Storage is not adjusted to updated folder structure on an App update under iOS 5.1 (WebKit Bug)
https://issues.apache.org/jira/browse/CB-330
This solution seems to be more safe than just changing the location of Webkit data calling a private API. While the App is running the Webkit storage locations are used. On resuming or terminating all data is backuped to the documents folder. Timestamps ensure that ab old backup cannot overwrite newer storage data (if the app crashes...).
The best: Users that are on an older iOS Version using an App with that fix in it, will not suffer damage lost in case of any iOS updates. Thats why one should not wait...
Instead of using an html5 database, I would send/receive the data via ajax (on a remote server, with php and mysql), preferably encrypted (and base64_encoded).