so i know that some, or let's say nearly all, files are backed up on iOS.
I know how to prevent them from being backed up.
To maybe save unnecessary work i wanted to know if the content of
containerURLForSecurityApplicationGroupIdentifier:
is being backed up too?
I couldn't find anything specific about the group containers in the File System Basics from apple. In NSFileManager it is said that the directories are stored in ~/Library/Group Container/. In File System Basics it is written that all subdirectories of Library are backed up by iTunes. Does this now also mean that the content of my Group Container is also backed up or maybe not?
Maybe someone of you already has experience with that and can exactly tell me what's done with the content of the Group Container.
As an iOS developer myself this is an important question. After some hunting, I found this radar:
AppGroup folder does not backed up (sic) via standard iCloud/iTunes backup procedure
This was reported as a duplicate of rdar://18396036 (Open) but it cannot be found.
Responses from Apple:
If this issue is still occurring, please include any relevant logs, and or a test case with your update. (Oct 30, 2014)
and
Engineering has determined that your bug report is a duplicate of another issue and will be closed (Nov 12, 2014).
It sounds like the intended functionality is that app group folders should be backed up, and there may have been a bug in iOS 8.0 preventing this which is fixed in iOS 8.1.
Related
The following use case:
create a strings file (not localized) and deploy the application to your test device
localize the file (en.lproj or similar), make some changes to the new file and remove the original file
deploy the application on the device
What I noticed that very often (always?) the application will still use the old non-localized file. The reason is that apparently the file is still in somewhere the application bundle, even though it has been removed from the project. iOS's logic is that if a file of a specific type is looked up, it first checks in the root of the bundle for the non-localized version, and only if it doesn't find it does it go deeper into the localized folders. (Is it just me, or is this logic kind of backwards? I'm used to first looking for language specific file, and then falling back to some defaults, but it might be my Java background.)
Sometimes (always?) removing the app from the device completely doesn't help either. What does in this case is a CMD+SHIFT+K, which cleans the build folder, and after the app is built and deployed again, the correct file is used.
A worse problem would be if such a thing leads to an app crash, like some strange issues with Nibs or whatever - I have seen those as well...
The question is: what would happen if the first version of my app in the apple store had the non-localized file, and the second version localized it? When the user upgrades the app, would they get the same behavior as me during development (i.e. outdated, non-localized file used)?
I can't imagine because I think this would be a cause of a lot of grieving and bug requests, but I can't tell for sure as I haven't yet published any iOS app.
If the behavior is correct when upgrading from the store, why is it? What is so different? Are the files stored locally on my computer somewhere and used when I deploy?
Can anybody share their experiences?
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.
I have an app that uses local storage (using sencha 'Ext.data.proxy.LocalStorage') to view some content offline. I was rejected by itunes for violating the iOS Data Storage Guidelines.
I thought it might be related to the localStorage being inside the /Documents folder in iOS before iOS 5.1. To confirm that in newer versions the document folder is empty I checked, but I still found a .file__0.localstorage.
The strange think is that the same file (but without the leading dot) also exists in the library/caches folder, where it should be.
Both have the same content.
Does anyone know how this can happen? I already asked in the Sencha Support but it does not seem to be related to the Sencha framework.
Note: I am not using PhoneGap, only Sencha.
Making a very small Hello World Application with Sencha that writes to local storage I could reproduce this behavior. It seems like on application exit, it will write a copy of the localstorage file to the /Documents folder.
This seemed suspicious to me and it reminded me of the PhoneGap patch for iOS 5.1 that backs up the localStorage file also.
With iOS 5.1 Apple started to put the localStorage file in the Library/Caches folder which broke many applications because the data was no longer reliable stored. So PhoneGap and others started to implement Workarrounds that backup the localStorage file to the documents folder and automatically restore it if needed.
Trying to find proof that Sencha does something similar, I opened up the resulting .app package and found a stbuild_template file that contains the native wrapper code. It is of course compiled, but searching for the string "localStorage" results in some interesting results like:
restoreLocalStorage
preserveLocalStorage
Could not remove source file while backing up localstorage Could not copy localstorage backup . Caches WebKit/LocalStorage .file__0.localstorage file__0.localstorage
SNLocalStoreageFix
Also I found a lot of references to NimbleKit which seems to be used internally for the packaging.
This thread also hints at a solution for the iOS 5.1 local storage problem in Sencha Touch 2.1 which is what the OP is using: http://www.sencha.com/forum/showthread.php?194674-Localstorage-and-native-iOS-5.1-apps&s=04149e771f9c4eea15cb6f6d97069ff6
All this is evidence for me that Sencha implemented a workarround for iOS 5.1 which will put the localStorage in the /Documents folder. Since you only use the localStorage file for caching, Apple rejected you because you store non-user data in /Documents.
I think using PhoneGap there is an option to disable this backup. So you might want to consider using this or ask Sencha if they have a similar option to disable it.
I created magazine reader app that uses png images as pages. When user downloads magazine, all png images are downloaded and stored in Caches folder.
Problem with Caches is that files in there can be apparently deleted anytime. Since app is designed to be used in offline mode as well, re-downloading of missing pages is impossible.
I tried to save it into Documents folder but my app got rejected, this apparently is not proper place for them.
So my question is, where can I put them to make that iOS won't delete them? I don't need them to be backed up to itunes or synced or anything like that, I just need them to stay there until I remove them.
I tried looking into the documentation but I could not find a category that would fit my needs, am I missing something trivial?
EDIT: I need to support iOS 4 as well
http://developer.apple.com/library/mac/#documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/FileSystemOverview/FileSystemOverview.html
Put it in the Libary Folder
Handle support files
—files your application downloads or generates and can recreate as needed—in one of two ways:
In iOS 5.0 and earlier, put support files in the /Library/Caches directory to prevent them from being backed up
In iOS 5.0.1 and later, put support files in the /Library/Application Support directory and apply the com.apple.MobileBackup extended attribute to them. This attribute prevents the files from being backed up to iTunes or iCloud. If you have a large number of support files, you may store them in a custom subdirectory and apply the extended attribute to just the directory.
Apple has a tech note that addresses this at http://developer.apple.com/library/ios/#qa/qa1719/_index.html
It shows sample code for setting a no-backup attribute on files.
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.