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 Wed, 29 Oct 2014 18:46:26 GMT
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?


> 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?


>
> 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