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.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? >
