cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <>
Subject Re: Cordova issue.
Date Mon, 22 Jun 2015 15:46:50 GMT
+ dev@ mailing list

There have been (fixed) bugs with the online bridge in the past. Are you
running a recent version of cordova-android?

As a quick fix, you can switch to use the PROMPT-based bridge.

On Sun, Jun 21, 2015 at 6:31 PM, David Hadas <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message