incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Plaquette <>
Subject Re: Unified JS Contact object
Date Mon, 16 Apr 2012 08:48:20 GMT

On 07/04/2012 10:55, Filip Maj wrote:
>> 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?

the parameter passed into the success callback.

>> in the callback we are sure the contact was deleted, and so any
>> associated data should be removed too.
>> Regards,
>> Paul
>> 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
>>> wonder
>>> if that's done?
>>> Returning the contact object entirely may make sense (providing
>>> feedback,
>>> "Bob has been deleted"), but in most cases nested JS callbacks should
>>> also
>>> 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
>>>> felt
>>>> 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,
>>>> in
>>>> the success callback. Android does not.   We need to agree on this
>>>> behavior
>>>> and update as needed.   The current documentation does not indicate
>>>> what
>>>> is
>>>> returned in the success callback.
>>>> In the unified JS only  the id is passed to the remove function.  This
>>>> is
>>>> fine if we are only going to remove the contact and not pass anything
>>>> back
>>>> in the success callback.   However, iOS previously passed the entire
>>>> contact object into remove.  The reason for this was so the contact
>>>> object
>>>> could be easily returned without having to look it up in the address
>>>> book
>>>> based on the id, then convert it to the proper format in order to
>>>> return.
>>>> Thus, if we return the contact object in the contact.remove success
>>>> callback, we should pass the entire contact object as the parameter.
>>>> If
>>>> 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
>>>> for
>>>> 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
>>>> removed
>>>> 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 -
>>>>> just
>>>>> 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
>>>>>> null:
>>>>>> 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
>>>>>> 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
>>>>> 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
>>>>>> 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

Paul Plaquette
Senior Software Engineer
Open Source Technology Center
Intel Corp.,Montpellier, France

View raw message