Closed pronebird closed 8 years ago
You should never put the database in container. A SQLite store will almost certainly corrupt if accessed from more than one device in the iCloud container. It is only really safe to do that if only accessing the data on one device, and in that case, there is no point putting it in iCloud.
(Note: Apple may allow it with standard iCloud sync, but they do lots of stuff to make sure things do not get corrupt.)
Kind regards, Drew
On 01 Aug 2016, at 20:06, Andrei Mihailov notifications@github.com wrote:
Is it possible to share database via shared container and make it available for read/write for both app and extension? I am concerned that Ensembles needs some special configuration in that case.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
Sorry, I meant application security group container, not iCloud container. This is what Apple suggests to do with CoreData and they promise that multiple apps can safely read/write from the same database since iOS 8.2.
CoreData also supports +mergeChangesFromRemoteContextSave
since iOS 9, which makes it possible to smuggle changes across processes, however not many ways available for that, only NSFileCoordinator
or CFNotificationCenterGetDarwinNotifyCenter
.
I am currently using CoreData store from widget loading database from app security group container without ensembles enabled, in readonly mode. The app runs with ensembles on. Everything seems to be fine.
However, I plan to roll out action extension and I really need to write to database from there. This is what concerns me that if ensembles does not see changes, it won't be able to create revisions in its internal database. On the other side, I am not sure it's safe to run Ensembles side by side without creating a disorder in revision history.
I see now. Indeed, Ensembles will not see changes added from a different process/app/ext. if you want to use Ensenbles, you could either
I actually like the second option where the ext doesn't need much data to work with. Also keeps the scope of the ext focussed. More like a function than a full app.
Kind regards, Drew
On 04 Aug 2016, at 20:02, Andrei Mihailov notifications@github.com wrote:
I meant application security group container. This is what Apple suggests to do with CoreData and they promise that multiple apps can read/write from the same storage since iOS 8.2.
CoreData also supports +mergeChangesFromRemoteContextSave since iOS 9, which makes it possible to smuggle changes across processes, however not many ways available for that, only NSFileCoordinator or CFNotificationCenterGetDarwinNotifyCenter.
I am currently using CoreData store from shared container without ensembles enabled, in readonly mode. The app runs with ensembles on. Everything seems to be fine. However, I plan to roll out action extension and I really need to write to database from there. This is what concerns me that if ensembles does not see changes, it won't be able to create revisions in its internal database. On the other side, I am not sure it's safe to run Ensembles side by side without creating a disorder in revision history.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
Is it possible to share database via shared container and make it available for read/write for both app and extension? I am concerned that Ensembles needs some special configuration in that case.