canmove, Confirmed users
2,887
edits
WebAPI/ContactsAPI: Difference between revisions
Jump to navigation
Jump to search
simplify ContactEmail and ContactTelephone interfaces to common ContactField (similar but simpler than W3C), use ContactField on impp & url for more consistency, future consideration / feature request
(→Priority 6 feature requests: export a vcf with carrier if you have such a device) |
(simplify ContactEmail and ContactTelephone interfaces to common ContactField (similar but simpler than W3C), use ContactField on impp & url for more consistency, future consideration / feature request) |
||
| Line 47: | Line 47: | ||
The following Contact interface is based [[vCard4]]/hCard properties, flattened for the simple/typical case of one address (adr) based on the [http://microformats.org/wiki/microformats-2#h-card microformats 2.0 hCard] iteration. | The following Contact interface is based [[vCard4]]/hCard properties, flattened for the simple/typical case of one address (adr) based on the [http://microformats.org/wiki/microformats-2#h-card microformats 2.0 hCard] iteration. | ||
interface | interface ContactField : nsISupports | ||
{ | { | ||
attribute DOMString[] type; // for primary/favorite (use:"PREF"), "home", "work", etc. | attribute DOMString[] type; // for primary/favorite (use:"PREF"), "home", "work", etc. | ||
| Line 76: | Line 70: | ||
attribute DOMString[] honorificSuffix; | attribute DOMString[] honorificSuffix; | ||
attribute DOMString[] nickname; | attribute DOMString[] nickname; | ||
attribute | attribute ContactField[] email; | ||
attribute DOMString[] photo; | attribute DOMString[] photo; | ||
attribute | attribute ContactField[] url; | ||
attribute DOMString[] category; | attribute DOMString[] category; | ||
attribute ContactAddress[] adr; | attribute ContactAddress[] adr; | ||
attribute | attribute ContactField[] tel; | ||
attribute DOMString[] org; | attribute DOMString[] org; | ||
attribute DOMString[] jobTitle; /* 'title' from vCard made specific */ | attribute DOMString[] jobTitle; /* 'title' from vCard made specific */ | ||
attribute Date bday; | attribute Date bday; | ||
attribute DOMString[] note; | attribute DOMString[] note; | ||
attribute | attribute ContactField[] impp; /* per RFC 4770, included in vCard4 */ | ||
attribute Date anniversary; /* new in vCard4 */ | attribute Date anniversary; /* new in vCard4 */ | ||
attribute DOMString sex; /* new in vCard4, gender sub-component 1 */ | attribute DOMString sex; /* new in vCard4, gender sub-component 1 */ | ||
| Line 153: | Line 147: | ||
=== Priority 1 feature requests === | === Priority 1 feature requests === | ||
Gaia Contacts App UI [[Gaia/Contacts#Gaia_v1|v1 feature requirements]] will gestate here and then migrate into the interface description above. | Gaia Contacts App UI [[Gaia/Contacts#Gaia_v1|v1 feature requirements]] will gestate here and then migrate into the interface description above. | ||
=== Priority 2 feature requests === | === Priority 2 feature requests === | ||
| Line 176: | Line 166: | ||
=== Priority 4 feature requests === | === Priority 4 feature requests === | ||
Features requested by one or more individuals which are already present in the vCard4 spec, and likely implemented by by one or more implementations (but not interoperably). | Features requested by one or more individuals which are already present in the vCard4 spec, and likely implemented by by one or more implementations (but not interoperably). | ||
* 'sort-string' / 'sort-as'. per suggestion from Jonas, the Japanese iPhone has a field for "phonetic last name" which can be used for sorting. The existing vCard3 sort-string property or vCard4 sort-as (sub)property could be used to capture this if the only intended use is sorting. | * 'sort-string' / 'sort-as'. per suggestion from Jonas, the Japanese iPhone has a field for "phonetic last name" which can be used for sorting. The existing vCard3 sort-string property or vCard4 sort-as (sub)property could be used to capture this if the only intended use is sorting. | ||
* 'related' - human relationships (MOAB) | * 'related' - human relationships (MOAB) | ||
| Line 188: | Line 177: | ||
* vCard4 extensions | * vCard4 extensions | ||
=== Priority 5 feature requests === | === Priority 5 feature requests === | ||
| Line 223: | Line 207: | ||
** ''allergies'' are things a person should or MUST not eat because they cause distress, illness, and potentially death. | ** ''allergies'' are things a person should or MUST not eat because they cause distress, illness, and potentially death. | ||
ContactField properties: | |||
* '''category''' - suggestion from Jonas. The field would be an array of strings. That way we can add "favorite" to the category array to favorite a phone number, and we could add "operator:Telephonica" to indicate a particular operator. | * '''category''' - suggestion from Jonas. The field would be an array of strings. That way we can add "favorite" to the category array to favorite a phone number, and we could add "operator:Telephonica" to indicate a particular operator. | ||
** | ** ContactField already has a 'type' DOMString[], and 'PREF' is already used as *a* type value by other implementations (Android AB, iOS AB) to indicate "favorite" phone number of a contact. | ||
* <span id="tel-carrier">'''carrier'''</span> per request from Telefonica. Recommendation: postpone til after v1. Outstanding questions: | * <span id="tel-carrier">'''carrier'''</span> per request from Telefonica. Recommendation: postpone til after v1. Outstanding questions: | ||
** What problem is it solving? | ** What problem is it solving? | ||
| Line 280: | Line 264: | ||
** 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). | ||
More details: | |||
* Summary: 'type:pref' for ContactField is how implementations implement a preferred contact address out of several of the same type - thus clearly requiring that ContactField 'type' be DOMString[]. | |||
** iOS dialer implements this 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 this 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 DOMString[] type accordingly. | |||
== Issues == | == Issues == | ||