incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Becky Gibson <gibson.be...@gmail.com>
Subject Re: Unified JS Contact object
Date Tue, 13 Mar 2012 13:47:09 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message