cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject Re: [Android] Not so fast....API changes in Cordova-Android for Pluggable WebView
Date Tue, 20 May 2014 18:27:00 GMT
Fair enough... (grumble grumble multiple inheritance...) I suppose that
this was an experiment to see if we could somehow maintain compatibility
with plugins that use the old public field. I was worried that there would
be issues with the CordovaAndroidWebView not *being* a View anymore --
thanks for verifying that.

(Incidentally, Andrew brought up the possibilty of making CordovaWebView in
this case a subclass of View, or maybe of AbsoluteLayout, so that it can
still *be* a view, and it can just manage its single child as a subview.
Would this allow the embedding use case, or would it still be problematic?)

If we're going to break things in 4.0, we should start by adding a getter
for the pluginManager right now, for 3.6.0. Then we can at least start
using it in our plugins, and we can encourage other plugin devs to use it
as well. We can start an actual API for inter-plugin communication, and
then the old ad-hoc methods get deprecated with the 4.0 release.



On Tue, May 20, 2014 at 1:58 PM, Joe Bowser <bowserj@gmail.com> wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message