[Development] QtContacts - New class QContactCollection

[Chris Adams]

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.

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.

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.

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).

Cheers,
Chris.


www.qinetic.com.au - Qt And QML User Experience Specialists

On Tue, Jan 20, 2015 at 7:23 AM, Renato Araujo <renatox at gmail.com> wrote:

> For what I understand every detail already have such functionality
> [QContact.detailUri] with this field you can specify from which contact
> this detail belongs, based on QContact.Guid;
>
> Is correct to say that a contact which the type is "TypeGroup" is a meta
> contact with information from different contacts (A merged contact)?
>
>
>
>
>
>
>
>
> Renato Araujo Oliveira Filho
>
> On Mon, Jan 19, 2015 at 6:12 PM, Konstantin Ritt <ritt.ks at gmail.com>
> wrote:
>
>> IMO, such a merged contact should belong to a special "address book" -
>> one that aggregates contacts and knows which field/detail came from this or
>> that real contact.
>>
>> Regards,
>> Konstantin
>>
>> 2015-01-20 0:27 GMT+04:00 Renato Araujo <renatox at gmail.com>:
>>
>>> Hey guys,
>>>
>>> I started to implement the class QContactCollection based on
>>> QOrganizeCollection[1]. Until now I just copy the code from QOrganizer
>>> module and renamed some classes.
>>>
>>> The idea of QContactCollection is to represent an "address-book". And
>>> with this we can create/remove/modify collection and query contacts based
>>> on the collection id.
>>>
>>> This looks great, but I have one concern about that. How to represent
>>> contacts that are present in more than one "Address book" (merged
>>> contacts)? In this case the contact can have more than one collection.
>>>
>>> Do you have any idea how to solve that?
>>>
>>> Should we use a different approach?
>>>
>>> What about use QContactCollectionId as a derived class from
>>> QContactDetails?
>>>
>>>
>>> [1] https://codereview.qt-project.org/#/c/104026/
>>>
>>>
>>> Thanks
>>>  Renato Araujo Oliveira Filho
>>>
>>> _______________________________________________
>>> Development mailing list
>>> Development at qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/development
>>>
>>>
>>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150120/dfdd514f/attachment.html>