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 <m...@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 <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
>> >>> > >> >
>> >>> > >>
>> >>> > >
>> >>> > >
>> >>> >
>> >>>
>> >>
>> >>
>> >
>>
>
>
