Well, since the problem is with ONLINE_EVENT having a race condition, earlier versions of Android would have to use the slower LOAD_URL with known issues related to the input fields. There's more testing that needs to be done, obviously, but it's worth adding the third bridge in the next major release.
I'm just wondering how people feel about bumping another version. I don't think our users understand that we use semver at all, which makes things extremely frustrating. On Thu, Mar 10, 2016 at 11:30 AM, Carlos Santana <[email protected]> wrote: > But what about 4.3 and lower versions of Android? How do we support them? > Do we use ONLINE_EVENT if we detect were are running on those versions of > Android? > > > On Thu, Mar 10, 2016 at 1:36 PM Joe Bowser <[email protected]> wrote: > > > So, apparently some people are reporting that the ONLINE_EVENT bridge > that > > we currently use by default in Android has a race condition when you > start > > using more than one WebView in an application. Even though we decided to > > not support the case of having multiple webviews in an Application, it's > > still being used this way. > > > > Ideally, I would like to see us figure out how we can change the bridge > > modes so that we don't have so many static classes, or at least change > them > > such that we're not tracing mutable states in static classes. However, > > someone asked about evaluateJavascript and using that for the bridge. I > > implemented that really quick here: > > > > https://github.com/infil00p/cordova-android/tree/building_bridges > > > > Basically, this should get around the whole bridge state problem since > > we're executing the JS on the right webview every time instead of trying > to > > manipulate a static variable that may or may not correspond to the > webview > > that we're using. Also, the benchmarking on this initially seems > > comparable to ONLINE_EVENT. > > > > There's also the fact that it's a lot less code than ONLINE_EVENT, due to > > the whole state thing. The main thing that ONLINE_EVENT has over > > evaluateJavascript is that it works on Jellybean (4.3 and lower). > > > > This branch does add a method to the API, and Crosswalk would have to add > > the same two lines of code to their WebView to allow evaluateJavascript > to > > work there as well as it does here. I did check to make sure their API > > does support it before I added it. > > > > So, is this useful? Should we merge it in? Do we increment a major > version > > number for this? > > > > Joe > > >
