Yes, I meant providing your own classes that inherit from our CordovaChrome/WebView classes.
>From what I've observed recently, addJavascriptInterface is still broken in the emulator and on some (maybe small subset) of real phones. On Thu, Mar 29, 2012 at 1:53 PM, Joe Bowser <[email protected]> wrote: > On Wed, Mar 28, 2012 at 9:09 PM, Bryce Curtis <[email protected] > >wrote: > > > I really haven't had time to look at this in detail, but agree that > > anything related to the webview should be in CordovaWebView. As Fil > > mentioned, that includes the history, plugin manager, whitelisting, & > > authentication + callback server. > > > > I assume that overriding chrome/view clients so the user can specify > their > > own will still work. > > > > > What do you mean overriding Chrome/View clients? You can use your own > classes if they inherit from the CordovaChrome class or CordovaWebView > class, but if you just cram a vanilla WebViewClient or WebChromeClient, > Cordova won't work at all. This has nothing to do with CordovaWebView, but > instead is a consequence of the prompt hack that acts as our current > bridge. If we want to make it so that we're not dependent on the > ChromeClient, we should probably bring back addJavascriptInterface and put > it in the view itself. > > BTW: Does the emulator still break when we do this on Android 2.3? I think > I'll have to look into that. > > Joe > > > > On Wed, Mar 28, 2012 at 6:17 PM, Filip Maj <[email protected]> wrote: > > > > > Sorry for late reply Joe! > > > > > > Looks great! As for outstanding issues as per your wiki article [1], I > > > would say move everything WebView related, as well as Cordova-specific > > > such as the plugin manager, into CordovaWebView.java. My thinking here > is > > > that, none of scaffolding necessary to enable device APIs in the web > view > > > should be a burden on the user - the CordovaWebView class should handle > > > all of that. > > > > > > It separates the cordova-y bits as something the WEbView needs to > manage > > > on its own, as well, and cleans up the final Activity-extending class > to > > > be simpler. Our end users should not have to worry about that stuff, > nor > > > do they need to see it in their own activities, or the generated > > > activities the baseline tooling within cordova-android provides. > > > > > > IMO: history, plugin manager, whitelisting, authentication, should all > be > > > handled by CordovaWebView. > > > > > > [1] http://wiki.apache.org/cordova/CordovaWebView > > > > > > On 3/28/12 4:06 PM, "Joe Bowser" <[email protected]> wrote: > > > > > > >BUMP! Are we all on board with doing this? > > > > > > > >Joe > > > > > > > >On Tue, Mar 27, 2012 at 1:15 PM, Joe Bowser <[email protected]> > wrote: > > > > > > > >> Hey > > > >> > > > >> I've been working on the CordovaWebView branch, and I think we need > to > > > >> discuss where to put the CallbackServer and PluginManager in the new > > > >> implementation. I'm OK with it being in the view, but I did have it > > in > > > >>the > > > >> Client before, and I'm wondering what people's thoughts are on that. > > > >>Also, > > > >> since these are core pieces of Cordova on Android, this may break > the > > > >> branch, which is fine, but it'd be good if more people looked at > this > > > >> branch, and discussed how this should work. > > > >> > > > >> > > > >> > > > >> > > > > > > https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-android.git;a > > > >>=shortlog;h=refs/heads/CordovaWebView > > > >> > > > >> http://wiki.apache.org/cordova/CordovaWebView > > > >> > > > >> Joe > > > >> > > > > > > > > >
