On Thu, Mar 10, 2016 at 11:48 AM, Carlos Santana <[email protected]> wrote:
> I don't think we need to bump major number, there is no public API brake > > This isn't a private API. This API is how third parties like Intel can make things like Crosswalk. > we are just added a feature, old stuff will still work. > Except that Crosswalk now has to implement evaluateJavascript on their XWalkEngine class. At least this won't need a crap ton of reflection code like the last API change. > > 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 > > > > > > > > > >
