incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Changes to iOS PluginResult sending
Date Thu, 04 Oct 2012 23:06:36 GMT
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
View raw message