Sharing couchbase lite on single device

[Jeff Kingyens]

Hello,

I have an app that is starting to use extensions (today widget, watch app, etc). if the user signs up or logs in from the main ios app, whats the best way to replicate/load this database to these extensions that live in other processes? Ideally I don't need to perform push/pull replication since the network connection might not be available. These extensions are basically separate containers / sandboxes on the same device. They can share a filesystem via app group memberships.

Thanks,
Jeff

[Jens Alfke]

> On Jan 22, 2015, at 8:56 PM, Jeff Kingyens <jeff.k...@gmail.com> wrote:
>
> I have an app that is starting to use extensions (today widget, watch app, etc). if the user signs up or logs in from the main ios app, whats the best way to replicate/load this database to these extensions that live in other processes? Ideally I don't need to perform push/pull replication since the network connection might not be available. These extensions are basically separate containers / sandboxes on the same device. They can share a filesystem via app group memberships.

I don't think replicating the database into the extension's sandbox is a good idea, since it consumes disk space and I/O bandwidth.

It's OK to put the database into the shared area of the filesystem and have the app and extensions all access it. The only thing you lose is that if one process changes the database, the others don't get notified; so if your UI updates are driven by notifications (or indirectly by them, via CBLLiveQuery or CBLUITableSource) they won't update to display changes from other processes. This is probably not a problem, though, because presumably the app and the extension aren't onscreen at the same time.

—Jens

[Jeff Kingyens]

Thanks, I did end up putting a single database in the shared file system. I wasn't sure about the database file locking but everything seems to still work. You are right, I don't get observers/notifications for database changes from the iPhone app on the watch, so I've opted to using polling instead. I'm not sure what the real hardware is like, but I can see the watchface and iphone screen simultaneously in the simulator. When a view controller on the watch appears, i just setup an NSTimer and fetch the rows i need to refresh a table. This keeps writes from the iPhone app in sync on the watch. However, I do perform some writes on the watch app itself, such as deleting a table row. The CBLLiveQuery on the iPhone app doesn't pick these up obviously. A watch app can call an openParentApplication() function so I will probably use this to trigger a UI refresh (in both foreground and background). The watch app is mostly read only so this should be fine.

On a side note, I was trying to setup CBLLiveQuery's on the watch app but the observers were not firing. I was also receiving a warning about a stopped run loop when I made a call to waitForRows(). Since I switched to polling on a timer I didn't have a chance to debug this further. However, even with NSTimer objects, I needed to explicitly attach the NSTimer to the run loop otherwise it wouldn't fire. I am not sure if there is something more CBLLiveQuery needs to do in order to fire as well and if the caller or the intializer itself should be responsible for this.

Thanks for the help!

Jeff

[Jeff Kingyens]

Right now I am just polling for document changes, however the CBLDocument objects appear to be cached so I can't detect changes. Is there any way to wipe the cache or disable it? I am currently closing the database and re-opening it every N seconds as part of my refresh/reload logic in my app extension.

Thanks,
Jeff

On Saturday, January 24, 2015 at 3:13:21 PM UTC-8, Jens Alfke wrote:

[Jens Alfke]

On Jan 26, 2015, at 6:33 PM, Jeff Kingyens <jeff.k...@gmail.com> wrote:

Right now I am just polling for document changes, however the CBLDocument objects appear to be cached so I can't detect changes. Is there any way to wipe the cache or disable it?

Not really. :(

Sounds like we'll need to add some support for handling changes to the db made by an external process. There wasn't a need for it in iOS before, but I can see that iWatch extensions will need it.

—Jens

[James Nocentini]

I just came accross this library https://github.com/mutualmobile/MMWormhole.

It's probably possible to only access the database within the app and use this library to send/receive documents to the Watch app.

This would solve the issue of long polling and caching but I'm not sure how much more code it would require.

James

[Jens Alfke]

On Apr 27, 2015, at 9:43 AM, James Nocentini <james.n...@gmail.com> wrote:

I just came accross this library https://github.com/mutualmobile/MMWormhole.

It's probably possible to only access the database within the app and use this library to send/receive documents to the Watch app.

The ReadMe file for MMWormhole says it works by having one process create temporary files in the shared space which are then read by the other process. My hunch [not based on any data!] is that each request/response would take quite a while (tens/hundreds of milliseconds?) To make that work you’d have to bundle up a lot of data into each message.

Back to the issue at hand: Jeff, did you ever file a bug report about the problems sharing a database between two processes? We could fix this, but it’s not on our radar since the problem was only discussed here and didn’t make it into the issue tracker where we do sprint and release planning.

—Jens