cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <>
Subject Re: [Android] Refactoring for different engines
Date Fri, 07 Mar 2014 23:21:48 GMT

I just committed some code based on their WebView modifications that
allows you to choose your renderer in the config file with this:

    <preference name="webView"
value="org.apache.cordova.engine.crosswalk.XWalkCordovaWebView" />

You currently have to copy over the *.pak file and the jsapi from a
Crosswalk Example project to get this to work.  The next thing that
I'm going to do is figure out how to write this as a plugin and have
it install on a default project.  Also, right now the bridge doesn't
seem to work, and I don't know why exactly.  That being said, the fact
that I can choose which version of Chrome/Chromium I'm running with a
single XML preference is HUGE.

There's definitely a lot more work that needs to be done, but as long
as we have something that we can fit into the interface, we should be
able to put in things like GeckoView or other third party renderers.
The nightmare of being stuck with bullshit WebView bugs may soon be

On Wed, Mar 5, 2014 at 8:59 PM, Michal Mocny <> wrote:
> First patch they landed, which claims to have min viable xwalk webview:
> On Wed, Mar 5, 2014 at 11:37 PM, Michal Mocny <> wrote:
>> I haven't looked yet, but did you see:
>> ?
>> On Wed, Mar 5, 2014 at 10:20 PM, Andrew Grieve <>wrote:
>>> First - very excited that you're working on this!
>>> Had a quick look. Not sure there's much to be gleaned yet. Once you start
>>> in on hooking up x-walk's webview I think it will become more obvious what
>>> the interface should look like. E.g., does x-walk even have the concept of
>>> ChromeClient vs WebViewClient vs WebView? Also unsure whether the class
>>> should extend android.View as well as implement our interface. E.g.
>>> alternative is to have a "getView()" method on the interface. Might help
>>> to
>>> cut down on file sizes, and API surface, but again, I'm not too sure.
>>> I've been pretty hesitant to touch existing exposed members (e.g. the
>>> public fields you were referring to) since touching anything public could
>>> break plugins. That said, maybe now is a good time to @deprecate a bunch
>>> of
>>> them and either replace them with getters, or just declare them to be not
>>> exposed to plugins.
>>> On Wed, Mar 5, 2014 at 6:57 PM, Joe Bowser <> wrote:
>>> > So, after looking at the Crosswalk code again, I've decided to take a
>>> > quick stab at making things pluggable.  I don't have a lot to show for
>>> > it, but with the help of Eclipse (which is why the generated
>>> > interfaces look so screwed up), I managed to create some interfaces so
>>> > we can start shoehorning in other browser renderers.
>>> >
>>> >
>>> >
>>> > I'm going to probably start with Crosswalk, because it's probably the
>>> > most mature primary candidate in the Android Third-Party WebView
>>> > thing, and I'm pretty sure the GeckoView will be happening shortly
>>> > after.
>>> >
>>> > I don't know how this would work w.r.t. the CLI or our workflow at
>>> > all, but at the moment, I really just want to at least start to have
>>> > some headway towards 4.x and PhoneGap day.
>>> >
>>> > What do people think of this so far? I'm going to try to clean things
>>> > up a bit, since we've definitely done a lot of things that would make
>>> > first year CS profs freak the hell out (i.e. public members in public
>>> > objects w.r.t. PluginManager).
>>> >
>>> > Thoughts?
>>> >
>>> > Joe
>>> >

View raw message