cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon MacDonald <simon.macdon...@gmail.com>
Subject Re: [Android] New Bridge: evaluateJavascript
Date Thu, 10 Mar 2016 20:18:47 GMT
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