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.html# homePhone [3] https://github.com/apache/incubator-cordova-wp7/blob/master/framework/Cordo 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/plu >>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?
