cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject Re: [Android] API changes
Date Wed, 09 Jul 2014 18:05:28 GMT
On Wed, Jul 9, 2014 at 1:21 PM, Andrew Grieve <agrieve@chromium.org> wrote:

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

The only plugin changes that have been required so far have been due to the
member->method change of WebView.pluginManager. This has only affected
plugins which need to coordinate with other plugins in Java.

With that in mind, I've wanted this for 4.0.0:
 - 100% backwards compatibility for plugins, except for the case of
inter-plugin communication
 - Provide a stable API for native-side inter-plugin communication so that
we don't have to break this *again*.


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

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