Thanks Michal! On 2/27/13 6:59 AM, "Michal Mocny" <mmo...@chromium.org> wrote:
>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=r >>>efs/heads/multipart_plugin_result >>> >>> > > js: >>> >>> > > >>> >>> > >>> >>> >>> >>>https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=re >>>fs/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 >>> >>> > >> > >>> >>> > >> >>> >>> > > >>> >>> > > >>> >>> > >>> >>> >>> >> >>> >> >>> > >>> >> >>
