cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <>
Subject Re: MozillaView update, bridge questions
Date Wed, 29 Oct 2014 17:56:35 GMT
On Wed, Oct 29, 2014 at 1:45 PM, Joe Bowser <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message