cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: MozillaView update, bridge questions
Date Wed, 29 Oct 2014 18:42:27 GMT
On Wed Oct 29 2014 at 11:19:02 AM Andrew Grieve <agrieve@chromium.org>
wrote:

> PROMPT isn't the default bridge, addJavaScriptInterface is. We fall back to
> PROMPT on Androids where AJI exposes security concerns. For Native->JS, we
> still use ONLINE events, which is actually crazy.
>
>
OK, so it's not the default, it's just on for 46.8% of all Android Devices.
(https://developer.android.com/about/dashboards/index.html)

It probably makes sense for Crosswalk to NOT use prompt because it
shouldn't have the same security problems that ICS has, right?

Reason for non-JSON is two-fold:
> 1. JSON doesn't support binary (e.g. ArrayBuffer)
> 2. JSON doesn't compose super easily (e.g. if you want to bundle two
> PluginResults together, with JSON you need to decode them both before being
> able to use the first one.
>
>
How often do we bundle PluginResults? I'm basically having to start from
scratch for the bridge for MozilalView, so this would be good to know.

 Also, would the unbundling of PluginResults have unintended consequences?
For example, if we had a location sensor based on BLE would it actually
have the most recent position first, or would we have to sort through the
PluginResults in JS using something like a timestamp?

Is any of this documented anywhere other than the Cordova Mailing List? I'm
noticing a lack of comments on the NativeToJsMessageQueue object I was
hoping to re-use for MozillaView so I wouldn't have to create another
feature branch with more API changes.


> On Wed, Oct 29, 2014 at 1:56 PM, Michal Mocny <mmocny@chromium.org> wrote:
>
> > On Wed, Oct 29, 2014 at 1:45 PM, Joe Bowser <bowserj@gmail.com> wrote:
> >
> > > Hey
> > >
> > > Unfortunately, I don't have anything working yet for the new
> MozillaView,
> > > but because MozillaView is so radically different than any other view,
> > I've
> > > been forced to re-think some things with our current exec script in
> > > cordova.js, namely why we're still using a prompt-based solution for
> > > NativeToJS API in 2014.
> > >
> > > I know that the reason we currently do this is because Android 2.3
> sucks
> > > and addJavascriptInterface doesn't work in the Emulator, and since
> people
> > > only seem to test Android 2.3 in the emulator, we have to support this
> > for
> > > some reason.
> > >
> > > I'm thinking that since the performance, as well as rendering on
> Android
> > > 2.3.x is so sub-par, maybe we want to strongly recommend that people
> use
> > > MozillaView on 4.x and switch our bridge to do something else like poll
> > >
> >
> > Do you mean MozillaView on 2.3?  My concern here is that those devices
> may
> > only be on 512Mb ram and its hard to imagine an alternative webview
> running
> > well on that (since it loses opportunity to share system resources, it
> has
> > larger overheads than system webview).  That said, if FF browser app is
> > having success on 2.3 devices, perhaps this is no different.  Perhaps
> > mozilla folk have insights into FF browser app stats on 2.3 devices?
> >
> >
> > > addJavascriptInterface and have the messages be sent back that way
> > > instead.  I don't know if there's additional drawbacks to this
> approach,
> > > which is why I'm asking here.
> > >
> > > Also, maybe it's time to re-think the encoding of the messages?  If we
> > can
> > > support moving JSON over the bridge we should do so instead of
> depending
> > on
> > > string encodings.  It's what's being done with Mozilla and I'm going to
> > > have to write the MozillaView as almost a separate platform and I'll
> have
> > > to override exec with it's stuff, since it's not a WebKit/Blink
> WebView,
> > > and instead has a sane way to pass stuff across. :P
> > >
> >
> > Last time I took a look at the bridge I asked the same question.
> Currently
> > encoding looks crazy at first glance.  Upon further inspection, it may be
> > difficult to compete on throughput with a more cleanly implementation,
> and
> > thats the reason for the ugly.  I'm all for an investigation into
> > improvements here, but we should start with benchmarks and an
> understanding
> > of what would be an acceptable regression (if any).
> >
> >
> > >
> > > Thoughts?
> > >
> > > Joe
> > >
> >
>

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