cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Supporting multiple plugin return values
Date Wed, 27 Feb 2013 21:12:28 GMT
Thanks Michal!

On 2/27/13 6:59 AM, "Michal Mocny" <mmocny@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 <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=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 <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
View raw message