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 Fri, 06 Apr 2012 09:30:30 GMT

I ported contact on cordova -tizen (first on WAC 2.0 and then on the 
tizen SDK contact API)

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.

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 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 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