In my app I retrieve, parse and save XML data to a sqlite database via CoreData. This data is essential to the operation of the app and needed for offline use. My minimum target is iOS 4.3
This is not user generated so i cannot store it in /Library/Documents
Source : https://developer.apple.com/library/ios/#qa/qa1719/_index.html
Because of this, I have no other choice but to store my data in the /Library/Caches folder. iOS may purge this directory at any time.
Does this mean that anytime my app downloads new data ( via xml ) and saves it using ...
[managedObjectContext save:&error]
... I will first have to check to see if MyData.sqlite still exists?
If it doesn't then I will need to "restore" the CoreData stack then alert any other object that may need to get a new pointer to, or modify it's managedObjectContext's persistentStoreCoordinator.
This solution does not seem right, but based on iOS 5.0 not supporting "do not backup", Apple's Data storage guidelines, and the way purging of the /Libraray/Caches directory works, I don't know how there is any other alternative.
Nick Lockwood's wonderful StandardPaths library has an opinion; this library stores application-private, not-to-be-pruned, not-to-be-backed-up, persistent-across-app-updates data in Library/Application Support/Offline Data by convention.
You are correct though that, for iOS 5.0 and older, any attempt to prevent a file from being backed up will be ineffective.
On iOS 5.0.1 backup-prevention is implemented as follows (source):
const char *filePath = [[fileURL path] fileSystemRepresentation];
const char *attrName = "com.apple.MobileBackup";
u_int8_t attrValue = 1;
setxattr(filePath, attrName, &attrValue, sizeof(attrValue), 0, 0);
On iOS 5.1 and above backup-prevention is implemented as follows (source):
[fileURL setResourceValue: [NSNumber numberWithBool: YES]
forKey: NSURLIsExcludedFromBackupKey
error: &error];
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With