Just patch it dude! On 4/26/12 3:25 PM, "Shazron" <[email protected]> wrote:
>Thanks Fil, >I guess this could be a documentation issue but I'd rather coerce the >values into strings. I'll send pull requests for cordova-js and >mobile-spec. > >On Thu, Apr 26, 2012 at 3:04 PM, Filip Maj <[email protected]> wrote: >> Looks to me like Android assumes a string for a phone number's "value" >> property [1]. >> >> BlackBerry uses WebWorks' PIM javascript API which I think handles >> number/string conversion on its own, but the API reference says phone >> numbers are supposed to be strings [2]. >> >> Looks to me like WP7 assumes strings as well [3] (where the ContactField >> generic object has value properties of type string). Also the WP7 SDK >> native example documentation [4] clearly assigns strings to phone >>numbers. >> >> Finally: the W3C spec of the contacts API says that phone numbers should >> be an array of ContactField objects, and the ContactField object's value >> property is always a string [5]. >> >> I say: force people to use a string. There's a lot of stuff in there too >> that can't be mapped as a number. What if you have a dash, a space, a #, >> parentheses for area codes, etc. >> >> We could easily coerce everything passed into Contact Field values as >> strings (as per your suggestion). >> >> [1] >> >>https://github.com/apache/incubator-cordova-android/blob/master/framework >>/s >> rc/org/apache/cordova/ContactAccessorSdk5.java#L1355 >> [2] >> >>https://bdsc.webapps.blackberry.com/html5/apis/blackberry.pim.Contact.htm >>l# >> homePhone >> [3] >> >>https://github.com/apache/incubator-cordova-wp7/blob/master/framework/Cor >>do >> va/Commands/Contacts.cs#L140 >> [4] http://msdn.microsoft.com/en-us/library/hh394013(v=vs.92).aspx >> [5] http://www.w3.org/TR/contacts-api/#contactfield-interface >> >> On 4/26/12 2:48 PM, "Shazron" <[email protected]> wrote: >> >>>Ah it' short-circuit evaluation: >>>http://en.wikipedia.org/wiki/Short-circuit_evaluation >>> >>>On Thu, Apr 26, 2012 at 2:41 PM, Shazron <[email protected]> wrote: >>>> I'm attempting to fix: https://issues.apache.org/jira/browse/CB-567 >>>> >>>> These lines: >>>>https://github.com/apache/incubator-cordova-js/blob/master/lib/common/p >>>>lu >>>>gin/ContactField.js#L11-12 >>>> >>>> The problem is, in iOS some users are passing in the type and value >>>> properties as numbers but not strings. These are passed in to Obj-C as >>>> the same type (NSNumber) and are passed directly to the underlying >>>> AddressBook framework untouched (it will require code to filter and >>>> test for these props, and I'd rather not touch working code at this >>>> point, and it's a lot of code if you look at it) but it will throw an >>>> exception because it didn't expect a NSNumber. I know, it's really a >>>> bug in their implementation but I'm asking for suggestions on how best >>>> to fix this. >>>> >>>> I'm thinking that I could just .toString() the properties and this >>>> does solve the problem, but since this is common code I'm wondering >>>> what the side effects are for the other platforms. Or should we punt >>>> this and just say "don't do that!" for the problem? >>>> >>>> As an aside, this is what I propose for the fix for example: >>>> >>>> this.type = (type && type.toString()) || null; >>>> >>>> It seems to work from my tests but I'm not exactly sure why (type && >>>> type.toString()) evaluates to a String (where it will evaluate that >>>> expression when type is anything non-null) - something for wtfjs? >>
