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 <[email protected]> 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 <[email protected]> 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 > > >
