cordova-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joe Bowser (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CB-9227) Malfunction OnlineEventsBridgeMode
Date Mon, 22 Jun 2015 22:08:01 GMT

    [ https://issues.apache.org/jira/browse/CB-9227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14596739#comment-14596739
] 

Joe Bowser commented on CB-9227:
--------------------------------

As Andrew asked earlier on the Cordova list, can you specify which version of Cordova you're
using.  We haven't seen this behaviour on Cordova with the bridge in any of our tests, and
this would be very apparent when testing something such as devicemotion, since we're setting
a watch and waiting for async calls.

> 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
>            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: issues-unsubscribe@cordova.apache.org
For additional commands, e-mail: issues-help@cordova.apache.org


Mime
View raw message