cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Supporting multiple plugin return values
Date Thu, 28 Feb 2013 07:46:44 GMT
ya that looks great thanks mang

On Wed, Feb 27, 2013 at 1:12 PM, Filip Maj <fil@adobe.com> wrote:
> 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