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] Not so fast....API changes in Cordova-Android for Pluggable WebView
Date Tue, 20 May 2014 17:58:46 GMT
It may have passed the mobile spec tests, but it shat the bed on the
changed JUnit tests. :(

The fact is that the CordovaWebView has to be a view to support the
users who use embedded webviews of some type.  We're already breaking
this with third party WebViews, but it's a minor breakage where
someone just has to change their view name to AndroidWebView for this
to work again.  With this new layout, it's impossible to support the
XML layout namespace for people who are seeking to embed enhanced
webviews in their applications.  Embedding views that are based on
CordovaWebView is one of those features that we would like to keep if
possible,

So, I think we should break backwards compatibility slightly in 4.0
instead of losing an entire feature with this change.

On Fri, May 16, 2014 at 1:43 PM, Ian Clelland <iclelland@chromium.org> wrote:
> Ugh... so I finally managed to get back to this, and spent a day and a half
> refactoring the AndroidWebView class.
>
> I've pushed the results to a branch of cordova-android called
> "backwards_compat". (See
> https://github.com/apache/cordova-android/tree/backwards_compat)
>
> It passes all of the mobile spec tests that 3.5.0 passes, for me (I get a
> couple of fails on contacts, because my test device has too many contacts,
> and there is a battery-status test which has been failing recently).
>
> It's kind of ugly, but it's what we'll need to do to maintain backwards
> compatibility with existing plugins. The question now is "is it worth it?".
> Or do we just delay all of this until we want to break
> backwards-compatibility, say with Cordova 4.0?
>
>
> On Fri, May 2, 2014 at 11:17 AM, Leo Yang <leoyang.webkit@gmail.com> wrote:
>
>> Since you talked about plugin so do you plan to introduce/merge xwalk
>> extension mechanism to Cordova plugin mechanism?
>>
>> Thanks,
>> Leo
>>
>>
>> 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.
>> >
>> > 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.
>> >
>> > So, how do people want to handle these changes?  We constantly get
>> > shit for changing our API when we do development, but I do think these
>> > improvements are extremely important, especially given how much flak
>> > we get for relying on Android's WebView.
>> >
>> > Thoughts?
>> >
>> > Joe
>> >
>>

Mime
View raw message