Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of agrieve@google.com designates
 209.85.214.180 as permitted sender)
MIME-Version: 1.0
Sender: agrieve@google.com
In-Reply-To: 
 <CAOBL_k6NK0c0iTEoyEjKAYbUKX8tBJN5juCdJ2KkmLLXqbCe6Q@mail.gmail.com>
References: 
 <CAOBL_k5uBxgF0SoN5UesQbsyjX3OSvX3inf9W+EZe=njkpfv-w@mail.gmail.com>
 <CABiQX1WuFgidpoacF7++HuWiYLjDbOjodsE-AbAsmhv+VzJsTg@mail.gmail.com>
 <CAOBL_k6NK0c0iTEoyEjKAYbUKX8tBJN5juCdJ2KkmLLXqbCe6Q@mail.gmail.com>
From: Andrew Grieve <agrieve@chromium.org>
Date: Wed, 9 Jul 2014 16:18:34 -0400
Message-ID: 
 <CABiQX1XdDTZYRzhZMJwJh-sKpx+Bzzx3QJHkCXqqBN3gq4L1Lg@mail.gmail.com>
Subject: Re: [Android] API changes
To: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=089e0149495cd030e004fdc86a85

--089e0149495cd030e004fdc86a85
Content-Type: text/plain; charset=UTF-8

On Wed, Jul 9, 2014 at 2:57 PM, Joe Bowser <bowserj@gmail.com> wrote:

> On Jul 9, 2014 10:22 AM, "Andrew Grieve" <agrieve@chromium.org> wrote:
> >
> > Most of the commits to cordova-android as of late were mine. I'm hoping
> > 4.0.x can be a commit-then-review kind of branch.
>
> Why?  Branching is super cheap in git.  If this was a normal repo, I'd be
> meh, but it's Apache git, which is weird. Reverting is non-trivial
>
Refactorings are super hard to merge when conflicts arise. It's been a pain
just merging master->4.0.x since any change to Cordova*Client or
CordovaWebView doesn't apply at all.


>
> > We're a long way out from
> > it being ready, so I think this will work well for now and as we get
> closer
> > to release we should be more cautious. It would be super-slow to ask
> before
> > making changes to 4.0.x, but I'm totally open to things being reverted /
> > discussed.
>
> Why would it be slow? If it takes 2 days to get your work to pass tests,
> keep it off a main repo until it does? I know we're not strict with TDD,
> but still, we shouldn't break the few tests we do have.
>
Sorry - I've been running mobilespec and making sure it's all green. I'll
have a look at the junit tests tomorrow.


>
> > WDYT? Maybe let's to an API walk-through once things settle to
> > make the final call on what we should keep & what we should change?
> >
>
> I honestly don't care about the changes landing as long as they don't break
> tests and demos. And, if they do, a heads up is really just an e-mail
> away.  I'm on PTO now until Monday, and I'm writing this while waiting for
> a ferry.  I think others will be on PTO as well, an e-mail will save us
> hours of sifting through patches trying to figure out what you did.  I
> didn't just create the test directory just because I needed busy work.
>

Awesome - yep, will try to be more ontop of emailing out changes.

