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

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

I'm very hesitant to change the API just for a single device, especially since 
it's on 3.7.x, which we only offer support w.r.t security fixes, because it's 
been less than six months since 4.0.x has been released.  I'll have to test 
this on my Samsung Galaxy S3 to see if I can get the same behaviour.  More 
testing will definitely be necessary.

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

Reply via email to