A couple of weeks ago, I realised that my public vCard was less useful than it might be. One of the specific reasons that I created it was to make it easy for people to add a bunch of my contact information to their address books when I met them, rather than them having to manually type in a whole load of stuff that was on a business card. It turns out that this is great when that person’s sat at their own computer, but if they’re (for example) using an iPhone then things become a little more difficult.

You see, the iPhone doesn’t like to use MobileSafari to download files. That’s fine in general – you don’t get a filesystem to peruse on the iPhone, so the only way that downloads would be useful is if the iPhone already knows what to do with them. That’s why applications are allowed to register their own custom URL schemes.

Unfortunately, by default the iPhone only registers a few URL schemes for use within web pages – mailto:, tel: and sms: as pseudo protocols, as well as specific URL structures for Google Maps, YouTube and iTunes links. This makes it impossible to do things like adding an address to the Address Book or an event to the Calendar with a single click on a link in a webpage – you just get a message that reads “Download failed. Safari cannot download this file”.

This is clearly a pain. As a phone, it seems reasonable that you should be able to easily add contacts to your Address Book. Unfortunately, either Apple thinks you shouldn’t be able to do this from a webpage or they just didn’t consider it as a usecase.

It turns out that they did consider that you might like to open email attachments though. If someone sends you an email that contains a VCF file then you are able to open it and see its contents. If you then scroll down to the bottom of the file you’re greeted with two options, allowing you to “Create New Contact” or “Add to Existing Contact”. Suddenly a world full of contact adding goodness is opened up to you.

So, what I’ve decided to do with my vCard is a little bit of user agent sniffing in my PHP. Currently I assume that every other device in the world other than the iPhone will do something sensible with the normal VCF file (or the microformatted data that’s on the page itself), so I listen out for the iPhone’s user agent. If I see it then I swap out the link to download the VCF file with one that takes the user to a page containing a form allowing them to enter their email address. Once they do, the VCF file is immediately emailed to them and they can add my card to their address book.

Right now the look and feel of the the email form that iPhone users are directed to could be described as rudimentary at best, but it works. At some point in the future I’ll get round to making it look a bit more pretty.

As a solution, I’m fairly happy with this. Whilst it’s nowhere near as nice as being able to simply click on a link and add a contact to your address book, it does at least mean that it becomes possible to add a contact from a web page. Certainly it’s a better solution than not allowing users access to the content at all. It’s also entirely possible that this solution would work for other filetypes, such as calendar events.

My only concern is that this problem may be in existence in other devices other than the iPhone as well. It would almost certainly make sense to make the email option available to users of other devices as well.

So there you have it – to allow a user to add a contact to their Address Book from a webpage on the iPhone don’t try and get them to download it, let them receive it via email instead.

The first thing to be aware of is that if Safari can display something on a webpage, then Dashboard can display it as well. If you visit a page in Safari and right-click somewhere on the background of the page then you should see a menu item titled Open in Dashboard.... If you select this then you’ll be able to drag to select an area of the page to turn into a dashboard widget. Click the Add button at the top of the window once you’re done, and you’ll magically have created a widget. Now, any time you open up your Dashboard that widget will be reloaded and you’ll see fresh data.

So, that’s how we’ll display the playlist as a Dashboard Widget – we’ll create a webpage that contains the data and then use that as the widget.

If you read the last entry, you’ll know that I like to use AppleScript as a quick glue language on my Mac. It’s pretty easy to use (once you know what you’re doing), and you can hook into many of the apps you use on a day to day basis and do interesting things with them. So, it should be no surprise to hear that I’ll be using AppleScript to get the playlist data out of iTunes. Given that I’ll be displaying this data on a webpage though I’ll be using PHP (because it’s what I know) to write a quick and dirty page that displays the data that the AppleScript provides.

The AppleScript is a little more involved than the one liners we used last time. We need to grab the current playlist and then grab information about its UID, Title, Artist and Album, and before finally finding out what the currently playing track is. Here’s how we do that.

set tracks_list to {}

tell application "iTunes"
    tell current playlist
        tell tracks
            set tracks_list to get {persistent ID, name, artist, album}
        end tell
    end tell

    set tracks_list to tracks_list  {persistent ID of current track}
end tell

get tracks_list

