@rfc2822 said in RELATED TYPEs mappings not 1:1:
The values which are available in Android are not identical to those defined in VCard.
Data transfer between the VCard data class
Contact and the Android Contacts provider is done in
AndroidContact, so you can also find the mappings there (
populateRelation: Android → data object;
insertRelation: data object → Android).
So, we have 14 types in Android:
TYPE_ASSISTANT, TYPE_BROTHER, TYPE_CHILD, TYPE_DOMESTIC_PARTNER, TYPE_FATHER, TYPE_FRIEND, TYPE_MANAGER, TYPE_MOTHER, TYPE_PARENT, TYPE_PARTNER, TYPE_REFERRED_BY, TYPE_RELATIVE, TYPE_SISTER, TYPE_SPOUSE. Of these,
TYPE_REFERRED_BY is currently the only one not dealt with by
We have 20 types in vCard:
contact, acquaintance, friend, met, co-worker, colleague, co-resident, neighbor, child, parent, sibling, spouse, kin, muse, crush, date, sweetheart, me, agent, emergency. Of these, 9, namely
child, co-resident, crush, date, spouse, sweetheart, friend, kin, parent are dealt with by
insertRelation. Meaning: see http://gmpg.org/xfn/11
The 5 clear 1:1 type correspondences I see are:
( TYPE_RELATIVE, kin),
(TYPE_SPOUSE, spouse). Of these
(TYPE_SPOUSE, spouse) is currently not dealt with correctly, and should therefore be an uncontroversial fix.
For all the other types, I don’t think trying to make one-way correspondences is a good idea, as this will lead to data loss (e.g., spouse -> TYPE_PARTNER -> sweetheart). I think the only reasonable approach is to use the label option for those (both Android and vCard have this option), which breaks localization, but does allow full 1:1 correspondences in both directions.
Convincing Google and the VCARDDAV people to harmonize is the next step…
Where do you know from that “partner” refers to business partners? The documentation is not very meaningful, so we had to play puzzle to guess which Android values have the same or a similar meaning as their VCard counterparts.
I thought it was, but I am now not at all sure any more about that.