Tired of boring, impersonal applications? Always wanted to integrate your friends’ details into your accounts payable application? Your boss’s home address into your circus parade routing application? Or “accidentally” remove the support phone email address for your own company from your customer’s phonebooks? Well, now¹ you can!
The Mobility project includes a component for accessing Contact information. This allows you to retrieve, create, update and delete address book information, as well as invoke actions on them (things like Send email, Dial or Invoke Voodoo). Just like QtSql, or Phonon, the Contacts component is intended to support accessing contact information from many different applications or services (at last count, we’d found over 20 candidates), including your favourite mobile phones, desktop programs and web services. The Contacts API is intended to be flexible and scalable enough to handle the wide range of capabilities of contacts engines – from SIM cards to RDF or LDAP backends. It’s (very) early days yet, but people are working hard on filling in the holes. You can probably expect some API changes before we’re done (particularly around filtering and asynchronous requests), but most of the foundations are stable.
The code is available on Gitorious. You’ll notice that right now there’s a lot of documentation and tests, and the addressbook tutorial from Qt has been modified to use this API. There are currently only a few actual backend engines – don’t worry, those will come along soon. You can easily add support for a new contacts engine via a plugin, so we’re expecting that not every plugin will make its way into our repository – but we’ll certainly try to accept any contributions². We have an initial rough implementation of a KDE 4.2 (libkabc 4.2) engine for validating the design, and an in-memory “reference” engine. Engines for Symbian, Windows Mobile and other platforms will appear over time as well.
Feel free to send any feedback to qtmobility at trolltech.com – or code contributions via Gitorious.
¹ For values of now that are equal to soon 
² Code, docs, feedback, or voodoo pins (we’re running low).
Possibly related posts:
6 comments
I am not seeing where this is going…
I was hoping QtMobility was, according to last descrition, give us some kind of services bridge that could look like SOAP, DBUS, or RPC. That we’d have some QObject proxy to communicate with whatever service provider we were working with.
It would seem that you’ve created such a module, and just added a contact object proxy?
I think your messages aren’t technical enough to be hitting the audience here. I just don’t understand the value of this, or where it is going, or, more importantly, what I can use it for. :-/ I feel the messaging is sales-pitchy, and not targeting your audience of software developers.
I was going to hold off on those comments, but being this is the 2nd such most of QtMobility that I don’t understand, I wonder if other people aren’t in a similar situation. Zack had a similar hard-to follow prose, but he always explained his technical approach.
Ok, so maybe I spoke too harshly. I went over the QtMobility posts again, and it makes a little more sense. The problem is it is scant on the implementation details. There is one chart, which isn’t exactly clear.
However, I would hope that it gets revealed just how this operates. Like is it SOAP over HTTP, RPC, or something completely proprietary? I have need for a SOAP 1.2 HTTP interface. And in fact if Qt supports the open service protocols, we’d have something very useful! Qt would be able to provide and consume web services. Which would be huge!
Scorp, for SOAP you should check out the SOAP module in the catalog at http://www.qtsoftware.com/products/appdev/add-on-products/catalog/4/Utilities/qtsoap/
It might fit your needs or might with a bit of adaptation. I have it in my queue to try out but haven’t processed my queue enough to get to it.
Thanks Baldy, but that only supports SOAP 1.1, and client only. And doesn’t use WSDL files. The Mobility framework should be able to consume a WSDL. But more importantly, it should be transport agnositc, and/or be interoperable with the wider world, so Qt apps don’t need Qt servers.
Hej,
the API looks like every call (loading contacts, saving etc.) should be a synchronous call.
This might cause problems when implementing plugins that communicate in an asynchronous way
with their backend (e.g. groupware server). Any ideas how to solve such issues?
For the Akonadi plugin we could make synchronous calls, however that involves using local
event loops which triggers problems when nested inside another event loop.
Ciao,
Tobias
@Tobias – yes, the current interface is solely synchronous. There’s the beginnings of an asynchronous API in the proposals directory. The event loop problem might indeed get a bit tricky – I’d hate to have to partition plugins into one or the other style of interface, but it might be necessary. Most mobile devices seem to have a synchronous API, for one reason or another.
Comments on this entry are closed.