I've been meaning to document how I wrapped the Twitter API ... in 4.5 seconds.   There is a very powerful feature in .NET is a tool in the sdk called xsd.exe.  Darren David actually has a fabulous post on exactly the power of this tool: never touch a DOM or XPATH again!   His post explains what is happening under the hood with xsd.exe quite nicely. I'd definitely recommend reading his post.  I figured it might be interesting for folks to see the exact steps I took to wrap the Twitter API:

1. Grab an instance of the public timeline from Twitter and pass that to xsd.exe to infer a schema as follows: xsd http://twitter.com/statuses/public_timeline.xml which creates public_timeline.xsd

3. Use the inferred schema to generate classes: xsd public_timeline.xsd

4. Walla!  We now have a class to party on called public_timeline.cs

5. To instantiate the class with live data, it is as simple as the following:

System.Xml.Serialization.XmlSerializer serializer = new System.Xml.Serialization.XmlSerializer(typeof(statuses));

statuses s = serializer.Deserialize(new System.Xml.XmlTextReader("http://twitter.com/statuses/public_timeline.xml")) as statuses;

And there you have it.  No DOM, no XPATH, no RegEx.  Now, if we want to take this wrapper to the next level, there are a few things we can do.  First, you will notice that Twitter returns the data as a string.  That's kind of a bummer; it would be nice to have it as a strongly typed DateTime.  Here's the line of code to do that:

DateTime date = DateTime.ParseExact(s.created_at, "ddd MMM dd HH:mm:ss zzzzz yyyy", CultureInfo.InvariantCulture, DateTimeStyles.AdjustToUniversal);

Another thing that you'll need to do is authenticate when you contact Twitter if you want data other than the public timeline.  Here's how to do that:

using (WebClient client = new WebClient())
{
client.Credentials = new NetworkCredential(TWITTER_USERNAME, TWITTER_PASSWORD);
statuses s = serializer.Deserialize(client.OpenRead(TWITTER_URL)) as statuses;
}

Of course, the TWITTER variables need to be set with the username, password and particular URL to the Twitter feed you are looking for. 

Another thing to think about doing is making the calls to Twitter on a different thread.  My recommendation for doing that is to implement Dan Crevier's Data-View-View Model.  This frees the UI thread from any calls to Twitter and provides a really nice model for marshalling data between the threads.  In fact, I did just this in my Flitter and Flitterbook implementations, which you can check out in the source code.

The final thing to think about, which I just recently implemented in some code I was working on, was to make the naming conventions look prettier.  Darren David alluded to this in his post but he's been so busy with the totally amazing HP Multi Touch kiosk he built (which you have to check out the videos for if you haven't yet) that he hasn't posted his part II.  But I imagine he's going to talk about using partial classes so as to make the class look prettier without touching the generated code.  This came in real handy with the Twitter API which generated some code with ugly array structures that I wasn't so keen on. I also had a need to use a kind of cool feature of WPF databinding where I wanted to reuse a datatemplate between two different objects (Twitter status and Facebook status) by just having them share names, such as AvatarURL, rather than create two templates that were fundamentally identitcal except for the data object. As such, I created a partial class with a bunch of getters as follows:

public partial class statusesStatus
{
public DateTime Date
{
get
{
return DateTime.ParseExact((string)this.created_at, "ddd MMM dd HH:mm:ss zzzzz yyyy", CultureInfo.InvariantCulture, DateTimeStyles.AdjustToUniversal);
}
}

public string AvatarUrl
{
get
{
return this.user[0].profile_image_url;
}
}

public string Text
{
get
{
return this.text;
}
}

public string UserName
{
get
{
return this.user[0].screen_name;
}
}

public string Location
{
get
{
return this.user[0].location;
}
}

}

Now I have a much prettier class without touching the generated code from xsd.exe.  Sorry for stealing Part II Darren. I couldn't help myself, as I have been meaning to write this post for about 2 months!