Recommended approach to app suspend/resume when running CBL continuous replicator

The documentation seems to make no mention of what to do with a continuous Couchbase Lite replicator if the mobile app suspends/resumes. Will LiteCore/CBL deal with this internally – will it stop by itself, will it disconnect (cleanly) by itself? – or does the app need to make sure it stops the replicator on app suspend and restart the replicator on app resume? Or should a continuous replicator always be run as a background service, so it continues even if the app is not in the foreground?

I have been struggling with this so I was wondering what the recommended approach is for this.

Swift / Obj-C will manage this for you but for all other platforms you must manage this yourself.

So if your replicator is still running when your app is suspended, and the OS terminates it, then it’d be a sudden unclean disconnect?

I tried to clean up the replicator on a suspend event, but I am not sure if I succeeded, I need to spent some more time on it.

There would probably be a disconnect before that time on platforms that don’t manage this for you because the program would not be responding in the background (except maybe Android? I’m not familiar with how it works but I don’t think it suspends in the same way). If the replication is running (foreground or background) and the app is terminated then it is no different than as if the app suddenly crashed and the disconnect would be unclean.

Thanks for the information Jim.

Jim is correct. Leaving a continuous replication going in Android is a bad idea. I believe that there are two good strategies for managing replications on Android:

  1. in a foreground service: I believe that this is the only reasonable place to put a continuous replication.
  2. in a Work Manager task. Not continuous and managed by the app. This is much more Android-like and much easier on the battery.
1 Like

FYI - discussed in " Replication Status and App Life Cycle" section of our docs

The best practice approach for Android is quite short. I didn’t find any code samples on how to implement the best practice on github. This also wasn’t mentioned in the dedicated CBL Mobile 3 day course. I use CBL 1.4 in production, start the replicator and leave it alone. I never came across a bug report over the years about it running a long in the background. Also there is basically no background activity shown in the Play Store console under Android vitals. Then again they only seem to report Alarm manager wake ups. If you @avia_bdg have a snippet on how you handle starting the continuous replication and when and how you decide to stop it and would share it. That’d be great!

I use Xamarin Forms for iOS and Android with the Couchbase Lite for .NET. Xamarin provides overrides for App OnResume() and OnSleep().

1 Like

Thank you for sharing. I believe these methods then call Android’s lifecycle method onResume() and onPause(). I think I won’t stop the replicator in onPause.() One of my use cases is:

  • user makes an edit
  • user leaves app straight away
  • onPause is called and replicator is stopped. If the replication didn’t happen fast enough, i.e. spotty network then the change wasn’t pushed up

Would you think that your users might run into this, too?

If your user leaves the app then it can be closed by the OS at any time anyway, so you can never guarantee a sync completes unless the user stays in the app until you tell it the sync has been done – version 2.5+ has sync events informing you when Documents have been pushed in the replicator. You don’t really have much control over your app once the user suspends it, unless you run some background service that syncs periodically. I haven’t yet gone to anything background.

If your objective is to wrap up ongoing replication when user leaves the app, then as Blake suggested above, using a work manager. There doesn’t seem to be a reason in your use case why you need replication running in continuous mode in the background . If for whatever reason you need the replication running in the background, then consider using a service.