cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: [Android] Where did webView.getPlugin() go on 4.0.x
Date Tue, 15 Jul 2014 23:43:15 GMT
On Tue, Jul 15, 2014 at 3:47 PM, Ian Clelland <iclelland@chromium.org>
wrote:

> FYI, I don't have a lot of confidence in being able to make CordovaWebView
> a concrete class; that's what I spent two weeks on a couple of months ago,
> and in the end, it was a lot messier, and would break a lot of third-party
> code. <insert rant about Java and multiple inheritance here>
>

Worth discussing specifics of what you think it would break I think. My
thinking is that a move from "something that extends View" to "something
that does not extend view" is a night-and-day change in terms of API, so
might as well just design it how we want it so that we can keep it stable
going forward. Even with AndroidWebView, which extends WebView and
implements the interface, you can't use it as a view without explicitly
casting it.


>
> I would really really *really* like the 4.0 plugin API to be as
> backwards-compatible as we can possibly make it. The only exception that I
> know of that we can't get away from is the getPlugin interface, for plugins
> to communicate with each other. That's a pretty small subset of the
> existing plugins, and I think that we can ease those developers through the
> transition, if we are really proactive at getting the word out to the
> community about the change.
>

If we make it a class, we could add back the pluginManager public field...
I don't love it, but if we make it final then at least it's not too
horrible.

The bigger change (IMO) is making CordovaWebView not a view though, so I
think we should change the API to be how we want it in 4.0 so as to not
need a 5.0 for as long as possible.


>
> Every change that we make to the public API is going to make it harder for
> people to switch. If we change something that touches every single plugin
> out there, then people will stay with the 3.x branch (or earlier!) forever.
>

Agree - we should keep the API used by plugins as stable as possible. But
right now, I think the only API we've seen plugins use is
pluginManager.getPlugin() (which we changed). I've been testing with all
cordova plugins and all chrome plugins with 3.x and 4.x and they all work
fine. We should add more to this list before we release anything, but I'm
optimistic most plugins will work fine.


> We shouldn't have to go the list to justify every change; as committers,
> we're all granted some level of trust within the group, but maybe we should
> slow down a little bit, and hash out an external API for 4.0.x in a doc
> somewhere, and try to stick to it. (My vote would be to take what we have
> already in 3.x, make the inter-plugin communication methods sane, without
> public member access, and document it)
>
>
>
> On Tue, Jul 15, 2014 at 3:35 PM, Andrew Grieve <agrieve@chromium.org>
> wrote:
>
> > Hmm, yeah, I don't like breaking things, but we need to have a way to
> make
> > changes to 4.0.x without too much debate as well. We didn't have an email
> > discussion for each symbol that was added to the interface, and it's not
> > feasible to do so going forward (for an interface, any change, add, or
> > remove of a function breaks compiles).
> >
> > My goal in removing getPlugin() was just to cut down on the amount of
> copy
> > & paste code between AndroidWebView and *WebView. My latest line of
> > thinking is that CordovaWebView should be a concrete class that contains
> a
> > CordovaWebViewEngine. If this were the case, I think a getPlugin() method
> > would make even more sense. Don't have time to do any more changes in
> this
> > week probably though.
> >
> > The only code I'm aware of that uses 4.0.x is AndroidWebView +
> > https://github.com/clelland/cordova-crosswalk-engine. I'm quite happy to
> > make sure these always compile at HEAD when making changes. Indeed I
> would
> > have had to revert fewer of my own changes if I checked that before
> > commiting. If there are other repos I should be looking at, then please
> let
> > me know. Next time I'm at it I'll check in a script to do test compiles
> of
> > everything so as to not break things anymore.
> >
> >
> >
> > On Tue, Jul 15, 2014 at 2:26 PM, Joe Bowser <bowserj@gmail.com> wrote:
> >
> > > OK, now third-party chrome doesn't work anymore.  I can't get the
> > > third-party WebView that we've been working on for months to work. I
> > > really need this to work, and I'm going to have to go off a branch
> > > that's months old because someone decided to undo months of work on a
> > > whim. Honestly, I'm cool with the branch being somewhat fast, but you
> > > do have to realize that you're working with other people on this
> > > branch.  Can you please stop doing this?
> > >
> > > On Tue, Jul 15, 2014 at 11:01 AM, Ian Clelland <iclelland@chromium.org
> >
> > > wrote:
> > > > Looks like it went missing in efcedab (according to git log -S)
> > > >
> > > > Agreed that it's frustrating. (And I liked getPlugin, too). I'd like
> > for
> > > > the 4.0.x branch to remain pretty fast-moving; I don't want to have
> to
> > > have
> > > > long discussions on the list before every commit, but breaking the
> > public
> > > > API isn't good. It breaks everyone's workflow, since we all have code
> > > that
> > > > lives outside of the core that relies on it.
> > > >
> > > >
> > > >
> > > > On Tue, Jul 15, 2014 at 1:56 PM, Joe Bowser <bowserj@gmail.com>
> wrote:
> > > >
> > > >> I was talking about getPlugin(), not getPluginManager().  We used
to
> > > >> have that method, and it's gone, and I'm asking here hoping that I
> > > >> don't have to sift through the 30 commits that were put in the repo
> to
> > > >> figure out where it went.  If there was a good tool to check all 30+
> > > >> commits that happened, that'd help too, but this is extremely
> > > >> frustrating, since I want to demo something.
> > > >>
> > > >> On Tue, Jul 15, 2014 at 10:48 AM, Andrew Grieve <
> agrieve@chromium.org
> > >
> > > >> wrote:
> > > >> > I don't think it's been removed:
> > > >> >
> > > >>
> > >
> >
> https://github.com/apache/cordova-android/blob/4.0.x/framework/src/org/apache/cordova/CordovaWebView.java#L81
> > > >> >
> > > >>
> > >
> >
> https://github.com/apache/cordova-android/blob/4.0.x/framework/src/org/apache/cordova/AndroidWebView.java#L732
> > > >> >
> > > >> >
> > > >> > On Tue, Jul 15, 2014 at 1:33 PM, Joe Bowser <bowserj@gmail.com>
> > > wrote:
> > > >> >
> > > >> >> Hey
> > > >> >>
> > > >> >> One of the new API methods that we added to the WebView was
> > removed.
> > > >> >> I'm not sure why it was, since we now have to get a PluginManager
> > to
> > > >> >> get a plugin.  Aren't we closing off access to the PluginManager?
> > > >> >> Seriously, this should have been discussed before we commit
> things.
> > > >> >>
> > > >> >> Joe
> > > >> >>
> > > >>
> > >
> >
>

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