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 > > >> > > > >> > > > > > > > > >
