cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject Re: 4.0 Sprint Tasks (Another "Hey, let's ship 4.0.x soon" post)
Date Mon, 08 Dec 2014 15:02:47 GMT
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.


>
> 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.


> 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)


> 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