Maybe we can do a Cordova Android 6.0 and sync it with Android N support when it comes out and this new bridge.
On Thu, Mar 10, 2016 at 7:29 PM Joe Bowser <[email protected]> wrote: > 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] > > > > > > > > >
