On Wed, Oct 29, 2014 at 7:52 PM, Andrew Grieve <agri...@chromium.org> wrote:
> On Wed, Oct 29, 2014 at 2:46 PM, Michal Mocny <mmo...@chromium.org> wrote: > > > On Wed, Oct 29, 2014 at 2:18 PM, Andrew Grieve <agri...@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 <mmo...@chromium.org> > > wrote: > > > > > > > On Wed, Oct 29, 2014 at 1:45 PM, Joe Bowser <bows...@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 > > > > > > > > > > > > > > >
