incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Changes to iOS PluginResult sending
Date Fri, 05 Oct 2012 18:28:38 GMT
I'm not sure why this would have changed. The PluginResult::success method
had a setTimeout in it, which I removed, but pretty much none of the core
plugins used that method anyways. They all used writeJavascript:callback,
which didn't use a setTimeout.

The one spot in the code where I did see a comment about alerts causing
deadlock worked around it dispatching using [self
performSelectonOnMainThread:@selector(writeJavascript:) afterDelay];

This is what I've used to in the "new path" so that all plugins use it to
avoid this case.

What are the specific cases you're seeing?



On Fri, Oct 5, 2012 at 2:06 PM, Becky Gibson <gibson.becky@gmail.com> wrote:

> 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