incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: ContactField
Date Thu, 26 Apr 2012 22:34:25 GMT
Yeah :)

On Thu, Apr 26, 2012 at 3:33 PM, Filip Maj <fil@adobe.com> wrote:
> 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]
>>>
>>>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" <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 = (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?
>>>
>

Mime
View raw message