You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Joe Bowser <bo...@gmail.com> on 2014/10/29 18:45:40 UTC
MozillaView update, bridge questions
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
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
Thoughts?
Joe
Re: MozillaView update, bridge questions
Posted by Joe Bowser <bo...@gmail.com>.
On Wed Oct 29 2014 at 11:46:43 AM Michal Mocny <mm...@chromium.org> wrote:
> On Wed, Oct 29, 2014 at 2:18 PM, Joe Bowser <bo...@gmail.com> wrote:
>
> Not sure KK and L will kill 2.3, but perhaps Android One etc will (cheap
> devices and 512 ram was previous motivation to continue shipping these old
> versions).
>
>
I thought the KK/L design goal was to facilitate Android One. I'm more
excited/worried about Project Volta and how that'll affect things like
Chromium and Gecko. Of course, this is just speculation from the sidelines
over here.
Re: MozillaView update, bridge questions
Posted by Michal Mocny <mm...@chromium.org>.
On Wed, Oct 29, 2014 at 2:18 PM, Joe Bowser <bo...@gmail.com> wrote:
> On Wed Oct 29 2014 at 10:58:08 AM Michal Mocny <mm...@chromium.org>
> wrote:
>
> > On Wed, Oct 29, 2014 at 1:45 PM, Joe Bowser <bo...@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?
> >
> > Yeah, I meant 2.3. Is that what's keeping Chromium-based WebViews off
> 2.3? I was hoping that KitKat and Lolipop would be killing off
> Gingerbread, since we're not talking about 11% of all users instead of 25%.
>
Not sure KK and L will kill 2.3, but perhaps Android One etc will (cheap
devices and 512 ram was previous motivation to continue shipping these old
versions).
>
>
>
> > > 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
> > >
> >
>
Re: MozillaView update, bridge questions
Posted by Joe Bowser <bo...@gmail.com>.
On Wed Oct 29 2014 at 10:58:08 AM Michal Mocny <mm...@chromium.org> wrote:
> On Wed, Oct 29, 2014 at 1:45 PM, Joe Bowser <bo...@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?
>
> Yeah, I meant 2.3. Is that what's keeping Chromium-based WebViews off
2.3? I was hoping that KitKat and Lolipop would be killing off
Gingerbread, since we're not talking about 11% of all users instead of 25%.
> > 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
> >
>
Re: MozillaView update, bridge questions
Posted by Joe Bowser <bo...@gmail.com>.
On Wed Oct 29 2014 at 4:56:24 PM Andrew Grieve <ag...@chromium.org> wrote:
>
> >
> > 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.
>
>
That test works? Cool. Right now, the specifics of the bridge are
understood by one or two people on Android, and I believe they're slightly
different on each platform. It'd be good if this was documented so that if
we get hit by a bus at a PhoneGap Day or Cordova Meetup the project isn't
totally screwed.
>
> >
> >
> > > On Wed, Oct 29, 2014 at 1:56 PM, Michal Mocny <mm...@chromium.org>
> > wrote:
> > >
> > > > On Wed, Oct 29, 2014 at 1:45 PM, Joe Bowser <bo...@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
> > > > >
> > > >
> > >
> >
>
Re: MozillaView update, bridge questions
Posted by Andrew Grieve <ag...@chromium.org>.
On Wed, Oct 29, 2014 at 2:42 PM, Joe Bowser <bo...@gmail.com> wrote:
> On Wed Oct 29 2014 at 11:19:02 AM Andrew Grieve <ag...@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 <mm...@chromium.org>
> wrote:
> >
> > > On Wed, Oct 29, 2014 at 1:45 PM, Joe Bowser <bo...@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
> > > >
> > >
> >
>
Re: MozillaView update, bridge questions
Posted by Joe Bowser <bo...@gmail.com>.
On Wed Oct 29 2014 at 11:19:02 AM Andrew Grieve <ag...@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 <mm...@chromium.org> wrote:
>
> > On Wed, Oct 29, 2014 at 1:45 PM, Joe Bowser <bo...@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
> > >
> >
>
Re: MozillaView update, bridge questions
Posted by Michal Mocny <mm...@chromium.org>.
On Wed, Oct 29, 2014 at 7:52 PM, Andrew Grieve <ag...@chromium.org> wrote:
> On Wed, Oct 29, 2014 at 2:46 PM, Michal Mocny <mm...@chromium.org> wrote:
>
> > On Wed, Oct 29, 2014 at 2:18 PM, Andrew Grieve <ag...@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 <mm...@chromium.org>
> > wrote:
> > >
> > > > On Wed, Oct 29, 2014 at 1:45 PM, Joe Bowser <bo...@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
> > > > >
> > > >
> > >
> >
>
Re: MozillaView update, bridge questions
Posted by Andrew Grieve <ag...@chromium.org>.
On Wed, Oct 29, 2014 at 2:46 PM, Michal Mocny <mm...@chromium.org> wrote:
> On Wed, Oct 29, 2014 at 2:18 PM, Andrew Grieve <ag...@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 <mm...@chromium.org>
> wrote:
> >
> > > On Wed, Oct 29, 2014 at 1:45 PM, Joe Bowser <bo...@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
> > > >
> > >
> >
>
Re: MozillaView update, bridge questions
Posted by Michal Mocny <mm...@chromium.org>.
On Wed, Oct 29, 2014 at 2:18 PM, Andrew Grieve <ag...@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 <mm...@chromium.org> wrote:
>
> > On Wed, Oct 29, 2014 at 1:45 PM, Joe Bowser <bo...@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
> > >
> >
>
Re: MozillaView update, bridge questions
Posted by Andrew Grieve <ag...@chromium.org>.
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)
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.
On Wed, Oct 29, 2014 at 1:56 PM, Michal Mocny <mm...@chromium.org> wrote:
> On Wed, Oct 29, 2014 at 1:45 PM, Joe Bowser <bo...@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
> >
>
Re: MozillaView update, bridge questions
Posted by Michal Mocny <mm...@chromium.org>.
On Wed, Oct 29, 2014 at 1:45 PM, Joe Bowser <bo...@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
>