incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Unified JS Contact object
Date Tue, 13 Mar 2012 16:01:29 GMT
I say for now we go with what's in the docs: no return value (or no
promises on the return value).

On 3/13/12 8:40 AM, "Filip Maj" <fil@adobe.com> 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" <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
>>>
>>>
>


Mime
View raw message