cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <>
Subject Re: ContactField
Date Thu, 26 Apr 2012 22:25:33 GMT
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

On Thu, Apr 26, 2012 at 3:04 PM, Filip Maj <> 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]
> rc/org/apache/cordova/
> [2]
> homePhone
> [3]
> va/Commands/Contacts.cs#L140
> [4]
> [5]
> On 4/26/12 2:48 PM, "Shazron" <> wrote:
>>Ah it' short-circuit evaluation:
>>On Thu, Apr 26, 2012 at 2:41 PM, Shazron <> wrote:
>>> I'm attempting to fix:
>>> These lines:
>>> 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?

View raw message