How got get Avatar pictures using contact framework?

[axeljaeger]

Hello,
I want to get those small pictures associated with contacts. I guess these are "Avatars". I am testing on a 5800XM because it is the only platform with


I know for sure that at least two of my contacts on my phone have those pictures.

I tried the following to obtain the path of the avatar:

    QContactManager manager(QString("symbian"), QMap<QString,QString>(), this);
    QList<QContactLocalId> contactIds = manager.contacts(QContactFilter());
    foreach (const QContactLocalId & id, contactIds) {
        QContact contact(manager.contact(id));
        QContactName name(contact.detail(QContactName::DefinitionName));

        //qDebug() << name.first();

        //QContactAvatar avatar(contact.detail<QContactAvatar>());
        QContactAvatar avatar(contact.detail(QContactAvatar::DefinitionName));

        QString avatar_path(avatar.avatar());
        if (!avatar_path.isEmpty()) {
            qDebug() << avatar_path;
        }
    }

Getting name works, I get all 170 names when I comment the line with the name in. But the avatar.avatar() always returns an empty string. I tried both ways, the commented and the not commented one to get the avatar path.

1. Should this work?
2. Any idea why it does not work?
3. Which one is the preferred way to access the avatar?
4. Why are there two ways to access the detail? By template and by "DefinitionName"?
5. Why is <QContactAvatar> include file missing in the package?

[MichaelGoddard]

Hello Axeljaeger,

Thanks for trying out Qt Mobility. In answer to your questions

1) It should work (* sooner or later)
2) Avatars may not have been implemented at the time of the release (unless you're compiling against git). Or there might still be a bug
3) Either way is fine - the template method is perhaps a little easier and more convenient.
4) Both are more or less equivalent - you can use the detail() function taking a string in a programmatic loop over a list of strings, or the template function if you have a specific class to use.
5) It's a bug.. I've submitted a fix for it. The headers from the src/contacts/{requests,details,filter} directories weren't being generated correctly.

Hope this helps.

Cheers,
MichaelG

[ttahola]

Hello,

Yes, like Michael said this looks like a bug in Symbian backend version you are using. Avatar image path is read successfully at least when tried with the latest QtMobility Contacts sources. I tried the following in the S60 5.0 emulator environment:

1. Create a contact and add an image for it in S60 Phonebook
2. Open Samplephonebook
3. Switch to symbian backend
4. Focus the contact created in step 1
5. Select Edit
6. The image selected for the contact in step 1 is shown on the Avatar button

Samplephonebook sources are available in path /examples/samplephonebook/ of QtMobility. The following code is used in Samplephonebook to set an image to avatar button (see contacteditor.cpp):

    QContact curr = manager->contact(m_contactId);
    ...
    QContactAvatar av = curr.detail(QContactAvatar::DefinitionName);
    ...
    if (av.pixmap().isNull()) {
        if (av.avatar().isEmpty()) {
            m_avatarBtn->setText("Add image");
        } else {
            m_avatarBtn->setIcon(QIcon(QPixmap(av.avatar())));
        }
    } else {
        m_avatarBtn->setIcon(QIcon(av.pixmap()));
    }

Symbian backend does not yet support reading contact thumbnail data with QContactAvatar::pixmap(), but it will be supported in the near future. With the latest version of symbian backend only reading image path with QContactAvatar::avatar() is supported. The related implementation can be found from \plugins\contacts\symbian\src\cnttransformanniversarysimple.cpp.

[axeljaeger]

Thank you for you reply. Is there any plans for a new release of the mobility APIs? Why do you want to have both methods in your API: Access filename or access pixmap? Isn't one enough? Your API atm is already quite huge so I appreciate if you decide on one way of doing things. What does the path return when you fetch the image over network? (Imagine a facebook backend).

[ttahola]

Why do you want to have both methods in your API: Access filename or access pixmap?

From symbian backend point of view:

Pixmap is (or will be) used to return a (possibly) scaled down version of the image; a thumbnail that is small enough so that it can be used for example in a name list view of a phonebook application without having to load a large image into memory. Thumbnail is stored into contacts database as a small resolution JPEG image.

Filename contains path to the original image. Note that the file that the filename path points to may have been removed. For example if it was on a memory card that has been removed or if the user removed the image manually (via media gallery or similar). In this case the image path points to an unexisting file, but the thumbnail image is still available and accessible via the pixmap function.

What does the path return when you fetch the image over network? (Imagine a facebook backend)

