cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Supporting multiple plugin return values
Date Thu, 14 Feb 2013 14:24:59 GMT
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 <mmocny@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 <shazron@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 <mmocny@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 <shazron@gmail.com>
wrote:
>>> > >
>>> > >> I don't see any problem with it as long as existing plugins (core
>>> and
>>> > >> third-party) don't break (unless we need to deprecate anything
of
>>> > course)
>>> > >>
>>> > >>
>>> > >> On Fri, Jan 18, 2013 at 11:55 AM, Michal Mocny <mmocny@google.com>
>>> > wrote:
>>> > >>
>>> > >> > I've filed https://issues.apache.org/jira/browse/CB-2239 but
>>> wanted
>>> > to
>>> > >> get
>>> > >> > feedback here in case there a simpler solution to this problem.
>>> > >> >
>>> > >> > Basically: I've recently added support for ArrayBuffer argument
>>> type
>>> > >> across
>>> > >> > iOS exec bridge and Braden added the same to Android.
>>> > >> >
>>> > >> > However, while working on a plugin to make use of this feature
>>> > >> (socket), we
>>> > >> > found that sound plugin calls expect to send an ArrayBuffer
back
>>> along
>>> > >> with
>>> > >> > over values.
>>> > >> >
>>> > >> > We considered adding a special bucket for ArrayBuffer return
>>> values to
>>> > >> the
>>> > >> > bridge, so that you can send a normal result + ArrayBuffer,
but
>>> > decided
>>> > >> > that wasn't scalable since we may want more custom non-json
>>> > serializable
>>> > >> > types in the future.
>>> > >> >
>>> > >> > We decided the best option was to allow returning a list of
>>> "cordova
>>> > >> bridge
>>> > >> > supported types", which includes everything we have had until
now
>>> +
>>> > >> > ArrayBuffer + whatever we add in the future.
>>> > >> >
>>> > >> > This shouldn't be a big change, existing plugins need not
change
>>> at
>>> > all,
>>> > >> > and it also opens up the possibility to do some interesting
>>> encodings
>>> > >> for
>>> > >> > return values whenever JSON isn't the most efficient (we do
some
>>> of
>>> > >> this on
>>> > >> > android already).
>>> > >> >
>>> > >> > -Michal
>>> > >> >
>>> > >>
>>> > >
>>> > >
>>> >
>>>
>>
>>
>

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