+ 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
>