In this script we first we create an empty list to put all our data in, then we add lists of track IDs, names, artists and albums to it, then we add a single item of the currently playing track’s ID. It’s not the most elegant of data structures to use once we get to play with it in PHP, but it’ll do. Running this from the commandline using osascript -s s playlist.scpt (the -s s means “print the output in a recompilable form”) gives us something like the following (respaced for clarity):

{
    {
        "0D7D716D221B623B", 
        "688E193B9F7F7EE3", 
        "05BFA94137C9691F"
    }, 
    {
        "Fashion Is Danger", 
        "Fabulous", 
        "Never Gonna Give You Up"
    }, 
    {
        "Flight of the Conchords", 
        "High School Musical Cast", 
        "Rick Astley"
    }, 
    {
        "I Told You I Was Freaky", 
        "High School Musical 2", 
        "Fantastic 80s"
    }, 
    "688E193B9F7F7EE3"
}

Now that we have a data structure, we can actually do something with it in PHP. Unfortunately, as far as I’m aware there’s nothing built into PHP that’ll read this structure. Fortunately though, this structure is pretty damn close to JSON. If we were to replace the twiddly brackets with square ones then PHP’s json_decode would return a data structure and we could do something with the data. Hooray. It’s a hack, but it works, and it’s what I did. A simple str_replace later and I had data. You can see the code, such as it is, in my github repository.

The eagle eyed amongst you will notice that I’m not directly calling osascript from my PHP script though, and am instead going through an intermediary shell script that nukes DYLD_LIBRARY_PATH before running the AppleScript. The reason for this is that on the machine I’m running the script on I’m using MAMP for my web stack, and that does funny things with DYLD_LIBRARY_PATH under Snow Leopard apparently. So, I have to nuke it.

And that’s all there is to it. Visit the webpage you’ve created to display the data, let it show you what’s playing and then turn it into a dashboard component using Safari. I get to control iTunes on a remote machine and I don’t have to keep a VNC connection on it. This makes me happy.

So, I went back to scratch and tried installing it on a web-server. Since my normal stack is Apache, MySQL and PHP I didn’t have any of the Java-based web-servers suggested by the W3C. My first attempt at getting the validator working was to use Jigsaw – the same web-server as the W3C uses to run their version on. Unfortunately, it didn’t work for me. Bugger.

So, I tried Tomcat. After following Basil Bourque’s instructions on Apache’s Tomcat wiki pages, I got Tomcat working. I then followed the rest of the CSS Validator installation instructions for Tomcat, and the validator worked in my browser. Excellent.

There was a fly in the ointment though. Whilst the validator worked in my browser, the same could not be said of my attempts to get it working via cURL calls from PHP using POST data. I was using the same code as I’d used to validate against the W3C’s HTML validator, so I knew that I was able to successfully push POST data across to servers. If I tried using GET requests to send the data to my local validator, then that worked. I verified the same thing was happening on the live CSS validator to make sure the problem wasn’t with my installation. I know you’re thinking “well, if GET worked, why not just make requests that way?” Unfortunately, I know that later I’ll be asking to validate much larger CSS rulesets — ones that will be far too large to fit on a URL. So, I needed to use POST.

After a fair bit of poking, I realised that the in-browser version of the CSS Validator was setting an enc attribute value of multipart/form-data on the form when it was uploading files or sending textual data. Conversely, it turns out that PHP was sending application/x-www-form-urlencoded as the encoding type instead, and the W3C CSS Validator just isn’t set up to accept that. After a long time of trying to work out how to send things in multipart/form-data format using PHP’s cURL functions, I happened upon a comment on PHP’s curl_setopt function which told me that if I gave PHP an array instead of a string it would automagically start using multipart/form-data. As if by magic, my problem was solved.

My problems setting up my programmatic connection to the CSS Validator could easily have been solved by clearer documentation. Nowhere that I could find in the Validator’s documentation was there any mention of needing to make POST requests using multipart/form-data. If this had been stated somewhere I would at least I have known the path I needed to be looking down. Likewise, lack of anything other than user-generated documentation for the PHP CURLOPT_POSTFIELDS cURL option made life far more difficult than it should have been.

Still, in the end I have a local version of the W3C’s CSS validator running on my laptop, and I’m able to connect to it programmatically to run tests. Which is nice.

These are the slides I put together for my talk:

If you just want to download the Code, go right ahead. If you want to know more about the project, read the WikiSlurp Project page.