incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: [Android] CordovaWebView: Moving the CallbackServer and PluginManager out of DroidGap
Date Thu, 29 Mar 2012 18:53:15 GMT
On Wed, Mar 28, 2012 at 9:09 PM, Bryce Curtis <curtis.bryce@gmail.com>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 <fil@adobe.com> 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" <bowserj@gmail.com> wrote:
> >
> > >BUMP! Are we all on board with doing this?
> > >
> > >Joe
> > >
> > >On Tue, Mar 27, 2012 at 1:15 PM, Joe Bowser <bowserj@gmail.com> 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
> > >>
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message