You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Becky Gibson <gi...@gmail.com> on 2012/04/03 22:44:34 UTC

Passing parameters to camera.getPicture instead of object -WHY?

Somehow I missed this change in unified JS. Why are we now passing an array
of parameters to getPicture rather than an options object?   By passing the
object, we allowed people to easily extend the getPicture api by just
adding their new option into an options object and modifying their copy of
the device specific camera implementation. They did not have to modify the
PhoneGap/Cordova.js implementation (at least on the iOS side).  Now, in
order to add a new parameter to getPicture, you need to modify the JS as
well to pass yet another parameter into getPicture - the list is already
long and we have lost some of the iOS options that were available.

curious minds are a dangerous thing......

Re: Passing parameters to camera.getPicture instead of object -WHY?

Posted by Shazron <sh...@gmail.com>.
Now all we have to figure out is how to support the options stuff that
was already in there without it being a maintenance nightmare...

On Tue, Apr 3, 2012 at 2:03 PM, Filip Maj <fi...@adobe.com> wrote:
> Yeah I did my best to test all that on iOS when I did the integration work
> on that platform. Obviously missed the notification API issue that came up
> today.
>
> Just to play devil's advocate, the brittle argument can work both ways :)
> sure I can use the wrong array index, but I can also misspell the named
> property name, and actually do that in TWO (JS + native) implementations
> instead of one.
>
> I agree though, for readability alone, I think the options object is nicer.
>
> On 4/3/12 1:57 PM, "Shazron" <sh...@gmail.com> wrote:
>
>>Hi Fil,
>>Just to make sure since I have to verify all the APIs don't use the
>>options object anymore and possibly fix those -- this was done across
>>the board, true?
>>
>>Yeah lets do a hashmap thing for arguments in some future release,
>>indexed arguments are brittle.
>>
>>Shaz
>>
>>On Tue, Apr 3, 2012 at 1:51 PM, Shazron <sh...@gmail.com> wrote:
>>> My guess is this change was to match the Android side, I had to make
>>> the same change for Notification API, which broke because of this.
>>>
>>> On Tue, Apr 3, 2012 at 1:44 PM, Becky Gibson <gi...@gmail.com>
>>>wrote:
>>>> Somehow I missed this change in unified JS. Why are we now passing an
>>>>array
>>>> of parameters to getPicture rather than an options object?   By
>>>>passing the
>>>> object, we allowed people to easily extend the getPicture api by just
>>>> adding their new option into an options object and modifying their
>>>>copy of
>>>> the device specific camera implementation. They did not have to modify
>>>>the
>>>> PhoneGap/Cordova.js implementation (at least on the iOS side).  Now, in
>>>> order to add a new parameter to getPicture, you need to modify the JS
>>>>as
>>>> well to pass yet another parameter into getPicture - the list is
>>>>already
>>>> long and we have lost some of the iOS options that were available.
>>>>
>>>> curious minds are a dangerous thing......
>

Re: Passing parameters to camera.getPicture instead of object -WHY?

Posted by Shazron <sh...@gmail.com>.
Gord - the OP's problem is not how to pass it in, but the signature
change in JS which affects Obj-C core plugins (was options object, now
options are arguments)

imo changing the exec signature however, should be another discussion..


