cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Supporting multiple plugin return values
Date Wed, 13 Feb 2013 20:24:40 GMT
ping.  Shaz?


On Tue, Feb 12, 2013 at 11:28 AM, Michal Mocny <mmocny@chromium.org> wrote:

> I've pushed this to a remote branch: multipart_plugin_result for both ios
> and js repo's:
>
> ios:
> https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=shortlog;h=refs/heads/multipart_plugin_result
> js:
> https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/heads/multipart_plugin_result
>
> mobile-spec-tests run fine and there should be no difference to any
> existing plugins.  Instead of adding anything complicated to support
> multiple arguments, I just added a new CDVType: MultiPart much in the same
> fashion as ArrayBuffers (we can implement a more efficient way to encode
> type information at some point, but its not really a problem right now).
>
> The resulting arguments are unfortunately delivered to plugin callback as
> a single array argument instead of as separate arguments (ie function
> win(args) { var arg1 = args[0] ...} instead of function win(arg1, arg2,
> arg3) {...}) due to the way cordova.callbackFromNative helper is
> implemented.  This can be improved later if we would like.
>
> Please take a look!
>
> -Michal
>
>
> On Sat, Jan 19, 2013 at 11:45 AM, Shazron <shazron@gmail.com> wrote:
>
>> I don't see any problem with it as long as existing plugins (core and
>> third-party) don't break (unless we need to deprecate anything of course)
>>
>>
>> On Fri, Jan 18, 2013 at 11:55 AM, Michal Mocny <mmocny@google.com> wrote:
>>
>> > I've filed https://issues.apache.org/jira/browse/CB-2239 but wanted to
>> get
>> > feedback here in case there a simpler solution to this problem.
>> >
>> > Basically: I've recently added support for ArrayBuffer argument type
>> across
>> > iOS exec bridge and Braden added the same to Android.
>> >
>> > However, while working on a plugin to make use of this feature
>> (socket), we
>> > found that sound plugin calls expect to send an ArrayBuffer back along
>> with
>> > over values.
>> >
>> > We considered adding a special bucket for ArrayBuffer return values to
>> the
>> > bridge, so that you can send a normal result + ArrayBuffer, but decided
>> > that wasn't scalable since we may want more custom non-json serializable
>> > types in the future.
>> >
>> > We decided the best option was to allow returning a list of "cordova
>> bridge
>> > supported types", which includes everything we have had until now +
>> > ArrayBuffer + whatever we add in the future.
>> >
>> > This shouldn't be a big change, existing plugins need not change at all,
>> > and it also opens up the possibility to do some interesting encodings
>> for
>> > return values whenever JSON isn't the most efficient (we do some of
>> this on
>> > android already).
>> >
>> > -Michal
>> >
>>
>
>

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