[Development] QtContacts - New class QContactCollection

[Chris Adams]

Hi Renato,

On Sat, Jan 24, 2015 at 5:51 AM, Renato Araujo <renatox at gmail.com> wrote:

> Hi Cris,
>
>
>
> On Mon, Jan 19, 2015 at 10:17 PM, Chris Adams <chris.adams at qinetic.com.au>
> wrote:
>
>> QContactType::TypeGroup is meant to represent a group of entities with
>> shared contact details (eg, a local football club might have a mailing-list
>> email address, a clubhouse phone number, etc).  Individual contacts can
>> have membership in groups (so various friends can be members of the
>> football club group).  I don't think that overloading TypeGroup with
>> aggregation semantics is a great idea, personally.
>>
>
> Thanks for the clarification. I was confuse about the
> QContactType::TypeGroup type, but now I understand how this should be
> implemented.
>
>
>
>>
>> We had a discussion a while ago (I cannot remember where, and a quick
>> grep through QTBUG-31824 failed me) about adding a new
>> QContactType::TypeFacet (to match stdlib nomenclature) or
>> QContactType::TypeConstituent where contacts of those types represent
>> "service- or sync-endpoint-specific contact instances which are aggregated
>> into a 'full' contact".  The "full" contact would be a
>> QContactType::TypeContact contact, and it would have
>> QContactRelationship::Aggregates relationships with the Facet/Constituent
>> contacts.
>>
>
> As Matthew mentioned this was already integrated to the mainline.
>
> About the relationships, what I understand now is that (please correct me
> if I am wrong):  the Main Contact should contain all the details from other
> contacts, and if I want to have more information (let say that I want to
> know where these details came from), I can use "QContact::relationships()"
> method it will return a list of relationships where I can find the id of
> the others contacts, but these contacts will be of the type
> "QContactType::TypeFacet".
>

Correct - the Aggregates relationships will tell you which Facet contacts
are aggregated by the main Contact.

Note that the details themselves have a detailUri field - this is currently
a freeform field, but can be composed of a contactId and a detailId.  So,
the details in the main/aggregate contact can "point back" to the specific
contact and detail from which they originally came.


>
> But lets say that I have two normal contacts one from my "local" address
> book and another from my google "address-book" (both contacts contains
> (phone number, email, address, etc) and I want to merge both contacts. Is
> this case should I change the google contact to TypeFacet and merge all
> details into the local contact?
>

I guess it depends on what you mean by "merge".

If you want to retain the information about their provenance, and merely
provide a single unified contact for presentation to users, then I would
simply ensure that every contact from an original data source (eg, a sync
source, or entry by the user via UI) is stored as a Facet contact, and that
every Facet contact is linked to exactly one main Contact.  In this case, a
phonebook style application would only ever show full Contact contacts, not
Facet contacts (as that would result in duplicates with partial data being
shown).  This style of "merge" is really just "linkage", and allows you to
store data from every source separately, maintaining provenance for every
detail.  This is what we did in nemomobile qtcontacts-sqlite.  (E.G., the
google-addressbook-contact is a Facet, and the local-addressbook-contact is
a Facet, and they are both linked to a Main Contact which aggregates their
details).

The other alternative, which you describe, is more destructive, so I
personally prefer the previous alternative over an actual merge operation -
but in some cases this is preferable (eg, if syncing from another device
via Bluetooth, for example).


>
>
>
>>
>> Then it comes back to what Konstantin suggests: each Facet/Constituent
>> belongs to the particular addressbook (eg, the OwnCloud addressbook, the
>> Fruux addressbook etc) and the Aggregate/Full contact belongs to the
>> FullContacts addressbook.  If the user edits the contact on the device, you
>> generate a "local" Facet/Constituent which is also linked into the
>> aggregate.  The aggregate can be regenerated on every write, or on every
>> read, depending on the desired performance characteristics for the device /
>> which trade-offs are preferred.
>>
>
> In fact this this looks like a good solution, and If I want, I can use the
> "QContactCollection:extendedMetaData()" method to retrieve a list of
> collections aggregate on this contact
>

If I understand you correctly, are you saying that you could store the ids
of all collections which contain any Facet contact which is aggregated by a
Contact in the Main/FullContacts collection, in extendedMetaData() fields
of the Main/FullContacts collection?  I guess you could, yes.  Out of
interest, why is this useful?  Generally, I think that would only be useful
on a per-contact basis (eg, so you can show that a given Contact
contains/aggregates data from some specific set of Facet contacts, eg,
Google, OwnCloud, etc) but perhaps I'm missing something?


>
>
>
>>
>> Note that this is the way we do it in nemomobile's qtcontacts-sqlite
>> engine, however we use rather artificial separations based on synctarget
>> (string) filtering, rather than Addressbook collections (we'd definitely
>> prefer Addressbook collections, going forward).
>>
>
> I went forward with the implementation, and I have already a MR[1] ready
> for review. Please take a look when you have time:
>
>
> [1] https://codereview.qt-project.org/#/c/104026/
>

Fantastic, thanks very much.  I haven't had a chance to review it yet, but
Matt and I will take a look sometime this week.

Kind regards,
Chris.



>
> Thanks
> Renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150127/292106a9/attachment.html>