I completely disagree, and think we should go the inheritance pattern. The reason for that is that we have to provide backwards compatibility for some views where the implementation is a view, and there's no dual inheritance in Java, which is the only way that I can see us accommodating both types of implementations. If we didn't already have users embedding CordovaWebView (and seriously guys, if you're reading this, please don't keep leaving me hanging here, I want you to step up into this conversation). Also, other views, such as the prototype MozillaView that I worked on, are implemented so that they inherit from a view.
Just because it may offer some us some flexibility doesn't mean that it's worth taking away an entire feature from other users. My most popular repository after Cordova itself is the example where I show how to embed a CordovaWebView, so people have been using this feature. On Wed Jan 28 2015 at 6:49:18 AM Andrew Grieve <agri...@chromium.org> wrote: > I'd prefer to go the other way, and change AndroidWebView to composition. > It's more flexible and does a better job of splitting up groups of APIs. > > On Wed, Jan 28, 2015 at 12:49 AM, Hu, Ningxin <ningxin...@intel.com> > wrote: > > > Hi Joe, > > > > > > The tests don't work with Crosswalk because Crosswalk's main class > > doesn't > > > inherit from a view. This is why we had to change the CordovaWebView > > > from being a class to being an Interface in the first place. I don't > > think there is > > > a way for these tests to work with Crosswalk because of this > > incompatibility. > > > I don't think there is a way to re-use these tests because of this > > fundamental > > > change. > > > > Crosswalk main class (XWalkView) actually inherits from a view (via > > FrameLayout). See > > https://crosswalk-project.org/apis/embeddingapidocs_v3/index.html > > > > I inspected the commit that changed the XWalkCordovaWebView from > > inheritance to composition ( > > https://github.com/MobileChromeApps/cordova-crosswalk-engine/commit/ > 26029ce8ae6d651a44a90222514cc6902ef8bb4a). > > The reason was some APIs of CordovaWebView interface (e.g. CanGoBack) > > conflict with XWalkView internal implementation at that time. And I > > remembered Ian and me thought CordovaWebView as an interface and > > compositing of webview probably was a good decouple solution. > > > > However, this changed in Crosswalk embedding API 3 (current version) that > > we separated the public interface and implementation. I briefly checked > > that the inheritance approach works with Crosswalk webview now. > > > > Folks, do you think we need to align all webview engines to inheritance > > pattern? > > > > Thanks, > > -ningxin > > > > > On Tue Jan 20 2015 at 5:11:54 AM Fu, Junwei <junwei...@intel.com> > wrote: > > > > > > > Hi, > > > > > > > > I pulled cordova-android 4.0 branch, and running JUnit test in /test > > > > directory, but there are compiled error as below, and I want reuse > the > > > > JUnit tests to test Crosswalk pluggable webView, so I request a PR > > > > https://github.com/apache/cordova-android/pull/140, could someone > > > help > > > > me to review and merge it. > > > > > > > > /test/menus.java:37: error: method registerForContextMenu in class > > > > Activity cannot be applied to given types; > > > > [javac] super.registerForContextMenu(super.appView); > > > > reason: actual argument CordovaWebView cannot be converted to View > > > by > > > > method invocation conversion > > > > > > > > test/splashscreen.java:33: error: method loadUrl in class > > > > CordovaActivity cannot be applied to given types; > > > > [javac] > > > super.loadUrl("file:///android_asset/www/splashscreen/index.html", > > > > 2000); > > > > reason: actual and formal argument lists differ in length > > > > > > > > Thanks, > > > > Junwei. > > > > > > > > ------------------------------------------------------------ > --------- > > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > >
