I don't think we need to bump major number, there is no public API brake we are just added a feature, old stuff will still work.
On Thu, Mar 10, 2016 at 2:41 PM Joe Bowser <[email protected]> wrote: > 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 > > > > > >
