Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of fil@adobe.com designates
 64.18.1.187 as permitted sender)
From: Filip Maj <fil@adobe.com>
To: "callback-dev@incubator.apache.org" <callback-dev@incubator.apache.org>
Date: Thu, 26 Apr 2012 15:33:10 -0700
Subject: Re: ContactField
Thread-Topic: ContactField
Thread-Index: Ac0j/DNFu4ULNlvcQ3SFSMKoc63S+A==
Message-ID: <CBBF1B32.52B7%fil@adobe.com>
In-Reply-To: 
 <CAE6O_-ZHL+PR8PU67wZJqTh8egTkqM4oG0uPMGRS1PitvaFSdg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.2.0.120402
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Just patch it dude!

On 4/26/12 3:25 PM, "Shazron" <shazron@gmail.com> 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 <fil@adobe.com> 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]
>>=20
>>https://github.com/apache/incubator-cordova-android/blob/master/framework
>>/s
>> rc/org/apache/cordova/ContactAccessorSdk5.java#L1355
>> [2]
>>=20
>>https://bdsc.webapps.blackberry.com/html5/apis/blackberry.pim.Contact.htm
>>l#
>> homePhone
>> [3]
>>=20
>>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=3Dvs.92).aspx
>> [5] http://www.w3.org/TR/contacts-api/#contactfield-interface
>>
>> On 4/26/12 2:48 PM, "Shazron" <shazron@gmail.com> wrote:
>>
>>>Ah it' short-circuit evaluation:
>>>http://en.wikipedia.org/wiki/Short-circuit_evaluation
>>>
>>>On Thu, Apr 26, 2012 at 2:41 PM, Shazron <shazron@gmail.com> 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 =3D (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?
>>