cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: 4.0 Sprint Tasks (Another "Hey, let's ship 4.0.x soon" post)
Date Mon, 08 Dec 2014 16:22:31 GMT
Have time at the airport to do some work.

On Mon Dec 08 2014 at 7:03:16 AM Ian Clelland <iclelland@chromium.org>
wrote:

> On Sun Dec 07 2014 at 11:54:29 PM Joe Bowser <bowserj@gmail.com> wrote:
>
> > Hey
> >
> > After messing with the JS for a week, I decided for now to stop work on
> > MozillaView.  I think I've managed to prove that the concept is at least
> > possible, but I really feel that it's still too unstable to actually show
> > past a demo/POC at this time.  We've definitely learned some lessons, and
> > I'll probably write a blog post on them soon, and pick up work in the new
> > year.
> >
>
> I'm glad that it's at least possible, even if it's not trivial. Do you
> think there are any other changes we'll need to make -- hooks that we'll
> need to provide -- before that project can be called a success? If so, I'd
> want to at least consider making those changes for 4.0, so we don't have to
> make another major version bump for MozillaView.
>
>
>
The work is mostly done.  The problems are that GeckoView is still a moving
target, and annoying things break.  For example, the stupid simple
fetch_libs script broke when I tried to fetch the libs because they're
doing a new sort based on all the different Android attributes (API 10, x86
vs arm6, etc).

That said, the most annoying part was trying to figure out how a plugin
could override exec.  That's something that I couldn't figure out at all
last week.  Writing basic plugins, and even changing cordova-js is fairly
easy, but this seemed next to impossible.  I found that our own stuff
slowed me down more than changes Mozilla did.


> >
> > That said, we should really concentrate on shipping 4.0 in January, we
> > should do the following:
> >
> > 1. Bump up the targeted version to 5.0
> > 2. Allow for users to target KitKat for Quirks Mode (I'm not kidding,
> > Quirks mode is back.  Chrome is the new IE! WTF MAN!)
> >
>
> Hasn't Android always done that? I thought that was the whole point of
> targetSdkVersion (maybe not webview specifically, but device quirks in
> general). Anyway, +1 to letting the developer set it if necessary.
>
>
> Yes, it has.



> > 3. Get the gradle work in.  MUCH FASTER! LESS SPAM! WOW!
> >
>
> It's pretty much all in, and should be the default in 4.0 (I'll check that
> to make sure it's true). The last piece is the AAR library support, which
> I'm going to test and merge this week.
>
> 4. Get the JUnit tests working with Gradle/Android Studio.  I don't think
> > this is a 4.0 task per-se, but we should do it right after 4.0 is
> released.
> > 5. Stare at the pie chart wishing that 9 was 5.  (Anyone who knows our
> > deprecation policies knows EXACTLY what I'm talking about).
> >
> > I do have one API change I want to make.  I want to rename the
> > CordovaWebView interface CordovaWebInterface so that it's obvious that
> it's
> > an interface.  Since people using the old CordovaWebView embedded feature
> > are going to have to do a find/replace on the XML, this doesn't really
> > matter.
>
>
> If you're convinced that it's not going to cause any additional pain for
> the developers, then I say go for it. It makes more sense as a name (It's
> messed me up more than once, looking for the *actual* view class)
>
>
Well, I'm not 100% convinced, but the people who use the feature need to
speak up now.


>
> > Of course, the people using this feature may beg to differ.  If
> > you're using this feature, and you care about it still working with your
> > current code, PLEASE TEST 4.0 NOW.
> >
>
> Strongly agreed.
>
>
>
> >
> > Thoughts?
> >
> > Joe
> >
>

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