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 Wed, 10 Oct 2012 18:24:29 GMT
I was able to reproduce this on my simulator every time. For some reason,
switching from using blocks+dispatch_async to performSelectorOnMainThread
fixes it. I've checked in this change, but we should definitely keep an eye
out for any other cases of this.



On Sat, Oct 6, 2012 at 3:43 PM, Becky Gibson <gibson.becky@gmail.com> wrote:

> It may not have been this explicit change - perhaps others that affect the
> exec mechanism.  Two places in the manual mobile-spec show the issue.   In
> contacts an alert is displayed with the success or failure of saving a
> contact.   In the Notifications if you test the Cordova Confirm, after you
> dismiss it an alert is displayed to indicate which confirm button was
> selected.  I have other examples in my own manual tests to it isn't
> mobile-spec related.
>
> -becky
>
> On Fri, Oct 5, 2012 at 2:28 PM, Andrew Grieve <agrieve@chromium.org>
> wrote:
>
> > 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