cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Supporting multiple plugin return values
Date Thu, 14 Feb 2013 03:51:59 GMT
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 <shazron@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 <mmocny@chromium.org>
> wrote:
>
> > ping.  Shaz?
> >
> >
> > On Tue, Feb 12, 2013 at 11:28 AM, Michal Mocny <mmocny@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 <shazron@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 <mmocny@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
> > >> >
> > >>
> > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message