I am attempting to add iCloud synching to my iOS/Mac app by using the iCloud methods on NSFileManager (no documents or file coordinators). The app needs to synch audio files across the various instances; create, delete and metadata changes. It isn't a collaboration style app, so I am not very worried about conflicts, etc. I have something basic working, but have run into some basic questions that I can't seem to find definitive answers to.
When using iCloud, there are two local directories involved, the sandbox directory where the file originates and the ubiquity container directory. Once I enable a file for ubiquity, should I start interacting with the file in the ubiquity container directly or should I continue interacting with the sandbox file and pushing/pulling changes from the ubiquity counterpart? It feels like the latter is best so that I don't lose all the users files if they turn iCloud off (not sure what happens to files in ubiquity container in that case).
If I maintain two files, is there a preferred way to push/pull incremental changes to/from the ubiquity container? As I understand it, if a user changes a file on a given device, all other devices get the incremental changes in their local ubiquity copy (if downloaded). Should I just be copying the file in it's entirety over to my local sandbox directory every time the ubiquity file changes and vice versa?
Constantly copying files to the ubiquity container as they are modified doesn't seem like a good strategy to me and might even result in iCloud thinking more of the file has changed than really has. You can interact with files in the ubiquity container directly, working with them just as you would a file in your 'normal' document sandbox. This is the model prescribed in all of the iCloud documentation, sparse as it may be.
You're right that you need to be able to handle the situation where a user migrates away from iCloud. There are methods to move a file out of the ubiquity container and some of the newer iOS 6 API makes it easier to detect if the user has iCloud enabled, though this is still an area where we could use more API.
Related
Using FileManager.moveItem I can move a file in iCloud to another location in iCloud without downloading it locally. I would like to perform the same thing but with FileManager.copyItem, in the sense that I would like to make copies of files within iCloud without downloading them locally.
With FileManager.copyItem it seems to not be possible.
Moreover, analysing the .js of icloud.com/iclouddrive I see /moveItems and other endpoints, but no /copyItems. There is however, a "DuplicateItems" string in a "transactionType" array, but I cannot understand how to use it.
When I save (either create or update) a small file in the iCloud container of my iOS app, the iCloud daemon first uploads the file to iCloud and then evicts it when the upload is done. If I monitor the file's state using a NSMetadataQuery I can see that after the save, the file's downloading status changes fromNSMetadataUbiquitousItemDownloadingStatusCurrent to NSMetadataUbiquitousItemDownloadingStatusNotDownloaded, and instead of my little test file named test I only see the file .test.icloud instead.
This is bad because if the user goes offline after the file creation, the file cannot be read again. The file should always be available locally after the creation (an outdated file is better than no file).
I know that I can immediately re-download the file using FileManager's method startDownloadingUbiquitousItem after iCloud removes it, but this feels like a silly hack. Is there a way to simply prevent iCloud from evicting the file in the first place?
I am using the "new way" of storing documents (iOS 11+) using UIDocumentBrowserViewController. No need for iCloud API, Entitlements etc. -- just works (under control of the separate Document Browser process).
However, I haven't figured out how to rename (i.e. move) a document programmatically this way, at least within iCloud. The standard "url.setResourceValues()" does work just fine on the local filesystem, but renders in 513/not permitted in iCloud. Also all the former ways of doing it (using full set of iCloud capabilities & entitlements, using complex FileCoordinator orchestration etc.) don't work either when the created document actually is controlled through the document browser.
I couldn't find any reasonable documentation or example on how to use the UIDocumentBrowser to also move a document under it's (and somewhat my) control. There is the UIDocumentBrowserImportModeMove mode that might do what I need, however I have no clue how to programmatically initiate that on a given UIDocument.
Has anyone already made experiences to do it this way?
Thanks, habitoti
There is no API to move a document that was returned to you by the document browser after the user picked it. You should file a bug with Apple to get one.
If this is inside your iCloud container, you can use the iCloud entitlements and -[NSFileManager URLForUbiquityContainerIdentifier:] to get sandbox access to your container and do whatever you want inside with NSFileManager; but that won't work in iCloud outside of your container or in other file providers (Dropbox...).
Currently i was saving my application data (Media) to the CacheDirectory i.e
/var/mobile/Applications/BEAFC76C-C450-4A3A-9765-A0385A9580F3/Library/Caches
and things were going fine. But recently i got a bug report that the application data has been deleted. When i searched over it, i got this Apple Doc. According to it, DocumentsDirectory should be the ideal place to store the User/Application data.
Put user data in the /Documents/. User data is any
data that cannot be recreated by your app, such as user documents and
other user-generated content.
And Cache should not be used to store the User Data that could not be reproduced by the application.
Put data cache files in the /Library/Caches
directory. Examples of files you should put in this directory include
(but are not limited to) database cache files and downloadable
content, such as that used by magazine, newspaper, and map apps. Your
app should be able to gracefully handle situations where cached data
is deleted by the system to free up disk space.
What should be the ideal place to store it.
EDIT:
I have an application that allows user to store Videos and Photos in the application. For that i used CacheDirectory. But i am getting bug reports that the Data (Videos/Photos) is getting deleted. What conclusion i draw is that the data is being getting delete by the Device itself in order to provide space.
Secondly i also wanna give the iTunes sharing function. So only the particular files has to be stored in the DocumentsDirectory. Some files can never be exposed and some has has to be shared. What should be the ideal way to store the files.
Use Documents (NSDocumentDirectory) for files you wish to share via iTunes.
Use Application Support (NSApplicationSupportDirectory) for files you wish to hide from the user but still be backed up and never deleted by the OS.
Starting iOS 5, Apple says that it's no longer a good thing to save all kind of files in Documents Directory - if you do that, your app will be rejected for sure because this folder is backed up to iTunes & iCloud, unless otherwise specified.
It says that we should save files into Caches or Tmp Directory - these won't be backed up, but it's not a good thing to do because files from these directories can disappear if low memory happens.
So I think the best think to do is to save the important files that you need all the time in your app into Documents Directory and mark them not to be backed up, like this.
Library/Application Support Folder is the folder you should be using.
This directory doesn't always exist, and thus you may need to create it.
You can enable or disable whether you want to backup this data with iTunes or not.
This data is not accessible even if you enable file sharing. Only data that you put in Document directory would be shared with iTunes sharing, so you can still protect your data and get it backed up as well. Apple's documentation
I'm a bit confused. I'm including in the bundle a Core Data file that will not be modified by the user. Apple rejected my app after I started copying the file to /Documents (due to the new iCloud requirements), so I now I copy the file over to /Library/myprivatedir/
The question is why do I need to copy over to /Library in the first place. What's wrong with it staying in the Bundle after all?
There's nothing wrong with opening a CoreData store from within the bundle. Just be sure to pass the NSReadOnlyPersistentStoreOption as part of the options to -addPersistentStoreWithType:configuration:URL:options:error:
Skimming the docs for iOS Data Storage Guidelines (apple id required) I found this
... Data that can be downloaded again or regenerated should be stored in the <Application_Home>/Library/Caches directory. Examples of files you should put in the Caches directory include database cache files and downloadable content, such as that used by magazine, newspaper, and map applications.
Because it is easily regenerated they may have taken issue with it.
A couple of points down may be useful if you did have a read/write database scenario
... Use the "do not back up" attribute for specifying files that should remain on device, even in low storage situations. Use this attribute with data that can be recreated but needs to persist even in low storage situations for proper functioning of your app or because customers expect it to be available during offline use. This attribute works on marked files regardless of what directory they are in, including the Documents directory. These files will not be purged and will not be included in the user's iCloud or iTunes backup. Because these files do use on-device storage space, your app is responsible for monitoring and purging these files periodically.