+ dev@ mailing list There have been (fixed) bugs with the online bridge in the past. Are you running a recent version of cordova-android? https://issues.apache.org/jira/browse/CB-6761 https://issues.apache.org/jira/browse/CB-6746
As a quick fix, you can switch to use the PROMPT-based bridge. On Sun, Jun 21, 2015 at 6:31 PM, David Hadas <david.ha...@gmail.com> wrote: > Hi agrieve, > > While hunting what initialy appeared to be a "file plugin bug" on a an S3 > Neo android 4.3 device, we had learned that OnlineEventsBridgeMode seem to > be broken on that device. We noticed that from a certain point in time, > the boolean *online* was always set to false during toggleNetworkRunnable > { ...webView.setNetworkAvailable(*online*) } - hence *online* was no > longer toggled via notifyOfFlush - consequently there were no more > webView *online *events sent out to the JS. From that moment events from > JAVA to JS were delivered only when someone from the JS was > calling androidExec (cordova.js) and we were always missing the last set of > events as there were stuck down at the JAVA queue. > > We realized that the OnlineEventsBridgeMode depends on the boolean > *online* always being maintained as an inverse of the WebView > online-state. Once it is reversed for any reason/bug, the system never > corrects itself. > > Till now we were unable to track down the exact sequance leading to the > reversal event, but we do notice a sequance of two consecutive calls to > notifyOfFlush, > flipping *online* twice - thereafter *online* is left unchanged (stuck on > teh wrong value). > > In fact we are somewhat uncomfirtable with the design choice of using > online toggling and blindly trying to keep the *online* variable as an > inverse of the WebView state. Our main conccern there is that this design > does not converge to a stable state and does not follow a KISS methodology > which may be painful in view of the asynchnous environment, dependency on > different WebView implementations etc, as a result implementation issues > and bugs such as the one we encuntered are more likely. We are wondering > about a simpler design choice of replacing: > webView.setNetworkAvailable(*online*); > with: > webView.setNetworkAvailable(*true*); // trigger an event > webView.setNetworkAvailable(*false*); // reset the webView to its > default state > thereafter removing redundent code such as the notifyOfFlush mechanism > which would no longer be needed, the JS event listener for offline etc. > > This apperently solved the problem with that S3 NEO android 4.3 - but may > be a better strategy to follow alltogether. > If so, we might be able to take the challange and suggest a patch or > better so, work with an existing contributer to create one. > > Please advise, > David Hadas >