cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: MozillaView update, bridge questions
Date Thu, 30 Oct 2014 03:50:03 GMT
On Wed, Oct 29, 2014 at 7:52 PM, Andrew Grieve <agrieve@chromium.org> wrote:

> On Wed, Oct 29, 2014 at 2:46 PM, Michal Mocny <mmocny@chromium.org> wrote:
>
> > On Wed, Oct 29, 2014 at 2:18 PM, 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.
> > >
> > > Reason for non-JSON is two-fold:
> > > 1. JSON doesn't support binary (e.g. ArrayBuffer)
> > >
> > Could use BSON or something similar?
> >
> Android webview has no binary bridge, so I think this would just make it
> slower.
>

BSON can have a string encoding as I understand, and supports additional
types like Binary and Javascript.  So, I was just bringing up an option to
use a library to encode/decode our payloads as an alternative to our custom
encodings.

That said, I don't think our encoding is actually all that confusing, and
its highly unlikely any library will outperform our encoding scheme.  Its
the bridge transport thats the confusing part.


>
>
> >
> >
> > > 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.
> > >
> > Could use a nested encoding for composing plugin results:
> > LENGTH:Payload:LENGTH:Payload or something?
> >
> That is what we do :)
>
> >
> >
> > >
> > > 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