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