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.
Related
I am building an iPhone app that requires preloaded content. This content is presented so that it tests the user's knowledge, but is not modified by the user. The content consists of proprietary image files and pdf files.
From what I understand, the best practice would be to store this in the app's Library or Documents directories (please inform if this assumption is not correct). In a future version of the app I might want to upload additional (not replacement) content via API, but this is not part of the initial version.
I have seen many posts and tutorials regarding obtaining paths to the Documents and Library directories of an app, and reading/writing to them. This is all good and useful, but not what I am looking for here.
I would like to preload the content into the Documents and/or Library directories, for the simulator initially, to test app in simulator; and ultimately to the release version. I would have thought this would be possible to do from XCode without writing code.
I have not been able to find a solution to this on Stack Overflow or other places on the net. Any pointers, links, solutions are welcome. I am using XCode 10.3 with Swift 4.2.
See the File System Programming Guide: File System Basics, which shows us:
The “data container” (including the Documents and the various Library folders) is for content generated/saved by the app. When, in Xcode, you mark resources as being part of the target, that becomes part of the bundle, and your app can retrieve it from there at runtime.
Theoretically, yes, you could copy data from the bundle to the Documents and/or Library folders, but, yes, you would have do that programmatically. It seems a bit wasteful to have two copies of these resources on the device, but you can do whatever you want. Generally, though, resources included in the bundle would just be be opened directly from there at runtime, not copying it to the data container (except for those cases where you would need to change it, because bundle contents are read-only).
FYI, for additional information regarding the file system, see the iOS Storage Best Practices video.
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.
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.
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.)
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.