You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Michal Mocny <mm...@chromium.org> on 2013/02/12 17:28:36 UTC
Re: Supporting multiple plugin return values
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 <sh...@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 <mm...@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
> >
>
Re: Supporting multiple plugin return values
Posted by Brian LeRoux <b...@brian.io>.
ya that looks great thanks mang
On Wed, Feb 27, 2013 at 1:12 PM, Filip Maj <fi...@adobe.com> wrote:
> Thanks Michal!
>
> On 2/27/13 6:59 AM, "Michal Mocny" <mm...@chromium.org> wrote:
>
>>All this work has landed and I've just updated the documentation. Since
>>there was no documentation at all for plugin return values, I added a
>>whole
>>section about it. If anyone wants to proof read, Commit:
>>http://git-wip-us.apache.org/repos/asf/cordova-docs/commit/9927fcdf
>>
>>Also, I've replaced the current mobile-spec bridge autotests from doing
>>bad
>>benchmarks that didn't work (and we now have benchmark tests anyway), with
>>a simple set of bridge smoke tests for echoing various message types.
>> Android seems to jave jake tests to smoke test the bridge, so maybe I
>>should move those there..
>>
>>-Michal
>>
>>
>>On Thu, Feb 14, 2013 at 9:42 AM, Max Woghiren <ma...@google.com> wrote:
>>
>>> I agree with Shaz‹in general we should start using this type of syntax
>>>for
>>> dictionaries:
>>>
>>> return @{@"CDVType": @"Multipart", @"messages": messages};
>>>
>>> I'd say messageAsMultipart: makes sense, in keeping with the pattern set
>>> by the other names.
>>>
>>>
>>> On Thu, Feb 14, 2013 at 9:24 AM, Michal Mocny <mm...@chromium.org>
>>>wrote:
>>>
>>>> And also: do we like the name "messageAsMultipart:" or should it just
>>>>be
>>>> "messageWithArguments:"?
>>>>
>>>>
>>>> On Thu, Feb 14, 2013 at 9:23 AM, Michal Mocny <mm...@chromium.org>
>>>> wrote:
>>>>
>>>> > Andrew,
>>>> >
>>>> > Yes I was definitely thinking the same thing, but wanted to do that
>>>> later.
>>>> > I'll make the change before documenting how multipart messages
>>>>work, as
>>>> > shaz suggested. Thanks for giving me a heads up about reference to
>>>>it
>>>> on
>>>> > android. Also: other platforms dont use it?
>>>> >
>>>> > -Michal
>>>> >
>>>> >
>>>> > On Wed, Feb 13, 2013 at 10:51 PM, Andrew Grieve <agrieve@chromium.org
>>>> >wrote:
>>>> >
>>>> >> My only comment is that I think it's worth refactoring
>>>> >> cordova.callbackFromNative so that it passes the multiple values to
>>>> >> callbacks as separate parameters. All references to it are in
>>>> cordova-js
>>>> >> plus one in Android's NativeToJsMessageQueue.java
>>>> >>
>>>> >>
>>>> >> On Wed, Feb 13, 2013 at 5:42 PM, Shazron <sh...@gmail.com> wrote:
>>>> >>
>>>> >>> Looks good to me.
>>>> >>> Although I have a bone to pick with dictionaryWithObjectsAndKeys
>>>> having
>>>> >>> objects first but that's not our problem ;) Good thing they support
>>>> >>> literal
>>>> >>> notation now...
>>>> >>>
>>>> >>>
>>>> >>> On Wed, Feb 13, 2013 at 12:24 PM, Michal Mocny
>>>><mm...@chromium.org>
>>>> >>> wrote:
>>>> >>>
>>>> >>> > 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=r
>>>>efs/heads/multipart_plugin_result
>>>> >>> > > js:
>>>> >>> > >
>>>> >>> >
>>>> >>>
>>>>
>>>>https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=re
>>>>fs/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 <sh...@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
>>>> >>> > >> >
>>>> >>> > >>
>>>> >>> > >
>>>> >>> > >
>>>> >>> >
>>>> >>>
>>>> >>
>>>> >>
>>>> >
>>>>
>>>
>>>
>
Re: Supporting multiple plugin return values
Posted by Filip Maj <fi...@adobe.com>.
Thanks Michal!
On 2/27/13 6:59 AM, "Michal Mocny" <mm...@chromium.org> wrote:
>All this work has landed and I've just updated the documentation. Since
>there was no documentation at all for plugin return values, I added a
>whole
>section about it. If anyone wants to proof read, Commit:
>http://git-wip-us.apache.org/repos/asf/cordova-docs/commit/9927fcdf
>
>Also, I've replaced the current mobile-spec bridge autotests from doing
>bad
>benchmarks that didn't work (and we now have benchmark tests anyway), with
>a simple set of bridge smoke tests for echoing various message types.
> Android seems to jave jake tests to smoke test the bridge, so maybe I
>should move those there..
>
>-Michal
>
>
>On Thu, Feb 14, 2013 at 9:42 AM, Max Woghiren <ma...@google.com> wrote:
>
>> I agree with Shaz‹in general we should start using this type of syntax
>>for
>> dictionaries:
>>
>> return @{@"CDVType": @"Multipart", @"messages": messages};
>>
>> I'd say messageAsMultipart: makes sense, in keeping with the pattern set
>> by the other names.
>>
>>
>> On Thu, Feb 14, 2013 at 9:24 AM, Michal Mocny <mm...@chromium.org>
>>wrote:
>>
>>> And also: do we like the name "messageAsMultipart:" or should it just
>>>be
>>> "messageWithArguments:"?
>>>
>>>
>>> On Thu, Feb 14, 2013 at 9:23 AM, Michal Mocny <mm...@chromium.org>
>>> wrote:
>>>
>>> > Andrew,
>>> >
>>> > Yes I was definitely thinking the same thing, but wanted to do that
>>> later.
>>> > I'll make the change before documenting how multipart messages
>>>work, as
>>> > shaz suggested. Thanks for giving me a heads up about reference to
>>>it
>>> on
>>> > android. Also: other platforms dont use it?
>>> >
>>> > -Michal
>>> >
>>> >
>>> > On Wed, Feb 13, 2013 at 10:51 PM, Andrew Grieve <agrieve@chromium.org
>>> >wrote:
>>> >
>>> >> My only comment is that I think it's worth refactoring
>>> >> cordova.callbackFromNative so that it passes the multiple values to
>>> >> callbacks as separate parameters. All references to it are in
>>> cordova-js
>>> >> plus one in Android's NativeToJsMessageQueue.java
>>> >>
>>> >>
>>> >> On Wed, Feb 13, 2013 at 5:42 PM, Shazron <sh...@gmail.com> wrote:
>>> >>
>>> >>> Looks good to me.
>>> >>> Although I have a bone to pick with dictionaryWithObjectsAndKeys
>>> having
>>> >>> objects first but that's not our problem ;) Good thing they support
>>> >>> literal
>>> >>> notation now...
>>> >>>
>>> >>>
>>> >>> On Wed, Feb 13, 2013 at 12:24 PM, Michal Mocny
>>><mm...@chromium.org>
>>> >>> wrote:
>>> >>>
>>> >>> > 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=r
>>>efs/heads/multipart_plugin_result
>>> >>> > > js:
>>> >>> > >
>>> >>> >
>>> >>>
>>>
>>>https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=re
>>>fs/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 <sh...@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
>>> >>> > >> >
>>> >>> > >>
>>> >>> > >
>>> >>> > >
>>> >>> >
>>> >>>
>>> >>
>>> >>
>>> >
>>>
>>
>>
Re: Supporting multiple plugin return values
Posted by Michal Mocny <mm...@chromium.org>.
All this work has landed and I've just updated the documentation. Since
there was no documentation at all for plugin return values, I added a whole
section about it. If anyone wants to proof read, Commit:
http://git-wip-us.apache.org/repos/asf/cordova-docs/commit/9927fcdf
Also, I've replaced the current mobile-spec bridge autotests from doing bad
benchmarks that didn't work (and we now have benchmark tests anyway), with
a simple set of bridge smoke tests for echoing various message types.
Android seems to jave jake tests to smoke test the bridge, so maybe I
should move those there..
-Michal
On Thu, Feb 14, 2013 at 9:42 AM, Max Woghiren <ma...@google.com> wrote:
> I agree with Shaz—in general we should start using this type of syntax for
> dictionaries:
>
> return @{@"CDVType": @"Multipart", @"messages": messages};
>
> I'd say messageAsMultipart: makes sense, in keeping with the pattern set
> by the other names.
>
>
> On Thu, Feb 14, 2013 at 9:24 AM, Michal Mocny <mm...@chromium.org> wrote:
>
>> And also: do we like the name "messageAsMultipart:" or should it just be
>> "messageWithArguments:"?
>>
>>
>> On Thu, Feb 14, 2013 at 9:23 AM, Michal Mocny <mm...@chromium.org>
>> wrote:
>>
>> > Andrew,
>> >
>> > Yes I was definitely thinking the same thing, but wanted to do that
>> later.
>> > I'll make the change before documenting how multipart messages work, as
>> > shaz suggested. Thanks for giving me a heads up about reference to it
>> on
>> > android. Also: other platforms dont use it?
>> >
>> > -Michal
>> >
>> >
>> > On Wed, Feb 13, 2013 at 10:51 PM, Andrew Grieve <agrieve@chromium.org
>> >wrote:
>> >
>> >> My only comment is that I think it's worth refactoring
>> >> cordova.callbackFromNative so that it passes the multiple values to
>> >> callbacks as separate parameters. All references to it are in
>> cordova-js
>> >> plus one in Android's NativeToJsMessageQueue.java
>> >>
>> >>
>> >> On Wed, Feb 13, 2013 at 5:42 PM, Shazron <sh...@gmail.com> wrote:
>> >>
>> >>> Looks good to me.
>> >>> Although I have a bone to pick with dictionaryWithObjectsAndKeys
>> having
>> >>> objects first but that's not our problem ;) Good thing they support
>> >>> literal
>> >>> notation now...
>> >>>
>> >>>
>> >>> On Wed, Feb 13, 2013 at 12:24 PM, Michal Mocny <mm...@chromium.org>
>> >>> wrote:
>> >>>
>> >>> > 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 <sh...@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
>> >>> > >> >
>> >>> > >>
>> >>> > >
>> >>> > >
>> >>> >
>> >>>
>> >>
>> >>
>> >
>>
>
>
Re: Supporting multiple plugin return values
Posted by Max Woghiren <ma...@google.com>.
I agree with Shaz—in general we should start using this type of syntax for
dictionaries:
return @{@"CDVType": @"Multipart", @"messages": messages};
I'd say messageAsMultipart: makes sense, in keeping with the pattern set by
the other names.
On Thu, Feb 14, 2013 at 9:24 AM, Michal Mocny <mm...@chromium.org> wrote:
> And also: do we like the name "messageAsMultipart:" or should it just be
> "messageWithArguments:"?
>
>
> On Thu, Feb 14, 2013 at 9:23 AM, Michal Mocny <mm...@chromium.org> wrote:
>
> > Andrew,
> >
> > Yes I was definitely thinking the same thing, but wanted to do that
> later.
> > I'll make the change before documenting how multipart messages work, as
> > shaz suggested. Thanks for giving me a heads up about reference to it on
> > android. Also: other platforms dont use it?
> >
> > -Michal
> >
> >
> > On Wed, Feb 13, 2013 at 10:51 PM, Andrew Grieve <agrieve@chromium.org
> >wrote:
> >
> >> My only comment is that I think it's worth refactoring
> >> cordova.callbackFromNative so that it passes the multiple values to
> >> callbacks as separate parameters. All references to it are in cordova-js
> >> plus one in Android's NativeToJsMessageQueue.java
> >>
> >>
> >> On Wed, Feb 13, 2013 at 5:42 PM, Shazron <sh...@gmail.com> wrote:
> >>
> >>> Looks good to me.
> >>> Although I have a bone to pick with dictionaryWithObjectsAndKeys having
> >>> objects first but that's not our problem ;) Good thing they support
> >>> literal
> >>> notation now...
> >>>
> >>>
> >>> On Wed, Feb 13, 2013 at 12:24 PM, Michal Mocny <mm...@chromium.org>
> >>> wrote:
> >>>
> >>> > ping. Shaz?
> >>> >
> >>> >
> >>> > On Tue, Feb 12, 2013 at 11:28 AM, Michal Mocny <mm...@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 <sh...@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
> >>> > >> >
> >>> > >>
> >>> > >
> >>> > >
> >>> >
> >>>
> >>
> >>
> >
>
Re: Supporting multiple plugin return values
Posted by Michal Mocny <mm...@chromium.org>.
And also: do we like the name "messageAsMultipart:" or should it just be
"messageWithArguments:"?
On Thu, Feb 14, 2013 at 9:23 AM, Michal Mocny <mm...@chromium.org> wrote:
> Andrew,
>
> Yes I was definitely thinking the same thing, but wanted to do that later.
> I'll make the change before documenting how multipart messages work, as
> shaz suggested. Thanks for giving me a heads up about reference to it on
> android. Also: other platforms dont use it?
>
> -Michal
>
>
> On Wed, Feb 13, 2013 at 10:51 PM, Andrew Grieve <ag...@chromium.org>wrote:
>
>> My only comment is that I think it's worth refactoring
>> cordova.callbackFromNative so that it passes the multiple values to
>> callbacks as separate parameters. All references to it are in cordova-js
>> plus one in Android's NativeToJsMessageQueue.java
>>
>>
>> On Wed, Feb 13, 2013 at 5:42 PM, Shazron <sh...@gmail.com> wrote:
>>
>>> Looks good to me.
>>> Although I have a bone to pick with dictionaryWithObjectsAndKeys having
>>> objects first but that's not our problem ;) Good thing they support
>>> literal
>>> notation now...
>>>
>>>
>>> On Wed, Feb 13, 2013 at 12:24 PM, Michal Mocny <mm...@chromium.org>
>>> wrote:
>>>
>>> > ping. Shaz?
>>> >
>>> >
>>> > On Tue, Feb 12, 2013 at 11:28 AM, Michal Mocny <mm...@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 <sh...@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 <mm...@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
>>> > >> >
>>> > >>
>>> > >
>>> > >
>>> >
>>>
>>
>>
>
Re: Supporting multiple plugin return values
Posted by Michal Mocny <mm...@chromium.org>.
Andrew,
Yes I was definitely thinking the same thing, but wanted to do that later.
I'll make the change before documenting how multipart messages work, as
shaz suggested. Thanks for giving me a heads up about reference to it on
android. Also: other platforms dont use it?
-Michal
On Wed, Feb 13, 2013 at 10:51 PM, Andrew Grieve <ag...@chromium.org>wrote:
> My only comment is that I think it's worth refactoring
> cordova.callbackFromNative so that it passes the multiple values to
> callbacks as separate parameters. All references to it are in cordova-js
> plus one in Android's NativeToJsMessageQueue.java
>
>
> On Wed, Feb 13, 2013 at 5:42 PM, Shazron <sh...@gmail.com> wrote:
>
>> Looks good to me.
>> Although I have a bone to pick with dictionaryWithObjectsAndKeys having
>> objects first but that's not our problem ;) Good thing they support
>> literal
>> notation now...
>>
>>
>> On Wed, Feb 13, 2013 at 12:24 PM, Michal Mocny <mm...@chromium.org>
>> wrote:
>>
>> > ping. Shaz?
>> >
>> >
>> > On Tue, Feb 12, 2013 at 11:28 AM, Michal Mocny <mm...@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 <sh...@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 <mm...@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
>> > >> >
>> > >>
>> > >
>> > >
>> >
>>
>
>
Re: Supporting multiple plugin return values
Posted by Andrew Grieve <ag...@chromium.org>.
My only comment is that I think it's worth refactoring
cordova.callbackFromNative so that it passes the multiple values to
callbacks as separate parameters. All references to it are in cordova-js
plus one in Android's NativeToJsMessageQueue.java
On Wed, Feb 13, 2013 at 5:42 PM, Shazron <sh...@gmail.com> wrote:
> Looks good to me.
> Although I have a bone to pick with dictionaryWithObjectsAndKeys having
> objects first but that's not our problem ;) Good thing they support literal
> notation now...
>
>
> On Wed, Feb 13, 2013 at 12:24 PM, Michal Mocny <mm...@chromium.org>
> wrote:
>
> > ping. Shaz?
> >
> >
> > On Tue, Feb 12, 2013 at 11:28 AM, Michal Mocny <mm...@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 <sh...@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 <mm...@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
> > >> >
> > >>
> > >
> > >
> >
>
Re: Supporting multiple plugin return values
Posted by Shazron <sh...@gmail.com>.
Looks good to me.
Although I have a bone to pick with dictionaryWithObjectsAndKeys having
objects first but that's not our problem ;) Good thing they support literal
notation now...
On Wed, Feb 13, 2013 at 12:24 PM, Michal Mocny <mm...@chromium.org> wrote:
> ping. Shaz?
>
>
> On Tue, Feb 12, 2013 at 11:28 AM, Michal Mocny <mm...@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 <sh...@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 <mm...@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
> >> >
> >>
> >
> >
>
Re: Supporting multiple plugin return values
Posted by Michal Mocny <mm...@chromium.org>.
ping. Shaz?
On Tue, Feb 12, 2013 at 11:28 AM, Michal Mocny <mm...@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 <sh...@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 <mm...@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
>> >
>>
>
>