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.39 as permitted sender)
From: Filip Maj <fil@adobe.com>
To: "callback-dev@incubator.apache.org" <callback-dev@incubator.apache.org>
Date: Sat, 7 Apr 2012 01:55:15 -0700
Subject: Re: Unified JS Contact object
Thread-Topic: Unified JS Contact object
Thread-Index: Ac0Um/O3qaiHrTYsQ/e7UHk+YNNFhQ==
Message-ID: <CBA54ED6.3A54%fil@adobe.com>
In-Reply-To: <4F7EB7B6.4030202@linux.intel.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.14.0.111121
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


>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.
>
>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=A9 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"<gibson.becky@gmail.com>  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<fil@adobe.com>  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"<gibson.becky@gmail.com>  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<http://w3c-test.org/dap/contacts/#idl-def-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<http://w3c-test.org/dap/contacts/#idl-def-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
>>>>
>>>>
>>
>>
>
>--=20
>Paul Plaquette
>Senior Software Engineer
>Open Source Technology Center
>Intel Corp.,Montpellier, France