cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: [Android] Not so fast....API changes in Cordova-Android for Pluggable WebView
Date Wed, 30 Apr 2014 17:58:52 GMT
On Wed, Apr 30, 2014 at 1:30 PM, Joe Bowser <bowserj@gmail.com> wrote:

> On Wed, Apr 30, 2014 at 9:35 AM, Michal Mocny <mmocny@chromium.org> wrote:
> > On Wed, Apr 30, 2014 at 12:23 PM, Joe Bowser <bowserj@gmail.com> wrote:
> >
> >> Hey
> >>
> >> So, once again, we're dealing with some major API changes once we
> >> introduce pluggable webview.  The first change that was done for
> >> sanity was finally deprecating setProperty.  This was slated to be
> >> removed by 3.5 or in six months from the deprecation date, but we kept
> >> it in too long.   While I would like to assume that everyone has moved
> >> over to setting their preferences in config.xml, which is the much
> >> more sane way of doing things, we can't do that.  We need to publicize
> >> this in some blog posts, as well as in our documentation somehow.
> >> There will obviously be some pissed off users, as we've seen in past
> >> posts, but I think having the ability to use a WebView other than
> >> Chrome 30 is worth these changes.
> >>
> >
> > Is it feasible to leave setProperty working only for default WebView?
>  This
> > would mean that custom webviews won't work with older plugins, but I
> think
> > thats fine.
> >
>
> The setProperty methods are actually in Cordova-Activity, and we could
> re-add those.  The thing is that these aren't actually used by
> plugins, and instead are legacy methods that only our unit tests use.
> I'll put them back in.
>
> >
> >>
> >> The other change, which says more about our design is adding a getter
> >> method for pluginManager.  We need to access the pluginManager to get
> >> plugins, and it's expected that everyone who implements a
> >> CordovaWebView will have this method produce a pluginManager.  In the
> >> past, it was just publicly exposed, which was not the greatest idea
> >> and was kinda sloppy.
> >>
> >
> > Similar to above question, could we leave it (deprecated) as an exposed
> > property only on the default webview?  And only support the new getter
> for
> > new webviews (xwalk, gecko)?  Again, only updated plugins would work with
> > custom webview, but I think thats fine.
> >
>
> No, I don't think so.  It's probably better to make a clean break and
> have all the WebViews expected to function the same than to have some
> plugins simply fail with certain webviews.  Plugins breaking across
> all the WebViews will force people to fix them, while things breaking
> with only Crosswalk will put crosswalk at an unfair disadvantage.
>

Trust me, Crosswalk is going to have an unfair *advantage* regardless of
plugin support ;)

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