On Tue, Apr 3, 2012 at 3:11 PM,  <gt...@gmail.com> wrote:
> If someone wanted an options arg why couldn't they just pass:
>
> [{f: 2, a: 1}]
>
> I think I am just missing the need to choose one or the other, where the array seems fine.
>
>
> Sent on the TELUS Mobility network with BlackBerry
>
> -----Original Message-----
> From: Becky Gibson <gi...@gmail.com>
> Date: Tue, 3 Apr 2012 17:27:33
> To: <ca...@incubator.apache.org>
> Reply-To: callback-dev@incubator.apache.org
> Subject: Re: Passing parameters to camera.getPicture instead of object -WHY?
>
> Ok, so to support iOS camera.getPicture for this release, I need to add 3
> more arguments to the takePicture device api - bringing the total up to 10!
>  And then in 1.7, we get to undo all of this work - wtf?  And, just for the
> record,  the call to exec from the Android 1.4.1 camera.getPicture()
>  accepted an options parameter  and passed those to CameraLauncher.java as
> an object.
>
> sorry, but I'm just a bit cranky as I keep discovering all of the things
> that are broken in unified JS.
>
> -b
>
> On Tue, Apr 3, 2012 at 4:57 PM, Shazron <sh...@gmail.com> wrote:
>
>> Hi Fil,
>> Just to make sure since I have to verify all the APIs don't use the
>> options object anymore and possibly fix those -- this was done across
>> the board, true?
>>
>> Yeah lets do a hashmap thing for arguments in some future release,
>> indexed arguments are brittle.
>>
>> Shaz
>>
>> On Tue, Apr 3, 2012 at 1:51 PM, Shazron <sh...@gmail.com> wrote:
>> > My guess is this change was to match the Android side, I had to make
>> > the same change for Notification API, which broke because of this.
>> >
>> > On Tue, Apr 3, 2012 at 1:44 PM, Becky Gibson <gi...@gmail.com>
>> wrote:
>> >> Somehow I missed this change in unified JS. Why are we now passing an
>> array
>> >> of parameters to getPicture rather than an options object?   By passing
>> the
>> >> object, we allowed people to easily extend the getPicture api by just
>> >> adding their new option into an options object and modifying their copy
>> of
>> >> the device specific camera implementation. They did not have to modify
>> the
>> >> PhoneGap/Cordova.js implementation (at least on the iOS side).  Now, in
>> >> order to add a new parameter to getPicture, you need to modify the JS as
>> >> well to pass yet another parameter into getPicture - the list is already
>> >> long and we have lost some of the iOS options that were available.
>> >>
>> >> curious minds are a dangerous thing......
>>
>

Re: Passing parameters to camera.getPicture instead of object -WHY?

Posted by gt...@gmail.com.
If someone wanted an options arg why couldn't they just pass:

[{f: 2, a: 1}]

I think I am just missing the need to choose one or the other, where the array seems fine.


Sent on the TELUS Mobility network with BlackBerry

-----Original Message-----
From: Becky Gibson <gi...@gmail.com>
Date: Tue, 3 Apr 2012 17:27:33 
To: <ca...@incubator.apache.org>
Reply-To: callback-dev@incubator.apache.org
Subject: Re: Passing parameters to camera.getPicture instead of object -WHY?

Ok, so to support iOS camera.getPicture for this release, I need to add 3
more arguments to the takePicture device api - bringing the total up to 10!
 And then in 1.7, we get to undo all of this work - wtf?  And, just for the
record,  the call to exec from the Android 1.4.1 camera.getPicture()
 accepted an options parameter  and passed those to CameraLauncher.java as
an object.

sorry, but I'm just a bit cranky as I keep discovering all of the things
that are broken in unified JS.

-b

On Tue, Apr 3, 2012 at 4:57 PM, Shazron <sh...@gmail.com> wrote:

> Hi Fil,
> Just to make sure since I have to verify all the APIs don't use the
> options object anymore and possibly fix those -- this was done across
> the board, true?
>
> Yeah lets do a hashmap thing for arguments in some future release,
> indexed arguments are brittle.
>
> Shaz
>
> On Tue, Apr 3, 2012 at 1:51 PM, Shazron <sh...@gmail.com> wrote:
> > My guess is this change was to match the Android side, I had to make
> > the same change for Notification API, which broke because of this.
> >
> > On Tue, Apr 3, 2012 at 1:44 PM, Becky Gibson <gi...@gmail.com>
> wrote:
> >> Somehow I missed this change in unified JS. Why are we now passing an
> array
> >> of parameters to getPicture rather than an options object?   By passing
> the
> >> object, we allowed people to easily extend the getPicture api by just
> >> adding their new option into an options object and modifying their copy
> of
> >> the device specific camera implementation. They did not have to modify
> the
> >> PhoneGap/Cordova.js implementation (at least on the iOS side).  Now, in
> >> order to add a new parameter to getPicture, you need to modify the JS as
> >> well to pass yet another parameter into getPicture - the list is already
> >> long and we have lost some of the iOS options that were available.
> >>
> >> curious minds are a dangerous thing......
>


Re: Passing parameters to camera.getPicture instead of object -WHY?

Posted by Becky Gibson <gi...@gmail.com>.
Ok, so to support iOS camera.getPicture for this release, I need to add 3
more arguments to the takePicture device api - bringing the total up to 10!
 And then in 1.7, we get to undo all of this work - wtf?  And, just for the
record,  the call to exec from the Android 1.4.1 camera.getPicture()
 accepted an options parameter  and passed those to CameraLauncher.java as
an object.

sorry, but I'm just a bit cranky as I keep discovering all of the things
that are broken in unified JS.

-b

On Tue, Apr 3, 2012 at 4:57 PM, Shazron <sh...@gmail.com> wrote:

> Hi Fil,
> Just to make sure since I have to verify all the APIs don't use the
> options object anymore and possibly fix those -- this was done across
> the board, true?
>
> Yeah lets do a hashmap thing for arguments in some future release,
> indexed arguments are brittle.
>
> Shaz
>
> On Tue, Apr 3, 2012 at 1:51 PM, Shazron <sh...@gmail.com> wrote:
> > My guess is this change was to match the Android side, I had to make
> > the same change for Notification API, which broke because of this.
> >
> > On Tue, Apr 3, 2012 at 1:44 PM, Becky Gibson <gi...@gmail.com>
> wrote:
> >> Somehow I missed this change in unified JS. Why are we now passing an
> array
> >> of parameters to getPicture rather than an options object?   By passing
> the
> >> object, we allowed people to easily extend the getPicture api by just
> >> adding their new option into an options object and modifying their copy
> of
> >> the device specific camera implementation. They did not have to modify
> the
> >> PhoneGap/Cordova.js implementation (at least on the iOS side).  Now, in
> >> order to add a new parameter to getPicture, you need to modify the JS as
> >> well to pass yet another parameter into getPicture - the list is already
> >> long and we have lost some of the iOS options that were available.
> >>
> >> curious minds are a dangerous thing......
>

Re: Passing parameters to camera.getPicture instead of object -WHY?

Posted by Filip Maj <fi...@adobe.com>.
Yeah I did my best to test all that on iOS when I did the integration work
on that platform. Obviously missed the notification API issue that came up
today.

Just to play devil's advocate, the brittle argument can work both ways :)
sure I can use the wrong array index, but I can also misspell the named
property name, and actually do that in TWO (JS + native) implementations
instead of one.

I agree though, for readability alone, I think the options object is nicer.

On 4/3/12 1:57 PM, "Shazron" <sh...@gmail.com> wrote:

>Hi Fil,
>Just to make sure since I have to verify all the APIs don't use the
>options object anymore and possibly fix those -- this was done across
>the board, true?
>
>Yeah lets do a hashmap thing for arguments in some future release,
>indexed arguments are brittle.
>
>Shaz
>
>On Tue, Apr 3, 2012 at 1:51 PM, Shazron <sh...@gmail.com> wrote:
>> My guess is this change was to match the Android side, I had to make
>> the same change for Notification API, which broke because of this.
>>
>> On Tue, Apr 3, 2012 at 1:44 PM, Becky Gibson <gi...@gmail.com>
>>wrote:
>>> Somehow I missed this change in unified JS. Why are we now passing an
>>>array
>>> of parameters to getPicture rather than an options object?   By
>>>passing the
>>> object, we allowed people to easily extend the getPicture api by just
>>> adding their new option into an options object and modifying their
>>>copy of
>>> the device specific camera implementation. They did not have to modify
>>>the
>>> PhoneGap/Cordova.js implementation (at least on the iOS side).  Now, in
>>> order to add a new parameter to getPicture, you need to modify the JS
>>>as
>>> well to pass yet another parameter into getPicture - the list is
>>>already
>>> long and we have lost some of the iOS options that were available.
>>>
>>> curious minds are a dangerous thing......


Re: Passing parameters to camera.getPicture instead of object -WHY?

Posted by Shazron <sh...@gmail.com>.
Hi Fil,
Just to make sure since I have to verify all the APIs don't use the
options object anymore and possibly fix those -- this was done across
the board, true?

Yeah lets do a hashmap thing for arguments in some future release,
indexed arguments are brittle.

Shaz

On Tue, Apr 3, 2012 at 1:51 PM, Shazron <sh...@gmail.com> wrote:
> My guess is this change was to match the Android side, I had to make
> the same change for Notification API, which broke because of this.
>
> On Tue, Apr 3, 2012 at 1:44 PM, Becky Gibson <gi...@gmail.com> wrote:
>> Somehow I missed this change in unified JS. Why are we now passing an array
>> of parameters to getPicture rather than an options object?   By passing the
>> object, we allowed people to easily extend the getPicture api by just
>> adding their new option into an options object and modifying their copy of
>> the device specific camera implementation. They did not have to modify the
>> PhoneGap/Cordova.js implementation (at least on the iOS side).  Now, in
>> order to add a new parameter to getPicture, you need to modify the JS as
>> well to pass yet another parameter into getPicture - the list is already
>> long and we have lost some of the iOS options that were available.
>>
>> curious minds are a dangerous thing......

Re: Passing parameters to camera.getPicture instead of object -WHY?

Posted by Filip Maj <fi...@adobe.com>.
My additional justification was that BOTH android and BB used the array
approach, and only iOS used the object approach, so I went with what the
majority of platforms rolled with.

On 4/3/12 1:51 PM, "Shazron" <sh...@gmail.com> wrote:

>My guess is this change was to match the Android side, I had to make
>the same change for Notification API, which broke because of this.
>
>On Tue, Apr 3, 2012 at 1:44 PM, Becky Gibson <gi...@gmail.com>
>wrote:
>> Somehow I missed this change in unified JS. Why are we now passing an
>>array
>> of parameters to getPicture rather than an options object?   By passing
>>the
>> object, we allowed people to easily extend the getPicture api by just
>> adding their new option into an options object and modifying their copy
>>of
>> the device specific camera implementation. They did not have to modify
>>the
>> PhoneGap/Cordova.js implementation (at least on the iOS side).  Now, in
>> order to add a new parameter to getPicture, you need to modify the JS as
>> well to pass yet another parameter into getPicture - the list is already
>> long and we have lost some of the iOS options that were available.
>>
>> curious minds are a dangerous thing......


Re: Passing parameters to camera.getPicture instead of object -WHY?

Posted by Shazron <sh...@gmail.com>.
My guess is this change was to match the Android side, I had to make
the same change for Notification API, which broke because of this.

On Tue, Apr 3, 2012 at 1:44 PM, Becky Gibson <gi...@gmail.com> wrote:
> Somehow I missed this change in unified JS. Why are we now passing an array
> of parameters to getPicture rather than an options object?   By passing the
> object, we allowed people to easily extend the getPicture api by just
> adding their new option into an options object and modifying their copy of
> the device specific camera implementation. They did not have to modify the
> PhoneGap/Cordova.js implementation (at least on the iOS side).  Now, in
> order to add a new parameter to getPicture, you need to modify the JS as
> well to pass yet another parameter into getPicture - the list is already
> long and we have lost some of the iOS options that were available.
>
> curious minds are a dangerous thing......

Re: Passing parameters to camera.getPicture instead of object -WHY?

Posted by Filip Maj <fi...@adobe.com>.
It got changed because each platform implementation did it differently. So
one approach had to be axed (iOS options object) and another adopted
(Android parameter array).

As I brought up in the other thread, I like the options approach better.
Clearer on the JS side IMO. If there's consensus on the topic of what
approach the exec() method should employ, then we can slate the switch in
1.7 or 1.8 - would be pretty easy.

On 4/3/12 1:44 PM, "Becky Gibson" <gi...@gmail.com> wrote:

>Somehow I missed this change in unified JS. Why are we now passing an
>array
>of parameters to getPicture rather than an options object?   By passing
>the
>object, we allowed people to easily extend the getPicture api by just
>adding their new option into an options object and modifying their copy of
>the device specific camera implementation. They did not have to modify the
>PhoneGap/Cordova.js implementation (at least on the iOS side).  Now, in
>order to add a new parameter to getPicture, you need to modify the JS as
>well to pass yet another parameter into getPicture - the list is already
>long and we have lost some of the iOS options that were available.
>
>curious minds are a dangerous thing......