ya that looks great thanks mang
On Wed, Feb 27, 2013 at 1:12 PM, Filip Maj <f...@adobe.com> wrote: > 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 >>>> >>> > >> > >>>> >>> > >> >>>> >>> > > >>>> >>> > > >>>> >>> > >>>> >>> >>>> >> >>>> >> >>>> > >>>> >>> >>> >
