I want the user to be able to access the files in the documents directory but am using core data and dont want the user to be able to access the store (the sqllite db), can i hide it from the user while still allowing file sharing, or can i put it in another directory where it will still get backed up?
The answer given by FrenchKiss Dev is not correct. The user will still be able to see the ".data" directory in iTunes and save that locally with all the files inside it.
Instead, store private documents in Library/Preferences
According to Apple:
In addition to the directories documented previously, the entire
/Library directory has always been preserved during
updates and backups, except for /Library/Caches.
Because of this, applications can create their own directories in
/Library/ and those directories will be preserved in
backups and across updates. To minimize the risk of name collisions,
we recommend that you name this directory carefully. For example, a
directory named Private Documents would be a good choice. You should
store any files you don't want to share to Library/Preferences.
In the documents directory, create a subdirectory which name starts with a dot. For example:
.data
EDIT: Please stop downgrading this answer !
This answer was correct at the time (remember that it was before the iPad was actually available! And there was a lot of confusion on the matter, we were still hoping for the iPad to appear in the shared devices in the Finder...).
Today (April 2012) it is still working on the Mac but not on Windows (starting a directory name with a dot means nothing in Windows).
Anyway, this Shared Document feature is a mess. Later they fixed it by saying that "Private Documents" should be stored in the Library Folder not in the Documents folder. But remember that developers were already using the Document folder before the iPad came.
Don't blame me for Apple mistakes.
Stack Overflow should have a way to mark an answer as obsolete.
API changes, get fixed, and it renders answers obsolete.
Related
I am not able the test my case, because I simply don't know when the synchronisation process of syncing files is triggered. Thats why I am asking this here.
I have a lot of files and subfolders in my apps document folder and want to prevent from backup up these files in ICloud (which seems to be stupidly the default).
Is it necessary to mark all these files with
MyFile.setResourceValue(NSNumber.numberWithBool(true), forKey: NSURLIsExcludedFromBackupKey, error: &err)
or is it good enough to only mark the root document folder once and all childs will also be marked with ExcludedFromBackup implicitely ?
u can use it for root directory only
Starting in iOS 5.1, apps can use either
NSURLIsExcludedFromBackupKey or kCFURLIsExcludedFromBackupKey file
system properties to exclude files and directories from backups.
In details look Technical Q&A QA1719
I found out that if I delete an App from the device, all local documents are deleted of course, but if the App has files stored in the iCloud-enabled folder ([[[NSFileManager defaultManager] URLForUbiquityContainerIdentifier:nil]) - These files are not deleted.
This causes two problems:
The storage taken by these files is not freed.
If the user re-installs the App, there are already files in the folder, which disrupts normal initialization.
I can take care of the second issue by going through the directory on first launch and deleting everything in there, but it seems a bit awkward.
I can't think of a way to take care of the first issue.
Any ideas?
iOS automatically purges files in the iCloud directory to free up space. You may also specifically "evict" files from your app, but since you are addressing the scenario in which the app is deleted, that probably won't be much help.
See the videos at developer.apple.com/icloud for more info.
I know normally I have two choices of places: Temporary folder or Cache folder.
But can anyone tell me the exact differences?
My app will download quite many images upon users' requests. Of course, no one need them on the disk of iphone permanently. But I still need to cache them in the case users will go back to see them in relatively short time period.
Temporary folder can be one place to go, as I understand it will be cleared by the system. But when will it be cleared?
For cache folder, will cache folder be cleared regularly as well? If the cache folder will not be cleared, and I write the images to Cache folder, that will occupy too much spaces in a longer term, and it is not good for the users of course.
So, can someone give me some hints and tell me the exact diff between these two folders?
Thanks
I would go with the Caches folder— look in NSPathUtilities.h for the relevant methods to get at that one. The Caches folder won't be backed up, but it won't necessarily be emptied either, and neither will the temp folder. /tmp would normally be cleared upon reboot (well, potentially), but on the iPhone that's not something that will happen commonly.
The best approach would be to put data into the Caches folder using some date-based scheme, so that you can clear its contents yourself when you deem it useful to do so. You could use the file's creation or modification date to inform this decision, and simply scan at each launch (or each enter-foreground event) to determine which items are old enough that they should be removed.
Sometimes when we issue an upgrade to our application we need to install some files to the application's Data folder. We want to make it possible for the users to move this folder to a place of their liking. But how to deal with this at install time?
I was thinking of deploying to the user's AppData folder and have the application somehow check there for new files at startup.
Any advice or references would be very welcome!
We use InnoSetup for a VB6 application if that matters for your answer.
Generally the best solution I've found is to allow the user to move the folder from within the application.
This allows the application to keep track of where its data is being kept (by adding a reference to it in a file or registry entry which it accesses at load time) and to access it seamlessly in the future.
Your update routines can then also access this information to determine where to place the update files.
Alternatively, make sure the folder name is as distinctive as possible and add a search routine to look for the directory in a number of sensible places at load time. Then write your manual specifying that the data folder can be moved to one of those locations ONLY.
Wouldn't the users just run an update or patch package? I'm not sure why they'd want or need to see such files. It's pretty rare for commercial software to offer users the options of where to store program settings and other internal-use files.
Give some thought to this before putting a lot of stuff into users' roaming profiles. You might want LocalAppData instead.
I want my app to share files via itunes file sharing. Right now all of the Documents folder
is exposed to the user. The problem is that there are certain files there (let's say these are "System files") that I don't want to expose. What should I do? And if it's not possible to "hide" files, where do you think it's best to put "System files"? In the Library folder?
Thanks
Apple has a Technical Q&A dealing with exactly this.
In addition to the directories
documented previously, the entire
/Library directory
has always been preserved during
updates and backups, except for
/Library/Caches.
Because of this, applications can
create their own directories in
/Library/ and those
directories will be preserved in
backups and across updates. To
minimize the risk of name collisions,
we recommend that you name this
directory carefully. For example, a
directory named Private Documents
would be a good choice.
Yes, the Library folder is a good choice. The Documents folder should be reserved for the user's documents. Alternatively, you can prefix the filenames of your "system files" with a . or put them in a .hidden subfolder of the Documents folder. Those hidden files are currently not shown in iTunes AFAIK.