If you haven’t yet please see:
Part 1
Part 2
Next, we want to build some UI to show us the data we’ve got back from Twitter. For this we’re going to use WPF. Before we get started with that, however, a bit more refactoring is needed. Since we want our UI to be nice and responsive, we’re going to do all of our talking to twitter on background threads. To that end, we want to make our TweetSharp code thread safe. We have basically have two major requests that we need to make, one to get all of our friends and one to get all of our followers. We can send those off more or less simultaneously, and wait for twitter to send back the response, all the while keeping the UI thread free to repaint the form as needed.
To that end, let’s wrap our twitter code up into a class. This also has the nice side-effect of limiting our dependency on TweetSharp from the UI layer. We could sprinkle TweetSharp calls throughout the UI, but that would be a refactoring nightmare should Daniel and I ever fall off a cliff and stop updating it, forcing you to move to one of the other (less fun 
) libraries out there.
I’m not feeling particularly creative, so I’m going to just call the class “Twitter”:
using System;
using System.Linq;
using System.Collections.Generic;
using Dimebrain.TweetSharp.Extensions;
using Dimebrain.TweetSharp.Fluent;
using Dimebrain.TweetSharp.Model;
namespace Diller.SocialGraphMinder
{
internal class Twitter
{
private readonly string _userName;
private readonly string _password;
private TwitterUser _User;
public Twitter( string username, string password )
{
_userName = username;
_password = password;
IsAuthenticated = Authenticate();
}
private bool Authenticate()
{
var twitter = FluentTwitter.CreateRequest()
.AuthenticateAs(_userName, _password)
.Account().VerifyCredentials()
.AsJson();
var response = twitter.Request();
_User = response.AsUser();
return _User != null;
}
public bool IsAuthenticated{ get; private set; }
}
}
Nothing particularly interesting there. Upon construction, the class performs a credentials verification with the given credentials and sets the IsAuthenticated bool so we know it’s safe to proceed.
Next, we’ll add the friend and follower fetching code:
//add these private members
private IEnumerable<TwitterUser> _friends;
private IEnumerable<TwitterUser> _followers;
//add these methods
public IEnumerable<TwitterUser> GetFriends()
{
if (!IsAuthenticated)
{
throw new InvalidOperationException("Not authenticated");
}
if ( _friends == null ) //only do this if we don't already have the friends list
{
var twitter = FluentTwitter.CreateRequest()
.AuthenticateAs(_userName, _password)
.Configuration.UseGzipCompression() //now using compression for performance
.Users().GetFriends().For(_userName)
.CreateCursor()
.AsJson();
_friends = GetAllCursorValues(twitter, s => s.AsUsers());
}
return _friends; //return either the newly fetched list, or the cached copy
}
public IEnumerable<TwitterUser> GetFollowers()
{
if ( !IsAuthenticated)
{
throw new InvalidOperationException("Not authenticated");
}
if (_followers == null)
{
var twitter = FluentTwitter.CreateRequest()
.AuthenticateAs(_userName, _password)
.Configuration.UseGzipCompression()
.Users().GetFollowers().For(_userName)
.AsJson();
_followers = GetAllCursorValues(twitter, s => s.AsUsers());
}
return _followers;
}
//we also need the cursor paging code from part 2
private static IEnumerable<T> GetAllCursorValues<T>(ITwitterLeafNode twitter, Func<string, IEnumerable<T>> conversionMethod)
{
long? nextCursor = -1 ;
var ret = new List<T>();
do
{
twitter.Root.Parameters.Cursor = nextCursor;
var response = twitter.Request();
IEnumerable<T> values = conversionMethod(response);
if (values != null)
{
ret.AddRange(values);
}
nextCursor = response.AsNextCursor();
} while (nextCursor.HasValue &amp;amp;&amp;amp; nextCursor.Value != 0);
return ret;
}
Finally, lets add some methods to get the data we’re really after, the aforementioned ‘spammers’(users who follow us, but whom we don’t follow), and ‘jerks’ (users whom we follow, but who do not follow us back).
public IEnumerable<TwitterUser> GetFriendsWhoDontFollowBack()
{
friends = GetFriends();
followers = GetFollowers();
return friends.Except(followers);
}
public IEnumerable<TwitterUser> GetFollowersWhoArentFriends()
{
friends = GetFriends();
followers = GetFollowers();
return followers.Except(friends);
}
If we left this code as-is, it would work perfectly well in a single-threaded application. Whatever code path got to the ‘GetFriends’ and ‘GetFollowers’ methods first would make all the proper calls and cache the results in the member variables. However if you try to use this class in a multi-threaded fashion you’re going to be in for a world of hurt. (Well, really, it most likely just plain ol’ won’t work).
If, for example, you create two threads, one to call the ‘GetFriendsWhoDontFollowBack’ method and the other to call the ‘GetFollowersWhoArentFriends’ method, both are going to call GetFriends() and GetFollowers(), likely before the other one has finished. At best, you’re duplicating work and chewing up your API limit unnecessarily, at worst, you’re going to confuse twitter by resetting the cursor on the second thread somewhere in the middle of paging through it on the first, causing it to throw HTTP 500 errors. (This is what happened when I tried it, and it’s something that probably warrants its own blog post as it was unexpected).
So, to remedy this, we need to synchronize access to the TweetSharp calls so we’re not making a tangly mess:
//add the following private members
private readonly object _friendsLock = new object();
private readonly object _followersLock = new object();
//amend the getfriends and getfollowers methods so they look like this:
public IEnumerable<TwitterUser> GetFriends()
{
if (!IsAuthenticated)
{
throw new InvalidOperationException("Not authenticated");
}
//see if friends are already fetched
if (_friends == null)
{
//if not already fetched
//wait for exclusive access to this code
lock (_friendsLock)
{
//need to double-check here
//another thread might have set the member
//while we were waiting
if (_friends == null)
{
var twitter = FluentTwitter.CreateRequest()
.AuthenticateAs(_userName, _password)
.Configuration.UseGzipCompression()
.Users().GetFriends().For(_userName)
.CreateCursor()
.AsJson();
_friends = GetAllCursorValues(twitter, s => s.AsUsers());
}
}//lock is released here
}
return _friends;
}
//make the same adjustments to this method:
public IEnumerable<TwitterUser> GetFollowers()
{
if ( !IsAuthenticated)
{
throw new InvalidOperationException("Not authenticated");
}
if (_followers == null)
{
lock (_followersLock)
{
if (_followers == null)
{
var twitter = FluentTwitter.CreateRequest()
.AuthenticateAs(_userName, _password)
.Configuration.UseGzipCompression()
.Users().GetFollowers().For(_userName)
.AsJson();
_followers = GetAllCursorValues(twitter, s => s.AsUsers());
}
}
}
return _followers;
}
A few important points:
- We used separate lock objects around the fetching of _friends and _followers objects as they are independent and can be fetched simultaneously.
- For best performance we only lock when we’re going to do the fetch. Once the objects exist they can be read without locking by any thread.
- The double-check for null after acquiring the lock is important to prevent duplication of effort.
- If we decide to periodically update the _friends and _followers lists, we would probably want to convert our locking behavior to a ReaderWriterLockSlim type, which is ideal for resources that are read a lot but infrequently updated.
It’s also worth noting that Tweetsharp instances aren’t thread safe. You should never try to use the same instance of a FluentTwitter request across multiple threads without doing your own synchronization. Since they are designed to be transient, it’s best to just create a new one on each thread that you’re using to talk to Twitter and leave it there.
This post has gotten too long already, so let’s end it here and take it up again in part 4…at which point, I promise, we will actually put pixels on the screen.
