ZF-3369: Google Contacts API support


This is more of a heads-up than a request.

I'm currently working on some code to work with the new Zend Contacts API for managing things like Gmail contacts. I anticipate having something in an alpha peer-review state sometime this week.

I'm starting this issue so I'll have somewhere to post the code and to "stake out" the area to avoid having multiple people unknowingly working on the same task.

Stuff that currently works: * Listing contacts * Emails * Phone data & subtype (mobile, pager, fax) information * IM data * Organization data * Label/categorization for data types * Altering primary e-mail * Notes about the current user


I signed the indivdual CLA before, but this one is something on company time so as soon as I get a Corporate CLA done I'll post what I have. Current classes:

Contacts/Extension/Categorized.php (abstract superclass) Contacts/Extension/Email.php Contacts/Extension/Im.php Contacts/Extension/Name.php Contacts/Extension/Notes.php Contacts/Extension/Organization.php Contacts/Extension/OrgName.php Contacts/Extension/OrgTitle.php Contacts/Extension/PhoneNumber.php Contacts/Extension/PostalAddress.php Contacts/ListEntry.php Contacts/ListFeed.php

Very cool Darien, sounds like a fantastic start! I'd like to help in some way if you're interested. Unit tests, sample application, etc. Are there any data model classes that you need? I have some code for Contacts/Extension/GroupMembershipInfo.php and Deleted.php if you are interested.

Thanks, I'm currently waiting on The Powers That Be to authorize me sending CLA application. Once I can post actual code things should be clearer.

I'm afraid my development model has been fairly haphazard, partially because this is my first time delving into the Gdata component works internally. So I don't have any unit tests. (How do you unit test against a monolithic external service anyway?) Right now the general structure is similar to the Calendar/ListEntry.php class.

Stuff I don't plan to implement any time soon: * Photos * Bulk updates (a broader issue than just Contacts) * Group or Membership data and queries

Misc concerns: * The existing extendedProperty handler (Zend_Gdata_Extension_ExtendedProperty) only appears to support attribute-based data storage. By contrast, this documentation page suggests it needs to have a switch for XML-blobs:…

What the test contact looks like in GMail...

...Shows a GMail contact as retrieved and displayed by PHP code.

The [1] designates the primary e-mail. "

MyCat" is a custom category for information, parallel to "Work" and "Personal".

Phone numbers may have a subtype like "Fax".

For organizations, the title is in square brackets.

Okay, so those last two screenshots are at least proof-of-concept. (Yes, the custom output is ugly, but it was easier when writing a bunch of throwaway echo statements.)

More musings and API uncertainties: * Can you have multiple "Fax" or "Mobile" phone numbers for a single category for a single contact? Right now there's no clientside code for checking that kind of situation. * It seems you can make a custom category called "work" that parallels the built-in "work" category. Is this a bug? How can we distinguish between them? The current implementation just assumes such name collision is not possible. * I haven't tested any sort of "advanced searching" or listing--just pulling back a small but complete list of test contacts.

In answer to your three questions: - yes, it is possible to have multiple phone numbers with rel set to fax ( - when you say that you are making a custom category, do you mean that you are adding an Atom category element to the entry, or did you mean you are using a different rel value on a phoneNumber element (for example)? - the query capabilities for the API are listed here:… . The items in the first box should already be included inf you inherit from the Gdata query class, the second set will require some new code. Please let me know if the descriptions in the documentation aren't clear.

If you have any questions, please ask :)

Thanks for your reply. I'm still bugging the appropriate folks for official permission to contribute the code.

What I had meant about categories is what you can do with Gmail: You start with "Work", "Personal" and "Other".

You can make custom categories like "Secret Identity" to hold a similar corresponding set of postal/im/email/phone data.

However, it seems you can also make custom categories which (from just looking at the XML) are indistinguishable from the built-in ones.

Improvements: * Added features to set the "primary" flag among sets of phone, IM, email, and postal values. (AFAIK the "primary e-mail" scope includes all email items in all categories, not just "Primary for Home" and "Primary For Work", etc.) * Listing categories in use for an entry (Home, Work, Personal, Foo) * Retrieving data objects by category label * Contacts-API-specific query options mostly coded

Huzzah! Apparently a confluence of deadlines (some ending, some starting) have resulted in activity.

I anticipate having legally-postable svn diffs shortly. Hopefully in time for the 1.6 feature freeze. Mind you, my prior "anticipation" was misleading, but literally correct :)

Is there any particular branch or tag I should diff against? I'm currently working off of 1.5.2, although it shouldn't matter very much since most of the files are new.

Hi Darien,

I appreciate all your hard work to get contacts support in. However, I don't know if we're going to have time to get this in before midnight tonight for the 1.6 feature freeze. I believe all code reviews/testing/docs/etc need to be complete by tonight. Given that ZF strives to maintain backwards compatibility, I don't think we really want to rush through this process.

Perhaps we should work on getting this checked into trunk later this week and then push forward to having it included in the 1.7 release (which Wil promises will come shortly after 1.6).

We can then post info in the Google Group for Contacts and get people to test it out before the release?

Cheers, -Ryan

Ah, so it's more than just a freeze on feature scope, then. Darn.

Regarding backwards-compatibility...

