cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Recent Change to CordovaWebView and DroidGap
Date Thu, 25 Oct 2012 20:48:41 GMT
Figuring this out is a good idea, otherwise platform maintainers will go
crazy

:)

On 10/25/12 1:40 PM, "Bryce Curtis" <curtis.bryce@gmail.com> wrote:

>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 <bowserj@gmail.com> 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 <agrieve@chromium.org>
>>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 <fil@adobe.com> 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" <bowserj@gmail.com> 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
>>>><curtis.bryce@gmail.com>
>>>> >wrote:
>>>> >> Joe,
>>>> >>
>>>> >> The commit
>>>> >>
>>>> >>
>>>> >>
>>>> 
>>>>https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-android.git
>>>>;a
>>>> >>=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
>>>>own
>>>> >> 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
>>>>
>>>>


Mime
View raw message