Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of agrieve@google.com designates
 209.85.216.180 as permitted sender)
MIME-Version: 1.0
Sender: agrieve@google.com
In-Reply-To: 
 <CAOBL_k6vW1qZafTksAODdJA4Xd0FW-BoA_i5c-O_Lx-wFZs2hA@mail.gmail.com>
References: 
 <BDD863A8AA703D4D8A2639FB639A44825716FD@shsmsx102.ccr.corp.intel.com>
 <CAOBL_k5ekUb0vhfTZ56u8+-Ztv1KWtxZZxVbJAa3U50ug1ghEw@mail.gmail.com>
 <1298B14A1D0704468AE73FC92557A162257EFC7D@SHSMSX104.ccr.corp.intel.com>
 <CABiQX1WgB6BmXQPZPCFF+w7uJuqjYtpX6_2kc0g5-EgRhEi_xg@mail.gmail.com>
 <CAOBL_k6vW1qZafTksAODdJA4Xd0FW-BoA_i5c-O_Lx-wFZs2hA@mail.gmail.com>
From: Andrew Grieve <agrieve@chromium.org>
Date: Wed, 28 Jan 2015 13:06:30 -0500
Message-ID: 
 <CABiQX1WR2NfoCa-YpMgJs14gFS7A9LFmjk=tJH1tjVVMym_hwQ@mail.gmail.com>
Subject: Re: cordova-android 4.0 JUnit tests
To: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=001a113a65164fb341050dba3c0c

--001a113a65164fb341050dba3c0c
Content-Type: text/plain; charset=UTF-8

You can still embed a view using composition. We are not providing any
backwards compatibility right now, even with inheritance, because
CordovaWebView is no longer a View (it's an interface, which requires an
explicit cast to (View), or a call to .getView() to be considered as a View)

On Wed, Jan 28, 2015 at 11:26 AM, Joe Bowser <bowserj@gmail.com> wrote:

> 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 <agrieve@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.hu@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.fu@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-unsubscribe@cordova.apache.org
> > > > > For additional commands, e-mail: dev-help@cordova.apache.org
> > > > >
> > >
> >
>

--001a113a65164fb341050dba3c0c--