cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Supporting multiple plugin return values
Date Wed, 27 Feb 2013 14:59:24 GMT
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 <maxw@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 <mmocny@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 <mmocny@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 <agrieve@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 <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