Skip to main content

Appharbor build notification using Google Talk (XMPP)

Appharbor recently ran a contest to encourage developers to use their API and showcase the API capabilities.
Based on some ideas floated by the Appharbor team I too decided to build something useful\interesting for Appharbor platform.I decided to create a desktop notification client which can notify user when the build is complete, its status in terms of success or failure.

How Appharbor works is that you push your code to a git repo supported by Appharbor (github, bitbucket etc). As soon as the checkin is done, Appharbor pulls the code base build it, and updates the running website. It's like a single click deployment!

I started to explore my option for a desktop client and some of the options I though of were
  • Build a desktop windows app and integrate with the Appharbor API.  This approach was the most flexible approach. I have full control of features and capabilities, but would take a good amount of time to develop.
  • Use third party desktop notification apps like Growl for Windows and use the Growl API to integrate with Appharbor. The shortcoming with this approach is that the user needs to install Growl for Windows on his machine, but it is better than the first approach as i can make use its existing notification capabilities

What i finally decided was to create a solution that uses Google Talk as the  notification client. The advantages of this approach were
  • Easy to build and within a short time span.
  • No extra installation required. Now a days most people have these messenger clients installed.
  • Cross platform \  Cross browser compatible.  Works on Mac, Linux, Windows i.e on any system that supports a XMPP client.
  • It seems cool :)
  • This approach can support any XMPP based client.Google Talk being one of them. This wiki entry details about the existing clients supporting XMPP.
The disadvantage with this approach is that you are limited by Google Talk + XMPP protocol capabilities.

So after dabbling for few days i created a working prototype. Here is how it works.

  1. User creates an Appharbor Application.
  2. Navigates to to generate Service hook url.
  3. Generates the Service hook url from this site.
  4. Adds the generated Service Hook url to his Appharbor app under the Service Hook section.
  5. Adds contact to his Google Talk
  6. Receives all build notifications in his Google Talk!!!
The final outcome, user now gets all build completion and failure notifications. This is how  notifications look

I would be soon publishing the second part in this series, where I would talk about the technical aspect of the solution, which is as interesting as the solution. This solution is an amalgamation of Windows Azure and Appharbor so just watch out for my future post.


Popular posts from this blog

Caching Images downloaded from web on Windows Phone Isolated storage

I was helping on a Windows Phone application where the requirement was to cache the images the phone downloads on the isolated storage for offline viewing.
I wanted a solution which was simple and as transparent as possible. While researching I found  someone wrote a Silverlight converter for loading images from isolated storage. Taking that as a base I created a converted which can
Load image from web (http + https), and persist it to isolated storage.In case of network connectivity issues can load the same image from isolated storage. It does that by mapping the http url to a isolated storage location.In case the network is down and the image is neither there in cache, loads a default image, passed as parameter to converter.Here is the gist for the implementation.

To use the converter
Import the name space.Declare the converter as resource.Set the Image Source Property to use this converter like this 

IIS Url Rewrite and HTTP POST data

If you play around with IIS Url Rewriting rules and try to do redirects on an HTTP POST you loose your POST data.

To make sure you get the post data you have to set the `redirectType` to `Temporary` within your rules. So the action configuration looks like this

<action redirectType="Temporary" type="Redirect" url="http://{HTTP_HOST}{REQUEST_URI}"> </action>
You may think what scenario warrant a POST request redirect. We faced one such scenario while doing SSO with a federated Identity Provider (IP)  such as Google, Azure AD. In federated authentication scenario once the user is authenticated by the IP, it redirects back to your site with claim tokens in a POST request over secure channel (https). In our case we wanted to redirect to user back http after receiving the request. But any redirects were causing loss of token. By doing a 307 (Temporary) redirect we were able to preserve the post data.