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 <mmo...@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 <mmo...@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 <agri...@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 <shaz...@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 <mmo...@chromium.org>
> >>> wrote:
> >>>
> >>> > ping. Shaz?
> >>> >
> >>> >
> >>> > On Tue, Feb 12, 2013 at 11:28 AM, Michal Mocny <mmo...@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 <shaz...@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 <mmo...@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
> >>> > >> >
> >>> > >>
> >>> > >
> >>> > >
> >>> >
> >>>
> >>
> >>
> >
>
