incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <>
Subject Re: Unified JS Contact object
Date Sat, 07 Apr 2012 08:55:15 GMT

>returning the id of the deleted contact object is of  interest  if an
>application is associating a contact id to another dataset  managed by
>the application.

Are you talking about the return value of the remove Contact function, or
the parameter passed into the remove's success callback?

>in the callback we are sure the contact was deleted, and so any
>associated data should be removed too.
>On 13/03/2012 16:40, Filip Maj wrote:
>> I can't think of a reason to return the id unless people are doing
>> webview-side caching of contacts or something along those linesÅ  I
>> if that's done?
>> Returning the contact object entirely may make sense (providing
>> "Bob has been deleted"), but in most cases nested JS callbacks should
>> be able to handle this situation via closures.
>> I'm indifferent as well...
>> On 3/13/12 6:47 AM, "Becky Gibson"<>  wrote:
>>> I found another Contacts issue.   The platforms have different return
>>> values for contact.remove.  There is no remove in the W3C spec but we
>>> that removal should be supported so we added this api into the PhoneGap
>>> Contact object.
>>> BB and iOS return the removed contact object, with its id set to null,
>>> the success callback. Android does not.   We need to agree on this
>>> behavior
>>> and update as needed.   The current documentation does not indicate
>>> is
>>> returned in the success callback.
>>> In the unified JS only  the id is passed to the remove function.  This
>>> fine if we are only going to remove the contact and not pass anything
>>> in the success callback.   However, iOS previously passed the entire
>>> contact object into remove.  The reason for this was so the contact
>>> could be easily returned without having to look it up in the address
>>> based on the id, then convert it to the proper format in order to
>>> Thus, if we return the contact object in the contact.remove success
>>> callback, we should pass the entire contact object as the parameter.
>>> we
>>> do not want to return anything in the success callback, we only need to
>>> pass in the id.   Whatever we decide it will be a change in behavior
>>> either Android or BB and iOS.  I don't have a strong preference.  It is
>>> probably easier to return nothing in the remove success callback.   Can
>>> anyone think of reasons that the remove callback should return the
>>> contact object?
>>> -becky
>>> On Mon, Mar 12, 2012 at 2:56 PM, Filip Maj<>  wrote:
>>>> Let's make the change and I can test it out on Android on my end -
>>>> ping me.
>>>> On 3/12/12 10:22 AM, "Becky Gibson"<>  wrote:
>>>>> The unified JS contact object initializes the contact object
>>>> incorrectly.
>>>>> Base on the June, 2011 and March, 2012 definition for the contact
>>>> object,
>>>>> parameters that are not defined should have the initial value of
>>>>> All Contact<>
>>>> objects *
>>>>> must* include all attributes supported by the implementation,
>>>> regardless
>>>>> of
>>>>> whether these attributes have been assigned a null value or not. If a
>>>>> supported attribute has not been assigned a value by the user or the
>>>>> implementation, then this attribute *must* still be present in the
>>>>> resulting Contact<>
>>>>> object
>>>>> and *must* have a value of null.
>>>>> The current implementation initializes all of the array fields to an
>>>> empty
>>>>> array rather than null if no value is provided.   The iOS code relies
>>>> on
>>>>> the distinction between null and empty array during an update of a
>>>>> contact.
>>>>> If an array value is null, that parameter is ignored (not changed),
>>>> if it
>>>>> is an empty array and data exists, the stored date for that parameter
>>>> is
>>>>> removed.
>>>>> Not sure if changing this back to the spec will affect the other
>>>>> platforms?
>>>>> -becky
>Paul Plaquette
>Senior Software Engineer
>Open Source Technology Center
>Intel Corp.,Montpellier, France

View raw message