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:55:38 GMT
On Wed, Oct 29, 2014 at 2:42 PM, Joe Bowser <bowserj@gmail.com> wrote:

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

Ah, I misunderstood I think.
I think the specifics of the bridge should be unique per webview
implementation. So long as they call speak in terms of PluginResults, I
think we're good.


>
> 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.
>
Depends what you're doing. On the native side, PluginResults queue up, and
a notification is sent to the webview to ask for them. The more busy the
webview, or the more rapid results come in, the more get bundled.


>
>  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?
>
No, they are guaranteed to go in order (they use a queue and a processed
synchronously)


>
> 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.
>
NativeToJsMessageQueue and CordovaBridge is the source of truth. There's
also a bridge benchmark test in mobilespec that I find useful when making
changes to the bridge.


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