Did you resolve this issue? I’m curious if you knew how long to leave a device before CBL becomes unresponsive.
I’m working on a similar project that uses the CBL RESP API. I’ve left a device untouched for 8 hours and the listener still seems to be working fine. I’m using the CBL 1.3 branch (1.3.0-45) though, which feels much healthier than 1.2.x. And I’m testing on a physical Android 5.1 device.
I’m using 1.2.1 and tested the Todo app again this morning. It’s still happening. Has 1.3 been released? If so, I’ll try again with that.
I don’t think its been released yet but 1.3 is already much better than 1.2x. I found the bugs in 1.2 made it unusable (both in iOS and Android). You can upgrade by adding something like this to your gradle:
compile 'com.couchbase.lite:couchbase-lite-android:1.3.0-45'
compile 'com.couchbase.lite:couchbase-lite-java-listener:1.3.0-45'
compile 'com.couchbase.lite:couchbase-lite-java-javascript:1.3.0-45'
I’ve been trailing 1.3 for a a while now and its getting better all this time.
The nightly builds are here: http://latestbuilds.hq.couchbase.com/couchbase-lite-android/1.3.0/
How long do you have to leave it before the listener shuts down?
1.3 was released last Friday.
Note you can automatically track updates using wildcarding in dependencies. For example, use
compile 'com.couchbase.lite:couchbase-lite-android:1.3.+' compile 'com.couchbase.lite:couchbase-lite-java-listener:1.3.+' compile 'com.couchbase.lite:couchbase-lite-java-javascript:1.3.+'
I know this is off topic, but I feel strongly enough about it that I want to warn you, and anyone else reading.
Using wildcards in your build dependencies, is (in my opinion), a really really bad thing to do. From experience it has cost me many hours, and saved me none.
One time, my team searched for hours for an explanation as to why 2 seeming identical builds did not behave the same way. A bug had crept in but no code had been committed. Turns out that some dependency got updated in the background, of course no one noticed, and that dependency change introduced a bug. Just a little minor version number update - harmless right? Wrong. We were lucky we caught it before going to production. Imagine doing all your testing on a version of the software, then doing one final build for the prod release which you then ship… and it picked up a bug in the build process! I used to work in finance and putting untested code into production would easily be a sackable offence.
And wildcards save you no time. Upping a version number manually is not a time consuming task. If you have a decent tool set its very easy to know when new versions become available. If a dependency does change you NEED to know about it, and you need to test it, same as you do your own code.
Using wildcards in your dependencies is, in my opinion 
just a very very expensive way to ensure that one day your software isn’t going to work.
Sorry. Rant over.
Thank you @hod.greeley and @nick-couchbase for your input.
The ticket filed for this issue has been assigned to 1.3.1 release.
Nick, you definitely raise a good point. People should be aware that can happen.
One suggestion is to keep the wildcard for initial development (especially when using something like a developer preview version), but make sure production builds tie to a specific version. I just like to pull updates automatically at times instead of having to check manually.
My advice is firmly do not ever ever use wildcards, for any reason at all. Ever. Not once. Don’t do it. Never ever.
Get decent tool set that makes upgrading, and spotting upgrades, painless.