cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryce Curtis <>
Subject Re: Recent Change to CordovaWebView and DroidGap
Date Thu, 25 Oct 2012 20:40:12 GMT
There really isn't any docs for DroidGap, other than in the source
code - maybe we need to do this - and doc the API & parameters that
are listed at the top of the file.  DroidGap is a unique class since
it is extended by others when writing an app.  We do this and rely
upon several of the public methods within DroidGap to be there.
Sounds like we need to review which methods are public and identify
supported API - and deprecate the rest.

I think it could make sense to identify public APIs for some other
classes, but they need to be reviewed before committing to support.
Many public methods are used internally from other classes in Cordova
- maybe we need to revisit and make protected if possible.

On Thu, Oct 25, 2012 at 2:33 PM, Joe Bowser <> wrote:
> If we do go down this route, does that mean that we have the
> opportunity to make certain methods package-private? I honestly think
> that we expose way too many things right now, and when we set these
> methods public, it wasn't so that they would be set in stone.  I feel
> that we've totally overextended ourselves by not thinking about this,
> and now we're stuck with this very poorly designed Java API that we
> have to maintain.
> Also, if we're serious about making a public API, we have to get our
> test suite working better.  We have the JUnit Tests that cover some of
> the Java use cases, but right now there's parts that just aren't
> working.  I don't know if it's the Android tools that are breaking it
> or what, but right now certain tests are failing for no good reason.
> On Thu, Oct 25, 2012 at 1:23 PM, Andrew Grieve <> wrote:
>> Java has really good visibility semantics. I think any symbol that is
>> public should be a public API, and any symbol we want to be able to change
>> we should make package-private or private. We're clearly not there atm, but
>> I think it's quite reasonable to do.
>> On Thu, Oct 25, 2012 at 4:18 PM, Filip Maj <> wrote:
>>> We should clarify what parts of the native code we can modify at will and
>>> what would be considered "public APIs"
>>> We don't document DroidGap to any (significant) extent, but we do (now) do
>>> that for the plugin APIs, and obviously the JS.
>>> On 10/25/12 1:13 PM, "Joe Bowser" <> wrote:
>>> >Hey
>>> >
>>> >Can you file a bug in JIRA against this commit so we can track it?  I
>>> >didn't realize that this would break anything significant.  I've
>>> >already modified it so that it should be fixed.  The problem that I
>>> >have with this is that now that we have two places to check for the
>>> >proper WebViewClient instead of one.  The bug that this is fixing is
>>> >the issue with our WebHistory.  CB-1568.
>>> >
>>> >Joe
>>> >
>>> >On Thu, Oct 25, 2012 at 1:01 PM, Bryce Curtis <>
>>> >wrote:
>>> >> Joe,
>>> >>
>>> >> The commit
>>> >>
>>> >>
>>> >>
>>> >>=commitdiff;h=6aafd6dc3aec1ed1fe1d7a3e08d73deedddbc3a3
>>> >>
>>> >> changes the signature of a public method
>>> >>
>>> >> -    public void init(CordovaWebView webView, CordovaWebViewClient
>>> >> webViewClient, CordovaChromeClient webChromeClient) {
>>> >> +    public void init(CordovaWebView webView, CordovaChromeClient
>>> >> webChromeClient) {
>>> >>
>>> >> which breaks any app that extends DroidGap & calls init with their
>>> >> view and chrome clients.
>>> >>
>>> >> We really need this support, so could you please revert.
>>> >>
>>> >> What is the bug that this was addressing - and maybe there's another
>>> >> way to solve it?  Let me know if Simon or I can help.
>>> >>
>>> >> Thanks,
>>> >> Bryce

View raw message