cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darryl Pogue <dar...@dpogue.ca>
Subject Re: [Android] New Bridge: evaluateJavascript
Date Thu, 10 Mar 2016 23:54:04 GMT
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?

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).

On 10 March 2016 at 15:48, Carlos Santana <csantana23@gmail.com> 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 <bowserj@gmail.com> 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 <
> 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
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>

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