It was relatively easy, although still more difficult than I would have guessed, to hook my bespoke website's Atom feed up to Google Buzz. I already have a Google email account and associated profile so Buzz just showed up in my Gmail interface. Setting it up it offered to connect to my YouTube account or my Google Chat account but I didn't see an option to connect to an arbitrary RSS or Atom feed like I expected.
But of course hooking up an arbitrary Atom or RSS feed is documented. You hook it up in the same manner you claim a website as your own via the Google Profile (for some reason they want to ensure you own the feed connected to your Buzz account). You do this via Google's social graph API which uses XFN or FOAF. I used XFN by simply adding a link to my feed to my Google profile (And be sure to check the 'This is a profile page about me' which ensures that a rel="me" tag is added to the HTML on your profile. This is how XFN works.) And by adding a corresponding link in my feed back to my Google profile page with the following:
atom:link rel="me" href="http://www.google.com/profiles/david.risney"
I used this Google tool to check my XFN
connections and when I checked back the next day my feed showed up in Google Buzz's configuration dialog.
So more difficult than I would have expected (more difficult than just an 'Add your feed' button and textbox) but not super difficult. And yet after reading this Buzz from DeWitt Clinton I feel better about opting-in to Google's Social API.
Irritatingly, my G1 won't show me PDFs so I've made the Google Docs PDF viewer which will load PDFs on the web up in Google Docs. Google Docs has the useful ability to display PDFs in web browsers without any Adobe software and works (mostly) on Android.
This was very easy to put together as an Android activity. First its necessary to register the application as handling PDFs from the web. This is done via the intent-filter declaration in the manifest:
intent-filter
action android:name="android.intent.action.VIEW"/
data android:scheme="http" android:mimeType="application/pdf"/
category android:name="android.intent.category.DEFAULT"/
category android:name="android.intent.category.BROWSABLE"/
/intent-filter
The action part says my activity will view PDFs, the data part says it accepts data with the PDF mime-type and with a URL that has an HTTP scheme. The browsable category
is necessary to allow links from a browser to open this activity.
Second, the activity opens up the browser to Google Docs pointing to the PDF.
Intent intent = new Intent();
intent.setAction(getIntent().getAction());
intent.setData(Uri.parse(
"http://docs.google.com/gview?embedded=true&url=" +
percentEncodeForQuery(getIntent().getData().toString())));
startActivity(intent);
This is very simple code to invoke a new intent browsing to a newly constructed URL for the PDF in Google Docs. That was easy.I've made a WPAD server Fiddler extension and in a fit of creativity I've named it: WPAD Server Fiddler Extension.
Of course you know about Fiddler, Eric's awesome HTTP debugger tool, the HTTP proxy that lets you inspect, visualize and modify the HTTP traffic that flows through it. And on the subject you've probably definitely heard of WPAD, the Web Proxy Auto Discovery protocol that allows web browsers like IE to use DHCP or DNS to automatically discover HTTP proxies on their network. While working on a particularly nasty WPAD bug towards the end of IE8 I really wished I had a way to see the WPAD requests and responses and modify PAC responses in Fiddler. Well the wishes of me of the past are now fulfilled by present day me as this Fiddler extension will respond to WPAD DHCP requests telling those clients (by default) that Fiddler is their proxy.
When I started working on this project I didn't really understand how DHCP worked especially with respect to WPAD. I won't bore you with my misconceptions: it works by having your one DHCP server on your network respond to regular DHCP requests as well as WPAD DHCP requests. And Windows I've found runs a DHCP client service (you can start/stop it via Start|Run|'services.msc', scroll to DHCP Client or via the command line with "net start/stop 'DHCP Client'") that caches DHCP server responses making it just slightly more difficult to test and debug my extension. If a Windows app uses the DHCP client APIs to ask for the WPAD option, this service will send out a DHCP request and take the first DHCP server response it gets. That means that if you're on a network with a DHCP server, my extension will be racing to respond to the client. If the DHCP server wins then the client ignores the WPAD response from my extension.
Various documents and tools I found useful while working on this: