cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: Recent Change to CordovaWebView and DroidGap
Date Thu, 25 Oct 2012 20:33:44 GMT
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