incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryce Curtis <curtis.br...@gmail.com>
Subject Re: [Android] CordovaWebView: Moving the CallbackServer and PluginManager out of DroidGap
Date Thu, 29 Mar 2012 21:01:00 GMT
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 <bowserj@gmail.com> wrote:

> 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