Re: iOS app groups sharing SQLite databases, notifications
Re: iOS app groups sharing SQLite databases, notifications
- Subject: Re: iOS app groups sharing SQLite databases, notifications
- From: Damien DeVille <email@hidden>
- Date: Thu, 26 Jan 2017 13:35:36 -0800
I haven’t been using SQLite directly in an app group but I’m using Core
Data (with a SQLite store type), which is supported by Apple and works
fine (they’ve also recently added `+[NSManagedObjectContext
mergeChangesFromRemoteContextSave:intoContexts:]` that makes merging
Core Data changes from another process much easier). So I would assume
anything SQLite needs to do multi-process arbitration will work since
it’s used and supported by, at least, Core Data.
Regarding IPC, as you said, you can use Unix domain sockets or Mach IPC.
Sockets are easy, you just bind to a path in the app group and
write/read from both processes. But yeah, fairly low-level.
I personally find Mach IPC somewhat easier to use. On iOS, you can use
`CFMessagePort` (note that these functions are documented as not
available on iOS but they are public, available and work, at least last
time I tried, so keep that in mind). One process will act as the
"server" and call `CFMessagePortCreateLocal` while the other process(es)
will act as "client(s)" and use `CFMessagePortCreateRemote` to get a
matching message port. Note that `CFMessagePortCreateLocal` will need to
register the Mach service name with the bootstrap server and dynamic
Mach service registration is inherently restricted by the Sandbox. The
trick is to use a Mach service name that begins with the app group
identifier, that’s how it also works on Mac.
If you don’t need to send any user data but simply notify the other
process, the simplest way is probably to use the Darwin notification
center (as you said). You can get it via
`CFNotificationCenterGetDarwinNotifyCenter` and send notifications as
you do in process. It’s based on notify.h so I guess the messages bounce
via `notifyd`. Note that your user info dictionary will not make it
through (that’s the same behavior for sandboxed apps on Mac) so it’s
marginally useful if you need to send user data. I believe it also used
to be the "Apple recommended approach" when they introduced WatchKit
extensions a few years ago and was mentioned in some WWDC session.
On Mon, Jan 23, 2017, at 01:20 PM, Jens Alfke wrote:
> I’m looking into the feasibility of sharing a SQLite database between
> multiple iOS apps by the same developer, using an “app group”.
>
> The app group entitlement grants a shared directory where the database
> file can be stored, but SQLite also relies on file locking and shared
> memory (via a mapped file) to arbitrate access. The Apple docs I’ve seen
> don’t explicitly say whether those mechanisms will work. I can’t think of
> any reason they wouldn’t work for any file that both processes have
> access to, but it would be nice to have confirmation. Have other people
> successfully shared SQLite databases using an app group?
>
> I’ll also be needing some limited inter-process notifications, so that
> one app can notify the others after it makes changes in the database.
> Most of the time this won’t be necessary since generally only one app is
> active, but there can be situations where a backgrounded app can modify
> the database, e.g. if it receives a push notification while in the
> background, or if it uses a background task to finish some activity after
> being backgrounded.
>
> Apple’s docs say that Mach IPC and Unix domain sockets can be used; but
> I’ve used both in the past and they’re rather low-level and messy. The
> CFNotification “Darwin Notification Center” seems like a better approach;
> it’s available on iOS, and the docs say it’s implemented using Mach
> notifications, which should work. Has anyone used it within an app group?
>
> —Jens
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden