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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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...... >
