davidhadas created CB-9227:
------------------------------
Summary: 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
Reporter: davidhadas
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]
