On Thu, Mar 10, 2016 at 3:54 PM, Darryl Pogue <[email protected]> wrote:
> If it's an addition to one of the public interfaces, doesn't that require a > major bump because every existing implementation of the interface would now > cause errors due to missing methods? > > Yeah, I hate semver. Right now we only have one existing implementation (Crosswalk), and that's the only thing that's affected by it. If people didn't think "Oh, it's a major version, everything is going to be broken!!!" just because we added literally one call, I'd probably not have an issue with the practice, but because of semver, this change is going to probably be delayed because people don't want to jump another major version so soon. As far as avoiding it, well, you kind of can't without using reflection to determine whether your view has that method it begin with. Having to come up with a technical solution to people's fear of bigger version numbers is how we get more bugs in our code. Semver aside, this change sounds good to me. I've definitely encountered > some bizarre issues with the online/offline events being used for bridge > communication (like navigator.online getting permanently toggled to false). > Can you reproduce this reliably? I've asked for repro code from the person who mentioned this, but I can't get it for unknown reasons. > > On 10 March 2016 at 15:48, Carlos Santana <[email protected]> wrote: > > > 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] > > > > >
