@jamiltz ,
Let me clarify “user leaves the app”, the app is background mode and is paused. If the app is shutdown and restarted, everything with CBL is fine. But there’s no way through code to do a full shutdown and restart with Cordova.
Hi @agillette,
I have one request to verity.
From your comment, once the app resumed, the app can obtain URL of CBL REST API endpoint. Can you try to access its URL from Android browser or to access from out-side of Android device/emulator by browser or curl command?
If Http server can response, JavaScript or WebView which is used by Cordova/PhoneGap has issue.
If Http server can NOT response, Couchbase Lite Java Listener has issue or enter bad state.
But when trying to connect to the app database, the API call stays in “pending” mode, no response.
Could you please share the details of “pending” mode? If you wait for a while, do you receive timeout or some error response?
We’d like to reproduce this issue, could you please provide CBL for PhoneGap version?
Thanks!
Hi @hideki,
I’m pretty sure that the WebView is not the issue. On resume, cblite.getURL(function (error, url) is working. But if I make a REST call to my database, the calls are pending.
I’m going to modify my to make a call to sync gateway on resume. If it responds and the REST call to the local db doesn’t, we’ll know that the WebView is not the culprit.
I’ll let you know in 30 mins.
You can use the reference TODO-LIst app to try to reproduce the issue.
BTW - I’m using 1.2.1.
I just ran a test where on resume my code is making two calls, one to the local db and one to sync gateway. The sync gateway responded with 200, where as the local db is still in “pending” state. This proves to me that the problem is with CBL and not the WebView.
@hideki: It could be that the OS has closed the TCP listener socket. (For comparison, iOS does this when an app has been backgrounded too long and/or the device locks.)
Hi @agillette,
Thank you very much for sharing additional information.
To track this issue, I created the ticket in github.
Thanks,
Hideki
Thanks @hideki,
Please keep me posted. I’m planning to submit my app into both Apple and Google app stores in two weeks.
For future reference, if something is definitely going wrong (as in this case), it’s more efficient to report it by filing an issue on Github, rather than posting a thread here.
But in this case it’s a little challenging to determine which product has the issue. I’m wasn’t sure if it’s phonegap plugin, the the java library, or something else.
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.