cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <>
Subject Re: [Android] Not so fast....API changes in Cordova-Android for Pluggable WebView
Date Wed, 30 Apr 2014 17:30:33 GMT
On Wed, Apr 30, 2014 at 9:35 AM, Michal Mocny <> wrote:
> On Wed, Apr 30, 2014 at 12:23 PM, Joe Bowser <> 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.

View raw message