canmove, Confirmed users
2,675
edits
WebAPI/ContactsAPI: Difference between revisions
Jump to navigation
Jump to search
→Contacts API specification: change PREF from integer to boolean, simpler, keeps vCard3 compat, specify vCard4 equivalent
(→key property: key-property id) |
(→Contacts API specification: change PREF from integer to boolean, simpler, keeps vCard3 compat, specify vCard4 equivalent) |
||
| Line 56: | Line 56: | ||
attribute DOMString[] type; // "home", "work", etc. | attribute DOMString[] type; // "home", "work", etc. | ||
attribute DOMString value; | attribute DOMString value; | ||
attribute | attribute boolean [https://bugzilla.mozilla.org/show_bug.cgi?id=860559 pref]; // false = no pref, true = preferred (vCard3 TYPE:PREF; vCard4 PREF:1) | ||
}; | }; | ||
| Line 66: | Line 66: | ||
interface <span id="ContactAddress">ContactAddress</span> { | interface <span id="ContactAddress">ContactAddress</span> { | ||
attribute DOMString[] type; // "home", "work", etc. | attribute DOMString[] type; // "home", "work", etc. | ||
attribute | attribute boolean [https://bugzilla.mozilla.org/show_bug.cgi?id=860559 pref]; // false = no pref, true = preferred (vCard3 TYPE:PREF; vCard4 PREF:1) | ||
attribute DOMString streetAddress; | attribute DOMString streetAddress; | ||
attribute DOMString locality; | attribute DOMString locality; | ||
| Line 108: | Line 108: | ||
The integer 'pref' field has been added for compatibility with both vCard3 and vCard4 use of 'pref'. | The integer 'pref' field has been added for compatibility with both vCard3 and vCard4 use of 'pref'. | ||
* | * false = no preference, same as if unspecified in vCard3 or vCard4. | ||
* | * true = preferred, same as TYPE:PREF in vCard3 and PREF:1 in vCard4 | ||
Note: despite [[hCard2]] including a flat set of adr properties into the top level h-card object for ease of publishing, this interface always abstracts those properties into a ContactAddress sub-object since typical device address books cluster address information accordingly, e.g. for a home or work address. The interface is able to represent published data. | Note: despite [[hCard2]] including a flat set of adr properties into the top level h-card object for ease of publishing, this interface always abstracts those properties into a ContactAddress sub-object since typical device address books cluster address information accordingly, e.g. for a home or work address. The interface is able to represent published data. | ||
| Line 297: | Line 295: | ||
=== Which existing address books support multiple communication types === | === Which existing address books support multiple communication types === | ||
* Which existing (shipping) address book support multiple communication types, e.g. an array of 'type' strings for tel, email, etc.? | * Which existing (shipping) address book support multiple communication types, e.g. an array of 'type' strings for tel, email, etc.? | ||
** '''Both iOS and Android ABs support types (plural) for communication properties''', as discerned by creating multiple phone numbers, and setting one of them to preferred, for each contact, and then exporting vCards, showing that the preferred phone number's type is exported as an array: "PREF,HOME" (e | ** '''Both iOS and Android ABs support types (plural) for communication properties''', as discerned by creating multiple phone numbers, and setting one of them to preferred, for each contact, and then exporting vCards, showing that the preferred phone number's type is exported as an array: "PREF,HOME" (i.e. for a preferred home number), or "WORK,FAX" (i.e. for a work fax number) | ||
** Thus at a minimum for data portability fidelity from other platforms, the ContactsAPI must support the multiple types exported(emailed,shared,etc.) by iOS and Android AB. | ** Thus at a minimum for data portability fidelity from other platforms, the ContactsAPI must support the multiple types exported(emailed,shared,etc.) by iOS and Android AB. | ||
** A new Address Book UI (e.g. Gaia) can choose to support some simplified UI (e.g. looking for PREF in particular, and then assuming just one other type). | ** A new Address Book UI (e.g. Gaia) can choose to support some simplified UI (e.g. looking for PREF in particular, and then assuming just one other type). | ||
Background: | |||
* iOS dialer implements PREF in the UI as "favorite" (displayed as a star * to the far right of the phone number) and allows more than one number to be a "favorite". However only the ''first'' such number listed is exported as a vCard tel type:pref. The other numbers' "favoriteness" is lost upon export from iPhone (email contact etc.). iOS fails to respect this "pref" type upon vCard import - thus fails roundtrip (on its own or across devices). | |||
* Android AB implements PREF as "default" (displayed as a checkmark to the right of the specific number) and allows only one number to be the "default". Android also exports this as vCard tel type:pref. Android also fails to respect this "pref" type upon vCard import - thus fails roundtrip (on its own or across devices). | |||
* Originally "favorite" for telephone number suggestion from Jonas. Which phone number of several of a contact is a "favorite" that is caller prefers to use. | |||
** interface ContactField now has | Summary: | ||
* 'type:work,fax' in vCard exports is how implementations implement a multiple type contact address out of several - thus clearly requiring that ContactField have a notion of multiple types and | |||
** thus 'type' is DOMString[]. | |||
* 'type:pref' in vCard exports is how implementations implement a preferred contact address out of several of the same type - thus clearly requiring that ContactField have a notion of 'pref'. | |||
** thus interface ContactField now has boolean pref property accordingly. | |||
== Implementation == | == Implementation == | ||