Figuring this out is a good idea, otherwise platform maintainers will go crazy
:) On 10/25/12 1:40 PM, "Bryce Curtis" <[email protected]> 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 <[email protected]> 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 <[email protected]> >>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 <[email protected]> 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" <[email protected]> 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 >>>><[email protected]> >>>> >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 >>>> >>>>
