[Android] CordovaBridge: Public or Private API

[Joe Bowser <bo...@gmail.com>]

Hey

I'm still working on the Mozilla Bridge and I'm running into problems with
how non-modular the current bridge is and how it was abstracted.  When we
created the ExposedJsApi class and added it to the API, we did so because
we may need to abstract the whole bridge later.  However, right now both
Crosswalk and Android WebView share the CordovaBridge, including its
encoding.  Since GeckoView now has its own bridge (which includes some JS
code that needs to override the Android defaults), I'm wondering whether we
should expose the CordovaBridge and allow it to be implemented or not.
There is a lot of shared code, but at the same time I don't know how much
code will be shared between the MozillaView and the default.

Either way, I'm getting pretty close to a workable prototype soon and then
we can start work on getting the MobileSpec tests passing.  Once the plugin
is broken out so that it can be installed using plugman or the CLI, we can
get more people looking at it.

But yeah, any thoughts on this would be great.

Joe

Re: [Android] CordovaBridge: Public or Private API

[Jesse <pu...@gmail.com>]

What if each webview implementation injected it's own exec function?
This would/could apply also to platform's webviews.  The cordova-js version
of exec, could simply queue exec calls if they happened pre-deviceready.

I have experimented with this in the past, and verified that Windows, WP8,
and iOS could easily support it.

@purplecabbage
risingj.com

On Mon, Nov 3, 2014 at 7:52 PM, Andrew Grieve <ag...@chromium.org> wrote:

> Hmm, yeah, CordovaBridge is very much tied to the idea that a bridge has
> prompt mode, which tells the origin, and a js mode which uses a token to
> verify it's trusted. Both of these concepts are fairly
> webview-implementation specific.
>
> The only thing in there that seems webview-agnostic is the reset()
> function. So, maybe create a CordovaBridge abstract base class that just
> has reset() and make that what the webview impl uses as its type?
>
> Not sure if that's along the lines of what you're thinking...
>
> On Mon, Nov 3, 2014 at 2:24 PM, Joe Bowser <bo...@gmail.com> wrote:
>
> > Hey
> >
> > I'm still working on the Mozilla Bridge and I'm running into problems
> with
> > how non-modular the current bridge is and how it was abstracted.  When we
> > created the ExposedJsApi class and added it to the API, we did so because
> > we may need to abstract the whole bridge later.  However, right now both
> > Crosswalk and Android WebView share the CordovaBridge, including its
> > encoding.  Since GeckoView now has its own bridge (which includes some JS
> > code that needs to override the Android defaults), I'm wondering whether
> we
> > should expose the CordovaBridge and allow it to be implemented or not.
> > There is a lot of shared code, but at the same time I don't know how much
> > code will be shared between the MozillaView and the default.
> >
> > Either way, I'm getting pretty close to a workable prototype soon and
> then
> > we can start work on getting the MobileSpec tests passing.  Once the
> plugin
> > is broken out so that it can be installed using plugman or the CLI, we
> can
> > get more people looking at it.
> >
> > But yeah, any thoughts on this would be great.
> >
> > Joe
> >
>

Re: [Android] CordovaBridge: Public or Private API

[Andrew Grieve <ag...@chromium.org>]

Hmm, yeah, CordovaBridge is very much tied to the idea that a bridge has
prompt mode, which tells the origin, and a js mode which uses a token to
verify it's trusted. Both of these concepts are fairly
webview-implementation specific.

The only thing in there that seems webview-agnostic is the reset()
function. So, maybe create a CordovaBridge abstract base class that just
has reset() and make that what the webview impl uses as its type?

Not sure if that's along the lines of what you're thinking...

On Mon, Nov 3, 2014 at 2:24 PM, Joe Bowser <bo...@gmail.com> wrote:

> Hey
>
> I'm still working on the Mozilla Bridge and I'm running into problems with
> how non-modular the current bridge is and how it was abstracted.  When we
> created the ExposedJsApi class and added it to the API, we did so because
> we may need to abstract the whole bridge later.  However, right now both
> Crosswalk and Android WebView share the CordovaBridge, including its
> encoding.  Since GeckoView now has its own bridge (which includes some JS
> code that needs to override the Android defaults), I'm wondering whether we
> should expose the CordovaBridge and allow it to be implemented or not.
> There is a lot of shared code, but at the same time I don't know how much
> code will be shared between the MozillaView and the default.
>
> Either way, I'm getting pretty close to a workable prototype soon and then
> we can start work on getting the MobileSpec tests passing.  Once the plugin
> is broken out so that it can be installed using plugman or the CLI, we can
> get more people looking at it.
>
> But yeah, any thoughts on this would be great.
>
> Joe
>