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 Fri, 11 Mar 2016 00:29:09 GMT
On Thu, Mar 10, 2016 at 3:54 PM, Darryl Pogue <darryl@dpogue.ca> 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 <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