cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: [Android] New Bridge: evaluateJavascript
Date Thu, 10 Mar 2016 21:03:44 GMT
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 <simon.macdonald@gmail.com
> 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 <bowserj@gmail.com> wrote:
>
> > On Thu, Mar 10, 2016 at 11:48 AM, Carlos Santana <csantana23@gmail.com>
> > 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 <bowserj@gmail.com> 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 <
> csantana23@gmail.com
> > >
> > > > 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 <bowserj@gmail.com>
> > 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
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message