The QtM Contacts API assumes that if the engine supports the concept of a "selfcontact" it also supports deleting/removing that contact as well as letting the client decide which contact with which localId is to be the selfcontact.

But these assumption cannot be fulfilled with the qtcontacts-tracker engine. The tracker database contains a selfcontact from the very beginning, which also can/should not be deleted. And as the localId is now bound to the internal database index (for performance reasons), the localId of the selfcontact can also not be changed.

Problem:
There is no way to advertise that "limited" support for a self-contact. The API dox only defines the feature flag QContactManager::SelfContact as:
"QContactManager::SelfContact The manager supports the concept of saving a contact which represents the current user"

And so e.g. the test tst_QContactManager::selfContactId() (**) will fail for qtcontacts-tracker, as it just sees the flag QContactManager::SelfContact and assumes it can change the localId or delete the selfcontact as it likes. From the code there it seems the "maemo5" engine has the same problem.

• http://doc.qt.nokia.com/qtmobility-1.2/qcontactmanager.html#ManagerFeature-enum
  • https://www.qt.gitorious.org/qt-mobility/contacts/blobs/master/tests/auto/qcontactmanager/tst_qcontactmanager.cpp#line3051

Solution:
no backwards compatible idea yet, sorry

I also wonder if this API where the client can select the selfcontact out of the already stored contacts is perfect yet. What are the use cases for that? Accessing a shared database where the user only afterwards can tell "I am that one"? Why would the user later switch to another contact and say "Now I am this"?