The only changes that are not entirely new files are convenience functions which can be moved elsewhere. I could submit a changeset which shouldn't affect anybody who isn't specifically trying the new API.

Hi Darien,

Yea, I'd love to get this in ASAP, but I want to make sure it's done right. The note from Wil: "Just a reminder that the feature-complete (that means all code, unit tests, and documentation) deadline for all contributions targeted for the 1.6 release is 6/30. "

Re backwards-compat: What I was referring to was that if we rush to get the contacts support added in the next couple hours, we could miss something in Contacts that we'd want to change, and end up regretting not being able to change it in the future :)

I'd love to get your code in.. I'm super excited that you're contributing it, but I just don't want to rush it the night of the freeze.

Can we work to get this reviewed this week, committed in trunk and then give the Google Group for contacts a chance to test it out before the 1.7 freeze?

Cheers, -Ryan

Sure, I have no particular objection to delaying it until 1.7, I just misunderstood the scope of the freeze.

On a unrelated note, I've been toying with is a Gdata adapter for Zend_Auth, but I'm running into some ambiguities since usernames are not necessarily unique due to context (service used, real gmail vs hosted corporate, etc.)

The Not-Yet-Ready-For-Real-Review proposal is now up in the wiki...…

I'll focus on adding more skeleton examples while waiting for the corporate gears to grind.

Hi Darien,

Great - thanks for the proposal! We'll happily review it. As this is not a new component, but rather just some new classes for an existing component (Zend_Gdata), I don't believe it really needs a formalized proposal.

Good luck with the "corporate gears."

Cheers, -Ryan

Thanks for your great work on this Darien. I might need to get this implemented before Darien gets throught he legal gears, could anyone give me a hand on how to do this manually? I'd be fine if I could just extract the raw data from google, but not sure how to do it. Ideally actually I'd just like to get it in JSON.

Here is what I'm doing: $contact = new Zend_Gdata($client); $query = new Zend_Gdata_Query( '…'); $query->setMaxResults(2000); $feed = $contact->getFeed($query);

foreach ($feed as $entry) {
    print 'Title: ' . $entry->title->text;

I do get the names of the contacts out, but don't know how to get the other data I need (which is just phone number and email address).

Thanks for any help!



This should get you the JSON version of the feed you're looking for...


require_once 'Zend/Gdata/ClientLogin.php'; require_once 'Zend/Gdata.php';

$client = Zend_Gdata_ClientLogin::getHttpClient('email address', 'password', 'cp'); $gd = new Zend_Gdata($client);

$response = $gd->get('…'); echo $response->getBody();

Here's some code that ought to work:

foreach($feed as $entry){


"); $parts = $entry->getExtensionElements(); foreach($parts as $p){ $element = $p->getDOM(); switch($element->tagName){ case 'email': print("Email: ".$element->getAttribute('address')."
"); break; case 'phoneNumber': print("Phone: ".$element->nodeValue."
"); break; default: continue; } } }

P.S.: If you want information about categories, e.g. "Work", "Personal", or phone-number subtypes such as "mobile" and "fax", I have a little rant about how that's painful:…#

Thanks guys for the very fast response - worked out well.



Pfhew. Waiting for Zend response to the corporate CLA.

Still waiting... But what's the procedure here, just toss up a zip of sources and someone else commits it to the right place in SVN?

Hey Darien, The preferred way is to upload a patch in unified diff format created by running 'svn diff'.

Once that's done, the community will have a chance to review the patch and provide feedback. Once everybody's happy with it, I can go ahead and check the code into SVN for you.

Thanks for all of your hard work on this. :)

As diffed against the 1.5.3 release tag.

Only minor changes on existing code, otherwise new files.

Okay, there it is.

Caveats: I have not recently re-tested it. Google may have changed their API. In fact, I'm pretty sure the category stuff ("Work","Personal") is broken, or at the least a bit iffy.

Google might have cleaned up that aspect of their API, but last I checked that particular categorization feature was iffy.

Note to self: Proof-read more next time.

The following Google tickets/issues are probably germane:……

It seems some of the docs may have been updated with more about possible 'rel' attribute values:

Turns out the patch I posted is already broken (broken assertion) when it encounters rel=""

Due to unexpected developments I will not be able to proactively develop this feature at this time, so I'm changing it to unassigned. I will however try to keep watching the issue and helping as time permits.

No worries Darren, I can help finish it up. Speaking of which, I'm hoping to finish going through the patch within the next week.

Err, Darien. Sorry about that. :)

Increasing priority to major.

Are there any updates on progress with this? As Google has added domain-wide contacts, this is of much more use to me now. The patch above seems to work to an extent but there is now version 3 of the Google Contacts API which has new, more structured types.

I'd be glad to work with someone to get this Gdata addition working correctly.

Sorry, there hasn't been much work on this since my last update.

The core code exists, but I still need to sit down and write tests, sample code, and documentation. Especially tests.

Does it exist somewhere where I can use it as-is? It doesn't have to be perfect, I don't really need docs as I've been going through the API over the last few days pretty intensively.

Nope. If it takes much longer, I might check it into the incubator, but for now there's no public copy.

Has there been any thoughts during the past fourteen months? I would love to see Google Contacts within ZF.

Second Ingmar's request. An update on support for Google Contacts seems way overdue.