feed is a GDataFeed object which can easily be iterated over, like so:

for entry in feed.entry:
    print entry.title.text


To be honest, I’m not sure if the scopes are necessary but I included them for the sake of completeness. Setting oauth_input_params for the oAuth token is essential and something that took me a while to figure out – I had assumed that setting the parameters for the Gdata service would be enough.

I am directly assigning the access token to the Gdata service. I had originally tried to use the setter – gdata_service.SetOAuthToken(access_token) – but had problems and switched to direct assignment. However, my problem could very well have been somewhere else, so feel free to try using the method.

Finally, you may have noticed that I’m querying the Analytics Data API. I hope to have more to announce about that soon. In the meantime, I’ll note that gdata-python-client doesn’t have specific Analytics support, which is why I’m using the generic Gdata service.

While App Engine has a very nice login system that hooks seamlessly into Google Accounts, gaining access to the user’s data via one of the Gdata feeds requires an additional authorization (you would use oAuth of course). However, Google has also introduced a federated login method whereby you can send the user to one screen where they both login and approve your access via oAuth to their data. So, I gave up development speed in favor of something that is hopefully simpler for my users. If you want to know more, Joseph Smarr of Plaxo has a good writeup of how the hybrid OpenID + oAuth combination came about.

After many frustrating attempts trying to get any of the many Django OpenID apps to work, all of which seemed to go haywire when touching App Engine (even if they claimed support), I found the google-app-engine-django-openid app. It’s quite simplistic – it doesn’t seem to connect to Django’s auth system at all – but, most importantly, it worked right out of the box on my App Engine install. Thanks, Wesley! Since I am requiring all users to login via a Google account, I simply skipped the first step in google-app-engine-django-openid’s login process, having the user enter their OpenID URL, and went to the next step, endpoint discovery. Beyond that all I had to do was add the additional oAuth parameters to my OpenID request and, on the return, upgrade the signed request token to an access token. gdata-python-client provides all the oAuth mechanisms you need as part of its authorization suite.

Of course, getting an access token was easier said than done, due the gdata library’s oAuth module being designed with the normal oAuth authorization flow in mind. To start using it much later in the oAuth process required me to initialize a bunch of things I wouldn’t have otherwise needed to handle. In the interest in saving people time, here’s the final code:

signed_request_token = gdata.auth.OAuthToken(key=args['openid.ext2.request_token'], secret="")
gdata_service = gdata.service.GDataService()
gdata.alt.appengine.run_on_appengine(gdata_service)
gdata_service.SetOAuthInputParameters(gdata.auth.OAuthSignatureMethod.HMAC_SHA1, settings.GOOGLE_CONSUMER_KEY, settings.GOOGLE_CONSUMER_SECRET)
access_token = gdata_service.UpgradeToOAuthAccessToken(signed_request_token)
person.accessToken = str(access_token)

It’s not a lot of code, really, but it took a lot of poking through the gdata code to figure it all out! Note that the access token returned by UpgradeToOAuthAccessToken() is not a string but can easily be converted to and from a string for storage.

When using parts of the gdata-python-client library, always make sure to set the http transport to App Engine’s urllib: gdata.service.http_request_handler = gdata.urlfetch. In general, if you’re getting any sort of weird error from something that uses a network connection, it’s probably because you’re not using Google’s URL fetch service.

In additional, one key thing I learned is that, while you don’t get a secret back with your signed request token, you must pass along an empty string for the secret when calling gdata.service.GDataService.UpgradeToOAuthAccessToken. None or False will cause errors in gdata’s oAuth library.

Finally, testing. Because Google requires your realm to match your domain for the oAuth request, I couldn’t test the authentication and authorization process on my local machine running the App Engine SDK behind a router. Instead, I just keep pushed changes to my live install on App Engine. I’m sure there’s a better solution, most likely running the SDK on a machine with a public address and getting an oAuth consumer key from Google tied to that address. Also, I didn’t use it but the oAuth Playground looks like a good place to test your oAuth interaction with Gdata services.

1. Install the SDK

   Simply download the SDK and install it. On Mac OS X that meant that I mounted the disk image, dragged the SDK app to my applications directory, and launched it. Make sure to give the app the necessary permission to create symlinks.

2. Get the latest version of google-app-engine-django

   Use SVN to export the latest version of google-app-engine-django: svn export http://google-app-engine-django.googlecode.com/svn/trunk/ your-app-dir

3. Get the latest stable version of Django

   Download from http://www.djangoproject.com/download/. Decompress it.

4. Zip up Django

   Google Apps currently uses version 0.96 of Django and they do not plan to switch in the near future. Thus, you need to put a django.zip file in your App Engine app directory, your-app-dir. You create the file by, from the Terminal, going to the directory of the new version of Django you downloaded and typing:

   1. zip -r django.zip django/__init__.py django/bin django/core django/db django/dispatch django/forms django/http django/middleware django/shortcuts django/template django/templatetags django/test django/utils django/views
   2. zip -r django.zip django/conf -x 'django/conf/locale/*'
   3. zip -r django.zip django/contrib/__init__.py django/contrib/formtools django/contrib/auth django/contrib/sessions

      Note there is an oversight in the App Engine article about zipping Django 1.0; the last two directories are necessary.

5. Edit settings

   Open app.yaml in your App Engine app directory and change the application name on line 1 to the name of your application. Then, open settings.py and uncomment line 83 so that django.contrib.sessions.middleware.SessionMiddleware is included.

6. Launch the default app

   From your App Engine app directory, launch the server: python manage.py runserver. If everything went correctly you should see the server mention using zipimporter and then announce that your app is running at http://localhost:8000. Open the URL and your should see a simple welcome message.

7. Build your app!

   Now you can get started building a Django app on App Engine. Make sure to read the article on using the Django App Engine helper to see how to start building your app.

May 19-21 is Where 2.0

May 27-28 is Google I/O

June 8-12 is WWDC

All nice events and ones that are relevant to the work I’m doing but not cheap… Will you be at any of these conferences?

With the ability of HTML5 web apps to store data locally and have the browser pass along the device’s hardware states, I believe that HTML5 wbe apps can do almost anything you could want an internet-using application to do. The only exception I can think of is high performance 3D graphics, as even great 2D graphics are possible with CSS3 and HTML5′s canvas tag. Already there are nice libraries like RaphaëlJS that work in the iPhone’s Mobile Safari.

• Public911.com plots 911 calls in Seattle as they happen.
• Alarmeringen.nl shows emergency calls throughout the Netherlands.
• Misdaadkaart.nl shows reported crimes throughout the Netherlands.
• Live Piracy Map shows acts of piracy throughout the world.

Not in real time but along the same lines (and admittedly quite controversial), there have been several maps made of membership in the far-right BNP in the UK in the last day as the party’s membership list was leaked online.

On a lighter note, the US Office of National Drug Control Policy made a map of medical marijuana dispensories and Starbucks cafés in San Francisco, eliciting predictable responses.

As you can see, a website mapping important events or locations can be a very powerful way to make a political or business point.