cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: MozillaView update, bridge questions
Date Wed, 29 Oct 2014 23:52:19 GMT
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.


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