I'm working on enhancing an existing application to use iCloud so the same data can be accessed on multiple devices.
I'm planning to use document-based storage and to use a file package (i.e. a directory of files represented as single file and handled by NSFileWrapper).
My main question is: are file package updates guaranteed to be atomic? If I open the app and a few files within a single document package have been changed, will iOS download them and then inform my app only when all subfiles are present and in-place? Or is there a risk that the files will come in one by one, leaving me with a potentially inconsistent package?
Also, my existing app uses SQLite (not through Core Data, but rather through a custom wrapper). Some parts of the app will clearly require a nice, indexed SQL database for performance. So my plan is to use the iCloud data as a reference store, keep an SQLite database in the Caches directory for performance reasons (or somewhere else strictly local to the device) and update the database based on what's in iCloud. Changes the user makes in the app will be recorded both in iCloud and in the local database. Is this crazy or reasonable?
so my answer to your main question is academic, because i don't have a test-base for testing this, but …
given that your directory is treated as a single-entity, if you coordinate using that entity as the item manipulated by your NSManagedDocument.
i'm basing this answer on my notes from learning about using NSManagedDocument to manage iCloud :
// Conflict
// - what if a device detached from the network changed a document that another device changed?
// and then the detached device re-attached and tried to apply the change and it conflicted?
// one must manage the conflict by looking for the InConflict document state.
// - when it happens, a decision must be made which version of the document to use and/or
// manage changes. probably want to set NSManagedObjectContext's mergePolicy to other than
// default (Error).
// - then update the old, conflicting NSFileVersion to no longer conflict (and remove those
// versions).
(yes, i take notes in objective-c comment format.)
Related
There're 2 folders in ~/Library/Caches in our iOS APP:
com.crashlytics.data
io.fabric.sdk.ios.data
It seems that they're used by Fabric?
I want to add a feature to delete all contents in the Caches folder, and I'm wondering if it's safe to delete these 2 folders?
If I delete the 2 folders when APP is running, what will happen if there're crashes in APP? Will the crash reports still be sent to Fabric?
Any advice would be appreciated.
Todd from Fabric here. It is not safe to delete these programmatically as they contain our crash report data. The folder Library/Caches/com.crashlytics.data/ is where crashes are uploaded from when your app relaunches. Thanks!
As per Apple Docs:
Put data cache files in the Library/Caches/ directory. Cache data can be used for any data that needs to persist longer than temporary data, but not as long as a support file. Generally speaking, the application does not require cache data to operate properly, but it can use cache data to improve performance. Examples of cache data include (but are not limited to) database cache files and transient, downloadable content. Note that the system may delete the Caches/ directory to free up disk space, so your app must be able to re-create or download these files as needed. (c)
So it means, that these folders can be removed even without any additional features in you app. Feel free to do it by yourself.
In my iOS app I am downloading a bunch of image files and saving them on disk in Library/Caches. Do I need to delete those files given iOS automatically clears them when its running low on disk space.
It depends where you save them. Read the File System Programming Guide for detailed discussion.
In Summary, If you are saving the files to:
Temp: You don't need to worry about cleanup, but you need to be aware that these files will not persist between app launches
Library/Caches Generally iOS won't delete these files but can clear them when running on low disk space. So developer has to make sure these files can be regenerated when required.
All other folders yes, you need to make sure the files are properly cleaned up when they are no longer needed.
UPDATE: Now that you have specified that you are saving to Library/Caches, From Apple Docs about Caches directory:
Use this directory to write any app-specific support files that your app can re-create easily. Your app is generally responsible for managing the contents of this directory and for adding and deleting files as needed.
In iOS 2.2 and later, the contents of this directory are not backed up by iTunes. In addition, iTunes removes files in this directory during a full restoration of the device.
On iOS 5.0 and later, the system may delete the Caches directory on rare occasions when the system is very low on disk space. This will never occur while an app is running. However, you should be aware that iTunes restore is not necessarily the only condition under which the Caches directory can be erased.
To be specific Your app is generally responsible ... for adding and deleting files as needed., You should always clean up after yourself. If you know you are done with the files, keeping them on disk and waiting for the device to run on low disk space so that the OS deletes them is a bad idea.
btw, if you are downloading files from the internet, why don't you use an already build library (so that you don't have to worry about these things).
If you are developing for iOS 8.0+ and using Swift, you could use AlamofireImage as an embedded framework. It comes with a very good caching system. I think you can use it on iOS 7 as well by copying the Swift files.
If you are using Objective C, you could use SDWebImage which comes with its own caching system. You could also use AFNetworking and enable basic caching, this blog post should get you started.
I got my app rejected due to violation of 2.23
After inspection, it would appear that I was indeed not a correct path for storing downloaded images and data files (i.e. files that I would prefer to have available for offline usage, but which the app can re-download again if removed by iOS)
However, after looking at:
https://developer.apple.com/library/ios/qa/qa1719/_index.html
It appears it may not even be enough to proper "cache" path for iOS > 5? Example:
/var/mobile/Applications/00000000-0000-0000-0000-000000000000/Library/Caches/'
Will using above make my app pass this requirement? Or am I forced to using the API for making files not to be backed-up?
Using the caches directory is correct if you can re-download the files. They will not be backed up. You only need to use the "do not backup" flag if the files exist in a location that normally is backed up (e.g. the documents directory).
I have a problem. I need to make the synchronization between the two devices
At first I was trying to set up synchronization through СoreData. But it's not a very good work. Adding new entities worked fine. But the editing of previously created work is not good.
I looked as done in other applications. And I saw that in the majority of synchronization is implemented through .entry file . What is this format is that? I tried to find information about it, and how to create it. But I could not find it. Please tell me how is synchronized through .entry . Maybe there are some tutorials.
Thank you for your time
Added Image Example this files in iCloude. It's file created one well-known application
These .entry files are not publicly part of any iCloud API, so no information is available on them. In fact if I Google for "iCloud .entry", this question is currently the #1 result (and the only one in the top 10 that is even remotely relevant).
Since these apps appear to be using iCloud, and since the file in question is a PNG, it's very likely that the apps are using iCloud file synchronization and that the .entry files are an undocumented internal implementation detail. They aren't something you create or use directly, but are (probably) something that iCloud uses for bookkeeping when you're using the file sync API.
To use this API, the basic steps are:
Create the file locally
Use NSFileManager to move the local file to iCloud
Use NSMetadataQuery to find files in iCloud that haven't been downloaded yet
Use NSFileManager to download iCloud files to the local device.
Apple provides a lot of documentation on this process, plus WWDC videos and sample code.
This is nothing like Core Data syncing. You can't sync a Core Data persistent store file this way-- Apple specifically warns that it's likely to get corrupted. But you can use it for most other types of documents.
Like many developers, my iOS app was just rejected for having downloadable content that was being backed up to iCloud. I've searched for a clear answer to this question but have not been able to get one.
Apple says that you should implement a 'do not backup' attribute to your files, however, they also state (https://developer.apple.com/library/ios/#qa/qa1719/_index.html):
The new "do not back up" attribute will only be used by iOS 5.0.1 or later. On iOS 5.0 and earlier, applications will need to store their data in /Library/Caches to avoid having it backed up. Since this attribute is ignored on older systems, you will need to insure your app complies with the iOS Data Storage Guidelines on all versions of iOS that your application supports.
My app supports iOS 4.0 and later. Does this mean if I want to maintain support for iOS 4.0-5.0, I have no choice but to put all my content into the Caches folder? Or, can I just add the 'do not backup' attribute and keep the files in /Documents? If I have to keep the content in the Caches folder, can I prevent these files from being purged in low storage situations? Finally, are there any developers who have put files in the Caches folder and know how often they do get purged?
Any advice or help would be greatly appreciated. Thanks a lot!
The concern area is the iOS 5.0, which supports iCloud, but does not recognizes “do not backup” attribute. In this case, all the data of the app inside documents directory is likely to get backed up to iCloud. For the iOS versions below 5.x:
the iCloud backup is not valid.
the "do not back up" flag is not relevent. It would not produce any warnings during compilation.
Hence the data can be kept in the documents directory, with "do not back up" flag appropiately added to the contents (files/folders), for all the versions. The problem is for the version 5.0 only.
i think you can find similar question like this :
What is suitable location for creating sqlite file?
and as per my thinking it is better to store files in library with new directory rather than document directory..
No it's wrong that tou say. I've solved your same problem in that way. I saved my database and directory images in directory Documents/.. flagons those As do not backup as suggest by Apple. In that way for devices that are updated to 5.x or more that files are not backup to iCloud; for others there are no changes because there are no support to iCloud.
This is a best practice because files that are not concerning user we do not backup in iCloud. All other files that you don't want to redownload must be saved in Documents flagging it as do not backup. If you save it in Caches folder those are deleted in a short time when you close the app and must be redownloded when you open it again.