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...@google.com> on 2013/01/18 20:55:15 UTC
Supporting multiple plugin return values
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
>> >
>>
>
>
Re: Supporting multiple plugin return values
Posted by Michal Mocny <mm...@chromium.org>.
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>.
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
>