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 <bows...@gmail.com> 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. > > https://github.com/infil00p/cordova-android/tree/pluggable_webview > > 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 >
