incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Becky Gibson <gibson.be...@gmail.com>
Subject Re: Changes to iOS PluginResult sending
Date Fri, 05 Oct 2012 18:06:15 GMT
I am seeing instances where a JavaScript alert within a function callback
will hang the app.  We have seen this issue before and the solution is to
wrap the alert in a setTimeout,  for example,  setTimeout(function() {
alert('error with ' + error.code); });

This problem now seems much more prevalent, especially with an iOS 5.1
device.   Could this be related to the exec  speed improvements? If so we
need to make sure to document the use of setTimeout() or folks are going to
be unhappy when they go to run their apps.

-becky

On Fri, Oct 5, 2012 at 10:49 AM, Michal Mocny <mmocny@chromium.org> wrote:

> For those who didn't click the bug link to read the full benchmarks, I'll
> summarize:
>
> If exec() is called from the context of a plugin result callback: perf
> improved *3x* [IFRAME_NAV] *6x* [XHR_NO_PAYLOAD]
> If exec() is called not from the context of a plugin result callback: perf
> improved *66%* [IFRAME_NAV] *33%* [XHR_NO_PAYLOAD]
>
> Excellent work Andrew!
>
>
>
> On Thu, Oct 4, 2012 at 7:06 PM, Filip Maj <fil@adobe.com> wrote:
>
> > Sweet that sounds good
> >
> > On 10/4/12 2:20 PM, "Shazron" <shazron@gmail.com> wrote:
> >
> > >+1
> > >
> > >On Thu, Oct 4, 2012 at 2:18 PM, Brian LeRoux <b@brian.io> wrote:
> > >> nice! looks great andrew
> > >>
> > >> On Thu, Oct 4, 2012 at 10:48 PM, Andrew Grieve <agrieve@google.com>
> > >>wrote:
> > >>> TLDR: Added a new method for plugins to use to send plugin results
to
> > >>>JS.
> > >>>
> > >>> I've done some work to try and optimize the exec() bridge on iOS:
> > >>> https://issues.apache.org/jira/browse/CB-1579
> > >>>
> > >>> The main goal of the change: whenever
> > >>>stringByEvaluatingJavascriptString is
> > >>> used to call a JS callback, poll for exec() messages using the return
> > >>>value.
> > >>>
> > >>> The two ways plugins sent results in before my change:
> > >>>
> > >>> Before my change, plugins would send results using either:
> > >>>     [self success:pluginResult callbackId:callbackId]
> > >>> or (more commonly)
> > >>>     [self writeJavascript:[pluginResult
> toSuccessCallback:callbackId]]
> > >>>
> > >>>
> > >>> Both of these returned a string, which means I had to create a new
> > >>>method
> > >>> that could take advantage of the optimization.
> > >>>
> > >>> So, the new fancy:
> > >>> [self.commandDelegate sendPluginResult:pluginResult
> > >>>callbackId:callbackId];
> > >>>
> > >>> And for custom JS callbacks:
> > >>> [self.commandDelegate evalJs:js]; // has a void return value.
> > >>>
> > >>>
> > >>> sendPluginResult: and evalJs:js have the extra bonus that they are
> > >>> thread-safe and they work around cases where an alert() in the JS
> > >>>callback
> > >>> would result in dead-lock.
> > >>>
> > >>> I've left both of the old signatures so as to not break third-party
> > >>> plugins, but did go and update all of the core plugins. I'd like to
> > >>> deprecate them. I'll go ahead and do that tomorrow probably.
> > >>>
> > >>> I plan on updating the plugin guide to use this new method.
> >
> >
>

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