I would like to create a NSPersistentDocument in Mac OS X and read this document as a UIManagedDocument on iOS 7.
Is this possible?
Are both file formats compatible?
Thank you!
Interesting question - I can confirm that the basic core data files are compatible. I have a Mac app and an iOS app using the same file that gets synced using iCloud. The app is a document based app and currently I have been storing the actual database file in iCloud so the whole file gets sync'ed by iCloud.
This works fine but obviously if a user opens the file on two devices and is not careful about saving and closing there is a possibility their changes may be overridden.
Apple has approved the Mac app which uses standard NSPersistentDocument to create and save files. Unfortunately they have rejected the iOS apps with some obscure reference to not conforming to their data storage guidelines, saying that documents must be stored in /Documents directory if they need to be backed up to iCloud. Well if the user has selected iCloud then I store the files in the iCloud location provided by the API calls.
Anyway I am still waiting to hear back from them about what is specifically wrong with this approach since it seems to be the same one used by Pages and other document based apps.
If I try using UIManagedDocument then iOS creates a folder structure and stores the database inside this folder structure. The Mac app File->Open dialog then shows this folder structure as well as a file that essentially looks like a the normal sqlite file. But then perhaps OS X 10.8.4 does not implement the latest iCloud/Core Data stuff - who knows...
EDIT
Here is a link to code examples and videos showing OSX and iOS app integration using Core Data and iCloud. http://ossh.com.au/design-and-technology/software-development/uimanageddocument-icloud-integration/
I agree this is definitely possible. I'm using NSPersistent document on OS X 10.8/10.9/10.10 with a binary core data format (no wrappers - plain files). On iOS i'm using UIDocument. Core data works fine in both environments.
Apple says NSPersistentDocument does not support iCloud. It is more correct to say it isn't fully supported. Most of the NSDocument support (which includes iCloud Document Library access from 10.8) will work. Handling of conflicted files on open works.
You can't enable auto save (which is listed as a requirement for iCloud Documents in the iCloud Design Guide). Autosave works asynchronously and is definitely not supported by NSPersistentDocument.
So if you handle file saving, and conflicts, it is possible to use NSPersistent document. There are some quirks: so, for example, if an iCloud change arrives on OS X for a document that is open, the normal NSDocument response would be to automatically reopen the document. This doesn't happen - and there is no warning the file has changed until you are about to save the file. But at least there is a warning. On iOS it is easier to detect changes as they happen by using UIDocumentStateChangedNotification.
Related
This is a very theoretical question, but quiet important for me, how I approach my next steps.
I am developing a SwiftUI MacOS app, where a user can upload own files. The metadata getting stored in CoreData and the file I store manually in the file system. At the moment I am using the default file folder for my application.
Soon I want to have a iCloud sync between my Mac OSX app and my iOS app. I read about it and it should work. CoreData should be no problem.
Now to my question if it will be possible to approach it that way I am thinking of:
I would like to create a Finder Sync Extension for my Mac OSX app, so I get a own folder, which can be added to the favorites and be observed. I want all my local files to be stored there. That should work..
Will I am able to sync these files which are stored in the Finder Sync Extension with iCloud to my iOS app?
Can I create a extension on iOS aswell, to display these files?
I am not storing my documents in a Data blob of the CoreData or allowing External Storage. I store all manually. Will I am able to still sync my documents via iCloud.
All in all, I want to know if I can store my files in the Finder folder, and still keep them synced with iCloud to iOS? If that is not possible, please let me know. Would be interesting to know in forehand.
A Finder Sync Extension should not "do" any syncing. In fact, Apple specifically recommends that a separate background process be used for any networking-like activity:
It’s generally best if the extension focuses on handling the badges, contextual menus, and toolbar buttons. Place in a separate service (a Login Item or Launch Agent) any code that performs the sync, updates state, or communicates with remote data sources. This approach ensures that there is only one syncing service running at a time.
https://developer.apple.com/library/archive/documentation/General/Conceptual/ExtensibilityPG/Finder.html
A Finder Sync Extension is used to provide file badges, menus, and otherwise modify the UI of Finder.
Adding a Finder extension doesn't give you a folder, let alone one that syncs.
You need to provide the folder and all sandbox details related to that. Your main app and/or background process needs to provide the syncing service.
In summary, your main app handles all of the syncing.
The Finder Extension only updates the UI for certain folders. It doesn't provide any syncing itself. So any "syncing with iCloud" question you have should be asked independently of the Finder Sync Extension context.
How do I keep the users data when they get an update.
I use the Marmalade SDK to develop an app and I saved the user data to bin files and text files, I used the ram:// prefix when saving the files.
If I delete the app and get it from the app store again with the could symbol It had lost all its user data. I would like to release an update that doesn't delete the users data. The app does not come with any user data files, the app creates them as you use it.
Edit: Marmalade is cross platform but my question is for iOS only and the app has been publish, I am asking with respect to an existing app.
Deleting the app from the device, also removes it's sandbox. So any user data stored locally is deleted. This is expected behaviour.
If the user data comes from the web, then you just need to download it again.
Have you read the tutorial for dealing with files?
I have never used that sdk but:
rom for the read-only portion of your apps data area and is read only.
ram for the writable portion of your apps data area. This drive is the only drive that is guaranteed to exist across platforms
rst for a removable memory card on the phone or tablet
raw for paths that will be passed directly to the underlying operating system without modification. (not supported on all platforms)
tmp for a system temp folder, outside of the s3e data area. (system temporary folder and currently only available on iOS)
So maybe you could try rst:// and get the expected result?
My iOS app is intended to be compatible with iOS 5.0 and above, and it has iCloud capabilities turned off in it's target settings, I'm not integrating with iCloud. My app stores an sqlite file and some image files into Documents folder. The sqlite file is not downloadable, but images are.
I've read some posts from people saying that their app's submission was rejected because they don't met the iOS Data Storage Guidelines, but I'm not sure if that is only required if your app has iCloud capabilities enabled, is it? Should I set the NSURLIsExcludedFromBackupKey for my files anyway?
Thanks in advance
EDIT
I've read this here:
It is not possible to exclude data from backups on iOS 5.0. If your app must support iOS 5.0, then you will need to store your app data in Caches to avoid that data being backed up. iOS will delete your files from the Caches directory when necessary, so your app will need to degrade gracefully if it's data files are deleted.
But I need the sqlite file to be in Documents to insert data... how should I handle this?
It has nothing at all to do with whether your app uses iCloud or not. It has to do with the user performing backups to iCloud which is beyond the control of your app.
If all of the data in your app that is stored in the app sandbox is data that is created and stored by the user through the use of the app then Apple will have no problem with the data being backed up.
They have issue with replaceable files being backed up needlessly. If the database file is read-only and could be obtained from a server or the app bundle then don't let it be backed up. But if it starts out mostly empty and then gets data added as the user adds data through the app then it should be backed up. Same for the images.
I'm developing an iOS app that has to support iOS 5+. I've read the iOS Data Storage Guidelines in order to prepare the app for the submission and read several questions and solutions about those guidelines here in Stackoverflow, but I still have some doubts about how I should handle this.
I have an sqlite database whose tables are defined in an .sqlite file. I copy this file into \Documents folder when app starts, and I keep such file always there in \Documents. This database firstly contains some collections of fixed data that app may need (lists of cities to select and things like that), and the rest is user-dependent data that will be downloaded. I've read this post: Apps must follow the iOS Data Storage Guidelines or they will be rejected in app that contains .sqlite3, but I still don't know what criteria should I apply. The .sqlite is not downloadable, it is included in Supported Files of the Xcode project, and some of the initial data is inserted from inside the app and it is neither downloadable. The user-dependent data, well, I can download it whenever I need. I've not integrated any iCloud stuff in my app. So, should it be correct to keep the .sqlite file always in Documents? AFAIK, you need the file to be there for performing all database operations...
As I said, I've not included any iCloud related code in my app, and in fact I don´t know how iCloud is managed because I've never told to do it, are backups of the app made anyway? Should I use the flags the iOS Data Storage Guidelines says in order to prevent files to be backuped? I need some guidence regarding backups and iCloud considerations.
And there is another thing: my app also downloads some user-dependent images. I show them in several views throughout the app, so I need them to persist while the normal working of the app. However, it is downloadable content. So, where should I place them?
Thanks a lot!
I believe your .sqlite file should be in Documents, this is the correct place for it.
You downloaded images should probably be in Caches, but you could also get away with them in documents as long as you set the "do not backup" attribute.
You can set the skip backup attribute like this:
BOOL success = [url setResourceValue: [NSNumber numberWithBool: skip]
forKey: NSURLIsExcludedFromBackupKey error: &error];
I was under the impression that iCloud only worked with UIDocument files.
How about other types?
Also if my user's files get uploaded into the cloud, can he use those files with all his devices if my app is universal?
According to Apple's File System Programming Guide,
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.
iCloud does back up of the things under Library also.
Ans YES of course if user's files get uploaded into the cloud, then he can use those files with all his devices if the app is universal as iCloud is intended to be the invisible magic that glues your iPhone, iPad and Mac (if you use one) together.