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.33 as permitted sender)
From: Filip Maj <fil@adobe.com>
To: "callback-dev@incubator.apache.org" <callback-dev@incubator.apache.org>
Date: Tue, 13 Mar 2012 08:40:58 -0700
Subject: Re: Unified JS Contact object
Thread-Topic: Unified JS Contact object
Thread-Index: Ac0BL7AvXyj1fobbRB61BTch0YurUg==
Message-ID: <CB84B832.169B%fil@adobe.com>
In-Reply-To: 
 <CADjNb+=ApNY1_6VGMsxLeAnpea2_qE+xRj7iNjJi=rrO65cgFw@mail.gmail.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="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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=8A 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
>>
>>