I have an app that is running in the simulator. I read and write from a sqlite3 data source. However, if i restart the app, then all datg that i had previously wrote to the db is lost.
The data is always in its original state.
Now back when i was developing this app i thought i read somewhere that data can not be persisted via iphone simulator.
Can anybody confirm or deny this?
Thanks!
You need to place your db file in a writable place, e.g. in the Documents folder. All the bundle files are read-only files.
If you are distributing an initial database with the app, you will need to copy it to Documents (or another folder) and use the copy.
You also need to ensure that you close the database connection in your application is closing (i.e. you receive a applicationWillTerminate message).
Related
I worked on app in which user can add images and make notes about those images, which i stored in sqlite and i store cards in document directory. I have enabled file Sharing option in app so user can keep backup of app's data manually in her PC via iTunes.
Please consider this scenario: the user connects the device from time to time to iTunes, and the synch process takes place. however, she does NOT go into the File Sharing option which is one way to backup manually the data in PC. now, she drops the phone in the bathtub and it does not work or due to some other reason she lost her device.
my question: when she gets a new phone, can she recover her data?
if yes, then how could we do this?
if no, then what is the correct way now to backup the third party app data.
If a user installs an an app which uses iCloud with a UI(Managed)Document, then uses the app, creates data which is saved to iCloud and then deletes the app on his phone, the iCloud data will stay on the device (transaction logs etc.). If the user reinstalls the app it will try to use these old files.
I have the following two problems with that:
The iCloud documents could have changed in the meanwhile and there might be problems when the user has no network connection on the first launch after reinstalling the app.
The iCloud documents for this app could have been deleted by the user (via settings or in Mac OS Finder in the user library). Now, when the user has no network on the first launch after reinstalling the app, the app might think that there is an ubiquity container with data even though it's already deleted (app might crash).
This is not very easy to test but I have definetely crashes and malfunctions for those two issues. E.g. NSMetadataQuery shows me results for documents which do not exist in iCloud because they have been deleted (but they existed on the deletion of the app).
Is there any easy solution to this? I thought about deleting the local iCloud data on the device when the app is launched for the first time - but how can this be done?
It can't be done. If you delete an iCloud document locally, you delete it everywhere-- eventually. The iCloud APIs have no concept of managing local copies independently of the iCloud service, so if you delete one-- even with the network down-- the iCloud ubiquity daemon will send a delete command to the service at the first opportunity.
The closest approximation that current APIs would allow would be:
Check whether the network is reachable
If it's not reachable, do not attempt to access any iCloud documents (because as you note, the information might be stale).
If and when the network comes up, try to open all existing iCloud documents. (On iOS, iCloud updates are only downloaded on demand, so you need to create that demand).
If that's not good enough (and let's face it, it's not good enough), file a bug with Apple and hope for the best.
Switching to custom generated device UUID's is turning out to truly be a nightmare! I am hoping someone has come across this before and might know a way to deal with it.
Assume a user has an application with a data set of 500,000 (small) records, its not feasible to simply copy the entire db of a device and merge them. A user has this application installed on an:
iPhone,
MacBook
Android tablet.
When connected to the same physical network, each device can see each other and can initiate a synchronisation.
To achieve three way data synchronisation (that does not depend on a central server or an internet connection).
Each device keeps a list of timestamped changes.
Each device knows the last time it synchronised with each of the other two devices.
When a device sees another device, it sends through all known changes since the last time they spoke to that device.
If a new device is discovered, no problem just send through all data ever entered.
The problem comes along if a user backs up their iphone or ipad, and restores it onto another iphone or ipad. Under this scenario we are ending up with a user that has two devices on the local network with the same UUID. Updates end up (randomly) going to one or the other identically identified devices.
I know we can continue to use the device unique identifier for now, but I am worried whats going to happen once its gone!
On application start you search for a file in the applications documents folder called udid.txt. If this file is not available create it and generate your custom UDID, save it to this file. Use the following function to add a flag to this file, to exclude it from the backup and sync routines.
#include <sys/xattr.h>
- (void) AddSkipBackupAttributeToFile: (NSURL*) url
{
u_int8_t b = 1;
setxattr([[url path] fileSystemRepresentation], "com.apple.MobileBackup", &b, 1, 0, 0);
}
The problem with this solution is that a user might use iPhoneExplorer or something similar to change the UDID. Try to encrypt or hide the file to prevent him from doing this.
Note: Works only since iOS 5.0.1.
You can instead store your generated device UDID in a file in the Caches directory, where it will not be backed up. When a backup is restored onto a new device, the database will be present but there will be no UDID file. In this case create a new UDID; the other instances will see this as a new instance and can push any recent changes across. You might want to change the logic so the other instances will query the timestamp on a new UDID instead of assuming the new instance is totally empty.
Before iOS 5.0, your UDID file will not be automatically deleted by the system. However in iOS 5.0 you will need to put up with the fact that it may get purged in low disk space situations. If that happens, just follow the same procedure as when restored onto a new device: create a new UDID; the other instances will see this as a new instance and push recent changes across.
As Floix said, there is a new mechanism in iOS 5.0.1 (yet to be released) which will let you specify that the file should be neither backed up nor purged.
I am having an application in which I am having SQlite database too ..If I delete that Application accidentally. Is there any way to get back the same application with the same database.
Or Is there any way to keep database alone in a separate place inside iPhone memory so that we can recover after application delete if needed.
Please tell me how to achieve the above?.
Regards,
V.K.
Every iPhone app runs in a "Sandbox", which is where it stores its application files and databases. When you delete the app, the whole sandbox is deleted, including your SQLlite database. There is no way to write it outside of the sandbox short of having another app that listens on a URL and having the app in question write to that URL.
When does data get restored for an app? What if I save data in the app's document directory. Then they sync with iTunes. Now iTunes has a backup. Will that data be populated to another device when they sync that new device to their iTunes or will they just get a clean install of my app? I'm trying to figure out how to keep track of a subscription in app purchase and was wondering if I could keep record in NSUserDefaults or some other local store.
Backups are per-device. So a backup of your iPod will not be restored to your iPhone. In other words, there is no sync.
Many times iTunes fails to create complete backup of all the iPhone data say it be contacts, message, mails etc. This type of problem may occur due to not installing iTunes properly. So, you should check whether iTunes have been installed correctly or not. In case there is no problem with iTunes then it is possible that you are trying to create backup of the files which can not be backed with the help of iTunes. To overcome with this issue you need to make use of iPhone backup application. By using this tool you will be able to prepare backup of all the files within minutes safely.
If the user backs up to iTunes, and then restores their backup to another device (maybe they lost their original iPhone), the contents of the app Documents directory will be put on the new device. Anything in the tmp folder won't be backed up or restored like this, but the Documents folder will.
However, that's not the best way to store the in-app purchase information. You should be storing that on your own server and keeping a count of the number of times the purchased content has been used. Inform the user that they can use it a certain number of times (say three) and after that they will have to buy it again. I'm not exactly sure of any details beyond that (like how to verify their identity) but it should get you started.