[Development] QtContacts - New class QContactCollection

[Konstantin Ritt]

2015-01-27 12:41 GMT+04:00 Chris Adams <chris.adams at qinetic.com.au>:

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

I, personally, don't like this detailUri concept. In my opinion, we should
not provide such kind of info to the user's side - the only one who really
needs to know (and track) the detail's origin is a respective backend that
did the aggregation, so I'd treat detailUri as a backend's implementation
detail.


>
>
>>
>> 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
>>
>
>
Regards,
Konstantin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150127/02845510/attachment.html>