>
> > Config.java - This I deprecated on both master and 4.0.x. The root of the
> > issue is that in its current form (singleton) it does not accommodate
> > having two CordovaWebViews with different settings. We're hitting this
> > problem in Cordova App Harness / Chrome App Developer Tool where we'd
> likei
> > the main webview to use the config.xml that was bundled with the app, and
> > have the child webview use a completely separate config - the one that is
> > uploaded to the tool at runtime. This really should be possible, but
> wasn't
> > with Config being a singleton. With this refactor/deprecation, webviews
> now
> > have their settings set programatically and CordovaActivity gets them
> from
> > config.xml by default. Should be 100% backwards compatible though, as
> > Config still exists and works in the same way.
> >
> > Some thoughts on goals for 4.0.x:
> > - Enable pluggable webviews with as little copy & pasted code as possible
> > - Delete most previously deprecated symbols
> > - Be 100% compatible with cordova apps that have not made native-code
> > customizations
> > - Ensure that all cordova, chrome, and Ionic plugins (any others?) are
> > compatible with both 4.0.x and 3.x.x either by maintaining APIs, or by
> > changing the plugins
> >
> >
> > From diving through the code over the past couple of weeks, I wrote a
> list
> > of other changes that I think would improve things:
> >
> > On master:
> > - Move KeyEvents into a plugin (e.g. even if it's a bundled one line
> > CoreAndroid)
> > - Extract SplashScreen into a plugin (looking through the code, seems
> this
> > is doable)
> >
> > On 4.0.x
> > - Share more code between XWalk and Android views. E.g. Maybe make
> > CordovaWebView a class, and create a WebViewEngine interface that they
> both
> > implement.
> > - Make AndroidWebView not extend WebView (or have XWalkCordovaWebView
> > extend XWalkView - just want them to be consistent in this way)
> > - Delete LinearLayoutSoftKeyboardDetect (functionality is provided by
> > Ionic's keyboard plugin based on LayoutChange listeners)
> > - Make CordovaInterface != CordovaActivity
> >   - I've mostly finished removing the requirement that they be the same,
> > just need to now make them not actually the same class. Thinking of doing
> > this by making the CordovaInterface a nested class within
> CordovaActivity.
> > - Move setting of disallowoverscroll into webview logic instead of within
> > CordovaActivity
> > - Delete shouldRequestFocusOnInit() within webview and instead have
> > requestFocus() called by CordovaActivity
> >
> > Other things that have been discussed by I'm not entirely sure about:
> > - Make default layout an AbsoluteLayout instead of a LinearLayout
> > - ActivityFragment
> > - Delete the LOG class
> >
> >
> >
> >
> >
> >
> > On Tue, Jul 8, 2014 at 6:01 PM, Joe Bowser <bowserj@gmail.com> wrote:
> >
> > > Hey
> > >
> > > I just noticed a ton of API changes on Android that I don't remember
> > > being discussed on the list landing in 4.0.x.  What's going on?
> > >
> > >
> > > For example, I thought we were going to keep this:
> > >
> > >
>
> https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=commit;h=eca05e6bad881fcd2ba928f76a28e0bb96d0e4b2
> > >
> > > Also, why is the config class being deprecated?  Why are these just
> > > being added to the repo without being talked about on the list first?
> > >
> > > Joe
> > >
> >
> >
> >
> > On Tue, Jul 8, 2014 at 6:25 PM, Joe Bowser <bowserj@gmail.com> wrote:
> >
> > > Hey
> > >
> > > I just noticed that there's been a ton of new commits on the 4.0.x
> > > branch, many of which change some public-facing APIs of Cordova.
> > > Landing this many patches into Cordova without bringing these up on
> > > the list isn't OK, since many of these changes will break any hope of
> > > an upgrade path for our users.
> > >
> > > Can we please make sure that heavy refactors happen on independent
> > > branches and are discussed on the list before they land in a release
> > > branch? I know that 4.0.x is a long way off, but I was planning to
> > > demo some of our work at OSCON, and the recent changes broke the demo.
> > > I now have to fork off the branch before this refactor was done, which
> > > sucks because we can't get any new people who want to contribute
> > > on-boarded easily.
> > >
> > > I really don't want to revert everything, because that would suck, but
> > > being patchbombed sucks as well, and doesn't help build consensus with
> > > other people on the project.  Also, I'm not sure we can revert this
> > > git repo back, because Apache git is weird and doesn't allow force.  I
> > > know that availability is limited, but a heads up would be good, since
> > > I have no idea what is going on with a lot of these commits, since
> > > some are the opposite of what we agreed to earlier.
> > >
> > > Interested in hearing thoughts about the changes, and how we can avoid
> > > this in the future.
> > >
> > > Joe
> > >
>

--089e0149495cd030e004fdc86a85--