This is an interesting use case. I would expect the image path to point either to an URL containing the image (I'm not sure if this is possible with Facebook) or a local copy of the image. If the path points to a remote location, then I think at least the pixmap should contain a local copy of the image data (as a thumbnail like with symbian contacts database) for performance reasons.

[axeljaeger]

Thanks for your reply. For my submission to the Qt Mobility Contest, I had a look at the API provided by Apple that is also used on the iPhone. They only return a pointer to the pixmap data. See http://developer.apple.com/mac/libra...dressBook.html


No filename at all. In the Qt land, this means having only a QPixmap. Is there any usecase where the filename is needed? Given your argument that the path might be invalid: Is this something an application developer should ever be bothered with? I will send more detailed feedback within my submission but I want to know before the reasons for having such a huge and redundant API.

[ttahola]

Is there any usecase where the filename is needed? Given your argument that the path might be invalid: Is this something an application developer should ever be bothered with?

I know a couple such use cases (there may be more): In some symbian phones there is so called "caller image" that is shown when there is an an incoming call from a contact. The caller image may be shown full screen. This feature uses the original, full resolution image. Also, the user is able to view the original, full size image of a contact (if it is available) with a "view image" command.

From an application development point of view it is ok to use the thumbnail data and ignore the file path to the full size image. But if you need to show the full size image, then you need to be aware that it may not be available anymore and you may want to use the thumbnail data as a fallback.

br, TeroA

[axeljaeger]

Keep in mind that you are creating a cross plattform API it will be hard to explain someone using OSX and Windows only that the API is so complex because there is something on symbian...

I suggest offering a method that returns a QPixmap but gets a QSize as argument and your API decides which of the ones available on symbian is to be used. Facebook also tends to return quite large images. So ATM I'm still not convinced that two different kinds of data returned are needed.

[ttahola]

Keep in mind that you are creating a cross plattform API it will be hard to explain someone using OSX and Windows only that the API is so complex because there is something on symbian...

Good point. Creating a cross platform API means that compromises need to be done to keep the API usable. It also means that there are some platform specific requirements that need to be considered. In this case we are talking about a QtMobility API which means that we need to consider also the limits of some mobile platforms; like memory consumption and disk space usage.

If we can find a solution that serves both, then I think an API change is justified. All the options I can think would either be really hard to use or would cripple backends that need to support thumbnail size contact images.

I suggest offering a method that returns a QPixmap but gets a QSize as argument and your API decides which of the ones available on symbian is to be used. Facebook also tends to return quite large images. So ATM I'm still not convinced that two different kinds of data returned are needed.

One problem with your solution proposal is that QContactDetail derived classes (like QContactAvatar) are just data holders. So you cannot have a QContactAvatar function that would read contact image data from a contact database or from a file. At the time you have retrieved a QContact object from a contact backend, it already includes all the data related to that contact. For backends that are used in mobile environments the size of a QContact object must be kept small. The function you proposed could probably be implemented in the QContactManager API, but then it would be more complicated to use, than QContactAvatar::avatar and QContactAvatar::pixmap combination. After all, using QContactAvatar class is currently similar to using any other QContactDetail derived class. There are differences on how the fields are used in different the backends, but isn't this the case also with other detail/field combinations?

Summary of the options discussed:

1. Current situation: QContactAvatar::pixmap and SubTypeImage

• Confusing to the user since different backends may have different purpose for these

2. Leave only QContactAvatar::SubTypeImage (remove QContactAvatar::pixmap)

• if the image referred to by SubTypeImage field is removed by the user, there is no image for the contact

3. Leave only QContactAvatar::pixmap (remove SubTypeImage)

• the size of contacts database will grow significantly, since it must contain duplicates of possibly large images
• the performance of loading a contact may be really bad (with big images)

4. Replace QContactAvatar::pixmap and SubTypeImage with a function that returns a QPixmap and takes a QSize as a parameter

• the function cannot be part of QContactAvatar; where then? -> confusing to the user

[axeljaeger]

To be hones, I dont like the current implementation with the numerous QContactDetail-subclasses at all. The Contacts-API has 58 classes. That is way to much. So I would appreciate more radical changes.

While I understand the idea of that template-based-API to move resolving from runtime to linker-time, classes like QContactGender or QContactUrl show that this approach leads to nonsense-classes and increases significantly the code size.

Edit: Did you had a look at the API by Apple? Retrieving the picture of the current logged in user is as simple as:

    NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
    ABPerson *aPerson = [[ABAddressBook sharedAddressBook] me];
    NSData* imageData = [aPerson imageData];
    QImage my_image = QImage::fromData((const uchar*)[imageData bytes], [imageData length]);

Another thing is that you have three classes that point to the identity: QContact, QContactId, QContactLocalId. By merging them to one class, you save not only 2 classes but also the functions to convert between those classes.

I think you care too much about the poor performance of the current symbian devices and not enough that a contact API is not so specific to mobile plattforms . The current API design violates http://qt.nokia.com/doc/qq/qq13-apis...ticsofgoodapis <= Be minimal.

[axeljaeger]

Another point: Wouldn't it be nice if QContact was a QObject and had a slot "setName" that could be directly connected to a QLineEdit's textChanged()-signal?

[ttahola]

Hello, sorry for late response.

Edit: Did you had a look at the API by Apple? Retrieving the picture of the current logged in user is as simple as:

    NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
    ABPerson *aPerson = [[ABAddressBook sharedAddressBook] me];
    NSData* imageData = [aPerson imageData];
    QImage my_image = QImage::fromData((const uchar*)[imageData bytes], [imageData length]);

The same use case with Qt Mobility would be something like (without too much error handling):

QContactManager* cm = new QContactManager();
QContact me = cm->contact(cm->selfContactId());
QContactAvatar myAvatar = me.detail(QContactAvatar::DefinitionName);
if(avatar.subType() == QContactAvatar::SubTypeImage) {
    QPixmap myImage = QPixmap(myAvatar.avatar());
    QPixmap myPix = myAvatar.pixmap();
}

Quite simple in my opinion. I'm more used to symbian code because of my background. That may affect my opinion... I think the most difficult part is that you need to check the subtype of the avatar.

Another thing is that you have three classes that point to the identity: QContact, QContactId, QContactLocalId. By merging them to one class, you save not only 2 classes but also the functions to convert between those classes.

In my opinion the purpose of the different contact id classes is not very intuitive at first sight; note that there is also QContactGuid contact detail class. We need some method to retrieve just a list of contacts without any contact details, so we need to have both a contact and a contact id class. It would not be very effective to return a list of QContacts for example from QContactManager::contacts method. For that purpose contact id works well and I think it is also very intuitive. But would it be possible to somehow combine the contact id classes? Feel free to contribute! I hope I will have some time to think this over later on.

I think you care too much about the poor performance of the current symbian devices and not enough that a contact API is not so specific to mobile plattforms . The current API design violates http://qt.nokia.com/doc/qq/qq13-apis...ticsofgoodapis <= Be minimal.

I have understood that the philosophy behind Qt Mobility APIs is to bring functionality usually seen only on mobile devices to other, also non-mobile platforms. But of course the same APIs must still be usable in mobile devices. And my interpretation is that performance is still one of the key issues. Especially in this specific use case: Contact image is an exceptional contact detail in the sense that almost all the other contact details are just strings, dates, numbers, etc. that typically take just a few bytes of memory. A single contact image may take several mega bytes of disk space. That is why the design of the image related functionality is so important.

But again, if the avatar API can be made yet simpler without affecting the performance, I will give my vote for the required changes.

[axeljaeger]

Hello, sorry for late response.
In my opinion the purpose of the different contact id classes is not very intuitive at first sight; note that there is also QContactGuid contact detail class. We need some method to retrieve just a list of contacts without any contact details, so we need to have both a contact and a contact id class.

Can we agree on having just one Contact-ID-class and merge at least all id-classes?

It would not be very effective to return a list of QContacts for example from QContactManager::contacts method. For that purpose contact id works well and I think it is also very intuitive.

Is there a usecase for only using a number of Ids? The only thing I can think of is to return a number of matching contacts. As soon as you show a list of contacts, you have to dereference the Id to full contacts to get the name to display.

Contact image is an exceptional contact detail in the sense that almost all the other contact details are just strings, dates, numbers, etc. that typically take just a few bytes of memory. A single contact image may take several mega bytes of disk space. That is why the design of the image related functionality is so important.

Right, the contact image is a special case. But what about the classes needed as template arguments like name, QContactUrl(There is already QUrl) or QContactGender(What an absurd class)?

[axeljaeger]

Summary of the options discussed:
4. Replace QContactAvatar:ixmap and SubTypeImage with a function that returns a QPixmap and takes a QSize as a parameter[*]the function cannot be part of QContactAvatar; where then? -> confusing to the user

That is a problem of your API and if this is the best solution, you will have to fix your API.

Is there any plans for a new binary release before the contest deadline? So far I had no success retrieving the contact image on the phone. If there is no new binary release, I have to hand in a blind-programmed submission and have to state in the feedback section that nokia was not able to provide a working implementation of their API although we see a lot of green here: http://qt.nokia.com/doc/qtmobility-1...-compatability.

You may understand that I do not have a maemo6 environment for testing.

[ceefour]

That is a problem of your API and if this is the best solution, you will have to fix your API.

Is there any plans for a new binary release before the contest deadline? So far I had no success retrieving the contact image on the phone. If there is no new binary release, I have to hand in a blind-programmed submission and have to state in the feedback section that nokia was not able to provide a working implementation of their API although we see a lot of green here: http://qt.nokia.com/doc/qtmobility-1...-compatability.

You may understand that I do not have a maemo6 environment for testing.

I agree fully with axeljaeger.

At this point, my app works only in S60 Emulator. On my E71 it's unstable (crashes without message) and practically unusable. And I'm not sure why. Oh well...