Monitoring Syncing

[Steve]

The iOS app I am building creates a Couchbase Lite database the first time it starts and populates this new database by syncing with a remote Couchbase Server. Upon this initial sync a map is displayed and the sync'd data is displayed on the map.

If the phone experiences networking problems and the sync is interrupted and takes sometime to complete, there is the possibility that not all data pertaining to the portion of the map being displayed will have synced to the phone.

How should I manage such a situation? Should I simply refresh the display once the initial sync completes? Should I refresh the map every 30 seconds for example, if the sync has progressed (in which case there maybe new data to display)?

PS - I have looked at the code of the demo grocery app. Currently my app determines the sync is complete when pull.completedChangesCount = pull.changesCount.

Thanks

[Jens Alfke]

On Sep 19, 2014, at 6:37 AM, Steve <s.ande...@gmail.com> wrote:

How should I manage such a situation? Should I simply refresh the display once the initial sync completes? Should I refresh the map every 30 seconds for example, if the sync has progressed (in which case there maybe new data to display)?

It's best to drive your UI from the state of the database, rather than watching replications. That way your app works correctly whether the changes were made remotely or locally. There are a couple of ways to do this:

• Run a CBLLiveQuery, and observe its 'rows' property to get notified when the results of the query change; then display your UI based on the query results
• Observe CBLDatabaseChangedNotifications, and in the observer method check whether documents relevant to your display have changed
• If you know which documents are driving the display, observe CBLDocumentChangedNotifications on just those

The live-query is generally the most convenient, but also the most expensive.

PS - I have looked at the code of the demo grocery app. Currently my app determines the sync is complete when pull.completedChangesCount = pull.changesCount.

That's not reliable. The changesCount gets adjusted as the replication progresses, because the puller is streaming a list of changes from the server and adds them to its queue as they arrive. What you should do is look at the status property and watch for it to change to idle or stopped.

Note that an idle replicator is not a guarantee that everything in the db is completely consistent. It's possible (if unlikely) that another client is halfway through pushing a set of changes to the server, and your replicator pulled all of the changes so far and went idle, even though there are more changes to come once the other client sends them.

(In general, there is no notion of 'transactions' in a fully distributed system, so you don't get the kind of referential integrity that you may be used to in a relational database.)

—Jens