You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Becky Gibson <gi...@gmail.com> on 2012/03/12 18:22:45 UTC
Unified JS Contact object
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
Re: Unified JS Contact object
Posted by Paul Plaquette <pa...@linux.intel.com>.
On 07/04/2012 10:55, Filip Maj wrote:
>
>> 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?
the parameter passed into the 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Š 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"<gi...@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<fi...@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"<gi...@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
>>>>>
>>>>>
>>>
>>>
>>
>> --
>> Paul Plaquette
>> Senior Software Engineer
>> Open Source Technology Center
>> Intel Corp.,Montpellier, France
>
>
--
Paul Plaquette
Senior Software Engineer
Open Source Technology Center
Intel Corp.,Montpellier, France
Re: Unified JS Contact object
Posted by Filip Maj <fi...@adobe.com>.
>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Š 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"<gi...@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<fi...@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"<gi...@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
>>>>
>>>>
>>
>>
>
>--
>Paul Plaquette
>Senior Software Engineer
>Open Source Technology Center
>Intel Corp.,Montpellier, France
Re: Unified JS Contact object
Posted by Paul Plaquette <pa...@linux.intel.com>.
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.
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Š 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"<gi...@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<fi...@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"<gi...@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
>>>
>>>
>
>
--
Paul Plaquette
Senior Software Engineer
Open Source Technology Center
Intel Corp.,Montpellier, France
Re: Unified JS Contact object
Posted by Filip Maj <fi...@adobe.com>.
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" <fi...@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" <gi...@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 <fi...@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" <gi...@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
>>>
>>>
>
Re: Unified JS Contact object
Posted by Filip Maj <fi...@adobe.com>.
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" <gi...@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 <fi...@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" <gi...@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
>>
>>
Re: Unified JS Contact object
Posted by Becky Gibson <gi...@gmail.com>.
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 <fi...@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" <gi...@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
>
>
Re: Unified JS Contact object
Posted by Filip Maj <fi...@adobe.com>.
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" <gi...@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