My excellent clients, 15Below, are interested in exploring how social media, like Twitter and Facebook can work in their business area, travel communications. I’ve been tasked with investigating the technical side of this, in particular interacting with the Twitter API. Before I share what little I’ve learnt about talking to twitter with .NET, I’d like to throw a stone in the lake and ripple out some thoughts on life on planet Twitter.
The first conclusion I’ve come to is that a database of twitter handles isn’t very useful; there’s not much you can do with them. You can’t send more than 250 direct messages per day, and in any case the user has to be following you to receive them. So twitter as a point-to-point mass private communication channel, like email, is a non-starter. No spamming then. You can mention slightly more people, but once again you would soon start to hit the 1000 status updates per day limit with any serious targeted communications. You used to be able to get your application whitelisted by Twitter, which allows you higher API limits, but they’ve stopped that now.
We thought about creating multiple senders, but you can’t automate account creation and most of the limits are per account. Twitter is very strict about any application that they consider to be bending their rules, and you’ll soon find yourself blacklisted even if you manually set about creating multiple accounts for an application that’s deemed to be out of bounds.
The interesting scenarios coalesce around the core Twitter interaction use case; broadcasting to followers and joining in with conversations based around mentions. One idea we’re playing with is for an account that replies with status updates when you mention it with some kind of token, say a flight number or the name of a city. You’ve still got that 1000 tweets per day limit, but so long as the use case is partitioned correctly, that needn’t be a problem.
OK, that’s the ‘what’s it good for’ waffle out of the way, now for the interesting stuff: how easy is it to talk to Twitter from .NET?
I’ve been playing with the excellent TweetSharp library by Daniel Crenna, which makes basic twitter interaction pretty trivial. The only thing I had think at all hard about was the OAuth workflow.
OAuth is a protocol that allows a user to authorise an application for a subset of functionality on their account without giving away their password. Now I will probably be building server side components that automate a small set of twitter accounts, so I need an OAuth workflow that allows me to do a one-time configuration of the component to give it access to an account. This means I have to have a one-time OAuth tool, that allows me to harvest the OAuth tokens for a single account.
I’ve written a little console app to do just that …
class Program
{
// you get the consumer key and secret from Twitter when you register your app.
private const string consumerKey = " --- ";
private const string consumerSecret = " --- ";
static void Main(string[] args)
{
var service = new TwitterService(consumerKey, consumerSecret);
var requestToken = service.GetRequestToken();
var authorisationUri = service.GetAuthorizationUri(requestToken);
// open up a browser window and point it at the authorisationUri
Process.Start(authorisationUri.ToString());
Console.WriteLine("Input the verifier pin number from the web page:");
var verifier = Console.ReadLine();
var accessToken = service.GetAccessToken(requestToken, verifier);
// now output the access token and secret so that we can cut-n-paste them into our
// server side configuration.
Console.Out.WriteLine("accessToken.Token = {0}", accessToken.Token);
Console.Out.WriteLine("accessToken.TokenSecret = {0}", accessToken.TokenSecret);
// check that the access token and secret work.
service.AuthenticateWith(accessToken.Token, accessToken.TokenSecret);
Console.WriteLine(service.Response.Response);
}
}
This will pop up a browser window and present a pin number generated by Twitter that you then have to copy and paste. It then outputs the generated token and ‘token secret’ for that account.
Once you’ve got an access token and a token secret, you can use them for as long as you want. If you own the accounts your server side component is using, you don’t have to consider the workflow for when the user cancels your application’s access rights.
Sending a status update is trivial …
var service = new TwitterService(consumerKey, consumerSecret);
service.AuthenticateWith(previouslySavedToken, previouslySavedTokenSecret);
service.SendTweet(message);
My next challenge is getting to grips with the streaming API so that I can monitor mentions and reply to status update requests. I’ve got a working demo that polls the Twitter API, but it’s a very wasteful use of the scarce API access allowance.
So there you have it. Some very early thoughts on using Twitter for business and pleasure. I think there are some very exciting opportunities, especially for ‘you don’t have to install anything’ communication with remote applications scenario.