My app uses custom file packages (UTI conforms to com.apple.package) to store individual "notebooks", each package (directory) containing various individual files. I would expect the "Manage Storage" section of iCloud settings on my iPad to show the names of the packages, NOT the contents of these packages. It makes more sense for the user to be able to delete an entire "notebook" instead of the component files inside.
So is this normal, or did I do something wrong when I uploaded the package to iCloud? I've created and exported the UTI for my custom file type (and it seems to work, since the email app recognizes my new files and associates them with my app). Do I somehow have to tell iCloud about my UTI definition?
Finally, if this behavior is "normal", is there a way to force it to work like I want it to?
Thank you!
I think I discovered the answer by accident. I recently deleting all the iCloud data for my app from the iCloud settings -> Manage Storage page (by tapping "Edit" and then "Delete All"). After reloading my data back up to iCloud, it worked as I expected - I now see just the package filename, instead of all the contents of the package.
I suspect this is because I originally uploaded my data to iCloud before I properly defined the UTI. After I finished getting the UTI correct, I had my app delete the data and reload it, but this apparently wasn't as thorough as deleting the entire iCloud container via the "Manage Storage" page. My best guess is that when I FULLY deleted everything and reloaded it from scratch, the proper UTI export data went with it this time.
Anyway, it now works! I hope this can help someone else in a similar situation.
Related
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 am building app which syncs documents over the iCloud.
When I create document (lets say its name is myfile1.doc) in one device and expect to appear in another one I get nothing - it looks like it doesn't sync. To my surprise when I read the content of Documents folder in ubiquity container I can see the representation of the file is added as a hidden file with .icloud extension (in this case .myfile1.doc.icloud).
I tried to find more about this .icloud files but so far no results.
Anyone know what are they representing? Is it the metadata item that indicates that file was added to iCloud and I should manually download it?
I think hidden files are handled by metadataQuery to indicate that the new file was added to iCloud and is waiting to be sync'ed. NSMetadataQuery recognizes them as representation of new files not yet downloaded to ubiquity container.
These files are not documented and you should ignore them. If you want to know what's in them, open one in a hex editor and have a look. Your code should not check for them or access them in any way.
my app has been rejected due to iCloud Storage Restrictions. (2.23).
There are lots of questions for this situation, but i am still not sure why my app has been rejected.. Here are my suspects:
1- My app downloads pdf files and images for letting users see on "offline" mode when a user selects a row from a tableview. I've set my download folder as "Documents/privateDownloads" and set the folder (and files inside) url flags as "do not backup"
2- My app also has a 2Mb. "preload.json" file, which my app reads the file at first launch and preloads into the database only at first launch (with a progress hud showing the progress of importing data). I haven't set the "preload.json" file as "do not backup".I just drag dropped the file into "Supporting Files" group in Xcode.
My guess is the problem lies in the 2nd suspect, but i've also read that i should move the "privateDownloads" folder into "Application Support" Folder instead of Documents folder.
i always stored my offline files on nsurl cache for a very long time (technically forever), but this time i've decided to do like this.
thanks for reading and helping.
Edit: there is a note from app store for rejection reason:
"In particular, we found that on launch and/or content download, your
app stores 3.6MB"
When i control this issue, this is happening after my application "preloads" the data. But what i really don't get it is, i am storing this preloaded data in core data. So yes, i want this data to be backed up in iCloud?!
To solve the issue of your seed data being too large, you might split your Core Data stack in two separate stores - one which stores the user data and is backed up to iCloud. And a second one which stores the seeded data imported from your JSON. This store could then be excluded from iCloud backup via the "do not backup"-flags.
Another recommended way would be to ship a pre-populated store like described in this article on objc.io. Since you mentioned your preload.json is several MB, this would be even more desirable to pre-generate the store once than on every device on initial app startup. And you could apply the required file attributes for not backing it up more easily.
The issue won't have anything to do with your preload.json file. If that's included in your app distribution, it is part of the app and you don't need to do anything different with it.
I would suspect that the reviewer didn't notice you were setting the 'do not backup' flag on files you've added to the Documents/privateDownloads folder, or that you have a bug and the flag isn't being set at all. It is safer, if you're able, to store those kinds of files in a /Library/Caches sub directory. Then you don't need to worry about the flag.
In my iPhone app, I am downloading files from server and storing them locally (user's document directory). The path of each file downloaded is subsequently updated in database.
If user tries to delete a file, first the file is deleted from local path using removeItemAtPath: (NSFileManager), then corresponding record is deleted from database.
Now I have one of the requirements according to which user can turn on a UISwitch to delete all data on app exit.
Now my question is -
suppose user downloaded 20000 files, say small images, and user turned
on the switch to delete all data on app exit. Is it good to handle
this task in applicationWillTerminate? What is the best way to
accomplish this scenario?
Please suggest.
Don't delete the files individually, delete and recreate the folder.
Your database could be handled differently by version tagging so that you can batch delete the items on the next run.
applicationWillTerminate will only be called if your app goes background (the only option by pressing Home button of the device) and "Application does not run in background" key is set in your app's info.plist file to "YES". Otherwise it won't ever be called.
If you are planning deploy app with similar functionality, you can use applicationWillTerminate for removing so many files. However, I would never recommend you that. Instead, my recommendation is to remove the files as soon as they are processed, if possible at all.
Another thing you must consider is not to save so many files in Document directory, however small those are. Document directory is backed up by iTunes and iCloud and if you store so many files there, you are gonna possibly violate Apple's Data Storage Guideline that would reject your app from App Store. It is always a good idea to store transient files in application's "tmp" directory and delete them when not required anymore.