You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Andrew Grieve <ag...@google.com> on 2012/10/04 22:48:24 UTC
Changes to iOS PluginResult sending
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.
Re: Changes to iOS PluginResult sending
Posted by Andrew Grieve <ag...@chromium.org>.
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 <gi...@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 <ag...@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 <gi...@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 <mm...@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 <fi...@adobe.com> wrote:
> > > >
> > > > > Sweet that sounds good
> > > > >
> > > > > On 10/4/12 2:20 PM, "Shazron" <sh...@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.
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Changes to iOS PluginResult sending
Posted by Becky Gibson <gi...@gmail.com>.
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 <ag...@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 <gi...@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 <mm...@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 <fi...@adobe.com> wrote:
> > >
> > > > Sweet that sounds good
> > > >
> > > > On 10/4/12 2:20 PM, "Shazron" <sh...@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.
> > > >
> > > >
> > >
> >
>
Re: Changes to iOS PluginResult sending
Posted by Andrew Grieve <ag...@chromium.org>.
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 <gi...@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 <mm...@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 <fi...@adobe.com> wrote:
> >
> > > Sweet that sounds good
> > >
> > > On 10/4/12 2:20 PM, "Shazron" <sh...@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 <ag...@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.
> > >
> > >
> >
>
Re: Changes to iOS PluginResult sending
Posted by Becky Gibson <gi...@gmail.com>.
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 <mm...@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 <fi...@adobe.com> wrote:
>
> > Sweet that sounds good
> >
> > On 10/4/12 2:20 PM, "Shazron" <sh...@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 <ag...@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.
> >
> >
>
Re: Changes to iOS PluginResult sending
Posted by Michal Mocny <mm...@chromium.org>.
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 <fi...@adobe.com> wrote:
> Sweet that sounds good
>
> On 10/4/12 2:20 PM, "Shazron" <sh...@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 <ag...@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.
>
>
Re: Changes to iOS PluginResult sending
Posted by Filip Maj <fi...@adobe.com>.
Sweet that sounds good
On 10/4/12 2:20 PM, "Shazron" <sh...@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 <ag...@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.
Re: Changes to iOS PluginResult sending
Posted by Shazron <sh...@gmail.com>.
+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 <ag...@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.
Re: Changes to iOS PluginResult sending
Posted by Brian LeRoux <b...@brian.io>.
nice! looks great andrew
On Thu, Oct 4, 2012 at 10:48 PM, Andrew Grieve <ag...@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.