[
https://issues.apache.org/jira/browse/CB-9227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
davidhadas updated CB-9227:
---------------------------
Environment:
S3 Neo android 4.3 device
Cordova 4.30 Android Platform 3.7.1
was: S3 Neo android 4.3 device
> Malfunction OnlineEventsBridgeMode
> ----------------------------------
>
> Key: CB-9227
> URL: https://issues.apache.org/jira/browse/CB-9227
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android, CordovaJS, CordovaLib
> Environment: S3 Neo android 4.3 device
> Cordova 4.30 Android Platform 3.7.1
> Reporter: davidhadas
> Assignee: Joe Bowser
>
> While hunting a bug resulting in file API not reporting success/failure
> during asynchronous calls, we had learned that OnlineEventsBridgeMode
> (NativeToJsMessageQueue.java) seem to be broken. We noticed that from a
> certain point in time, the Boolean online was always set to false during:
> toggleNetworkRunnable {
> ...
> webView.setNetworkAvailable(online)
> }
> Consequently there were no more online/offline events triggered at the JS and
> no more consequent polling of messages.
> To be more precise, events from JAVA to JS were delivered only when someone
> from the JS was calling androidExec (cordova.js) and never during
> online/offline events.
> As a result, we were always missing the last set of events as there were
> stuck down at the JAVA queue resulting in application freeze.
> (Once that started, the Boolean online was no longer being toggled via
> notifyOfFlush resulting in a permanent failure resolved only when reloading
> the software).
> As far as we understand, WebView only deliverers online/offline events to JS
> if the state of the Network changes i.e. if after a call to
> webView.setNetworkAvailable(false) one would call
> webView.setNetworkAvailable(true) and vice versa. This means that by design,
> Cordova seeks to maintain the Boolean online to maintain the inverse state of
> the WebView Network state. If/when the Boolean online looses track of the
> WebView Network state, the system online/offline events are discontinued
> until software reloading.
> Till now we were unable to track down the exact sequence leading the Boolean
> online to loose track of the WebView Network state in our system, but we do
> notice a sequence of two consecutive calls to notifyOfFlush, flipping the
> Boolean online twice - thereafter the Boolean online seem to have lost track
> of the WebView Network state and online/offline events no longer propagated
> to JS.
> If our understanding is indeed correct..... than, our main concern is that
> this design does not converge to a stable state and that inview of the
> asynchronous nature of the design and reliance on WebView specifics, a KISS
> methodology which would not put the code at risk of coming into a complete
> halt in view of a single mishap may be better. I.e. a design with a better
> self healing property following mishaps.
> We tried out a simple modification by replacing:
> webView.setNetworkAvailable(online);
> with:
> webView.setNetworkAvailable(true); // trigger an event
> webView.setNetworkAvailable(false); // reset the webView to its default
> state
> This had apparently solved the issues in our S3 Neo android 4.3 device though
> more testing are needed.
> If this approach is adopted, it requires cleaning up the code and removing
> now redundant code such as the notifyOfFlush mechanism which would no longer
> be needed, same for the JS event listener for offline events etc. This we
> hope would result in overall simplification of code in this area and better
> stability and endurance to mishaps. On the negative side, this alternative
> design results in doubling the amount of times in which
> webView.setNetworkAvailable() is toggled - forcing certain overhead. Yet,
> notice that there is no longer a need for cordova.js to listen to offline
> events, such that the added offline processing is now limited to the WebView
> internal overhead which is likely to be slim.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
