I didn't say it was a private API what I meant is that based on what you shared that this Will be a new public API another bridge people can use with the current API not broken.
So a minor bump on the version is OK - Carlos @csantanapr > On Mar 10, 2016, at 4:03 PM, Joe Bowser <[email protected]> wrote: > > Well, If they add the method, the latest version of their plugin should > still work with older versions of Cordova. So, is this really the same > thing? > > On Thu, Mar 10, 2016 at 12:18 PM, Simon MacDonald <[email protected] >> wrote: > >> I think we are okay bumping the minor for this change not the major. >> >> I'm in favour of this bridge as long as we don't need to guard all the code >> with reflection. Using reflection to call evaluateJavascript would negate >> any performance bonus. So if we can use evaluateJavascript on Android 4.4 >> and above and then revert to LoadUrl on Android 4.3 and earlier for this >> bridge I say we go for it. >> >> I think we can give CrossWalk enough time so this doesn't completely screw >> them over. Also, if we give them a heads up they can make it so the plugin >> only installs on Cordova Android 5.1.1 and earlier. >> >> >> Simon Mac Donald >> http://hi.im/simonmacdonald >> >>> On Thu, Mar 10, 2016 at 2:51 PM, Joe Bowser <[email protected]> wrote: >>> >>> 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 >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
