cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <>
Subject Re: [Android] API changes
Date Wed, 09 Jul 2014 17:21:58 GMT
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. 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. 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? - 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 like
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
- 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
- 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
- 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
- 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 <> 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:
> 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 <> 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

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