Eventually there will be MahTweets for Windows Phone 7 (WP7), but for now I’m concentrating on getting the base library done. One of the advantages is with anything .NET is that you can reuse code from platform to platform – ie, the same C# that works on desktop can work on the web via ASP.NET or in games on the Xbox 360. Kinda. The problem is the compact/minimal variants such as Silverlight or WP7’s Silverlight don’t cover 100% of the “desktop” .NET or don’t work with third party libraries, or the Client Profile which lacks certain core libraries (such as System.Web). In this case, being Silverlight, everything has to be asynchronous, and is Silverlight 3 based, rather than the current release of Silverlight 4.
Currently there is no real error checking/handling, nor any tests, but the basics work. MahApps.Twitter makes use of JSON.NET (for deserialisation) and Hammock (for OAuth and REST requesting)
Eventually this library will also come in a desktop flavour, it’s just a matter of time.
Obviously, make sure YOURKEY, YOURSECRET and YOURREDIRECTURL are changed. This is example code for SetupView.xaml.cs – an PhoneApplicationPage. You will need a webbrowser to do the initial OAuth authorisation dance. I don’t have XAuth to test against, and I also believe it defeats the purpose of OAuth in the first place, so it isn’t currently covered by the library. If you wish to contribute something XAuthey, comment below or contact me via Codeplex :)
private const string ConsumerKey = "YOURKEY";
private const string ConsumerSecret = "YOURSECRET";
private TwitterClient t;
public SetupView()
{
InitializeComponent();
t = new TwitterClient(ConsumerKey, ConsumerSecret);
t.BeginGetRequestUrl(RequestUrlCallback);
}
public void RequestUrlCallback(RestRequest request, RestResponse response, String Url)
{
wbBrowser.Navigate(new Uri(Url));
}
private void wbBrowser_Navigated(object sender, System.Windows.Navigation.NavigationEventArgs e)
{
//If it contains mahtweets.com, it is redirecting.
if (e.Uri.AbsoluteUri.Contains("YOURREDIRECTURL"))
{
t.BeginGetAccessToken(e.Uri,AccessTokensCallback);
}
}
public void AccessTokensCallback(RestRequest request, RestResponse response, Credentials Tokens)
{
//STORE THESE TOKENS!
t.SetOAuthToken(Tokens);
//Get information about the authorised user
//t.Account.BeginVerifyCredentials(VerifyCredentialsCallback);
}
public void VerifyCredentialsCallback(RestRequest request, RestResponse response, ITwitterResponse Response)
{
User u = ((User) Response);
//Do cross thread GUI shit for WP7/SL/WPF and you could do Application.Name = u.Name
}
Twitter has for awhile had streaming support for larger volume of Tweets, usually processed by companies offering analytics or searching or other ‘services’ that need a high volume to make stuff work. Streaming maintains a very long HTTP session (infinitely long?), where Twitter pushes the data to you. In the case of "firehose" or "gardenhose", they’re all public Tweets, sometimes filtered to keywords, etc.
Another analogy is the long car trip with kids in the back. The standard RESTful API is the children asking "Are we there yet? Are we there yet? Are we there yet?", whereas Streaming is the parents in the front saying "I’ll tell you when we are there…. we’re there"
From Twitter’s point of view, at least in theory, this will result in less requests so their servers will be hammered less and in turn could result in a faster, more reliable service. From the user point of view it gives you real time Tweets using less traffic. Its win-win.
What are user streams?
When they had their first conference earlier in the year (Chirp), they talked about something called user streams. Are they a stream of a single user? No, user streams are what all desktop clients will eventually move to. They’re a stream of the logged in users friends tweets, mentions and direct messages as well as what I presume will be called "stream events" which include interactions between two people and optionally a Tweet.
You’ll notice the Streaming API is read only, so the REST API will be hanging around for writing (Tweeting). Infact, REST API will be hanging around so that you can do the initial "fill up" of the client, since the stream only gives you Tweets since you connected to the service.
Sadly, it is in limited beta at the moment, so while we’ve now got the code to do it in MahTweets, we can’t freely give it out to everybody yet.
Stream Events A stream event has a target, a source, a target object and a name for the event. So far I’ve only been able to observe the target object being a Tweet.
When Twitter originally released their API it had only one form of authentication what is now known as "basic auth". The issue with basic auth is that it requires any applications or websites that ends up using the API to use the username and password. Obviously, this represents a security issue because third parties have full access to the user via API or by just taking those passwords and logging in manually.
Like many other social services, Twitter eventually cottoned on that this was a bad idea, and they’ve adopted OAuth, a token based authentication delegation system.
Some have argued that OAuth is too complex, if you read the Twitter dev mailing list there are numerous requests to keep basic auth but just move it to SSL only. Security and trust shouldn’t be the easiest thing in the world, there needs to be a degree of complexity about them.
Somebody at Twitter got it into their mind that listening to the general whingers and whiners was a good idea. Instead of just relying on open standards, they’d make their own protocol dubbed xAuth which works in conjunction with Oauth. xAuth requires the user to enter in their user name and password, then the application/website can use those credentials to exchange for OAuth access token/secrets. Hang on a moment, their new security measure requires you to enter in "basic auth", essentially? This isn’t a case of two steps forward, one step backward, it’s a case of two steps forward and then a bullet in the head.
The idea of OAuth is so you don’t’ have to have complete trust in the applications – just the service. This method relies on the consumer application to "be a good citizen" and discard the username and password after they’ve got their tokens.
Twitter, please stick to social media, not security.
Where is part one? Well a few months ago, Brendan wrote part one outlining the frustration we feel about everybody loving the "big boys" in the Twitter client space, never giving the smaller, (seemingly) the non-VC funded, open source clients a chance to shine.
It’s happened again, but this time its worse. Seesmic were yet again presenting at a major Microsoft conference (MIX10), banging on about how they got early access to the WinPhone7 Series hardware and SDK – how wonderful, another platform we simply can’t compete with because come day one, they’ll have not only had the emulator for longer, but physical devices to try everything on. And if we were to move to WP7S, we’d have to break the mindset of everybody who saw MIX/associated articles that "WP7S + Twitter = Seesmic". They are in the phone from before day one. You just can’t compete against that.
Oh, and something about updated desktop client that will include plugins – turns out via MEF, just like us. The one consolation I have is that all those promised features they keep banging on about – we’ve got them today. Now. 3 months ago. Not "in the near future" (anybody seen their iPhone client they promised? oh wait, doesn’t exist)
Unlike Brendan, I’m not venting at the general noisy ‘industry’ and how hard it is to get a break, but how the favourites of PDC will continue being the favourites on every platform Microsoft releases, so long as Microsoft keep handing out early access to the same developer again and again. This isn’t so much about MahTweets, but the frustration that Microsoft pick a favourite and will run forever with them – what about the other, smaller clients in this field? Where is the love for Witty, Blu, Halfwit, Sobees, or Gadfly?
It feels less like "Developers, Developers, Developers" and more like "Developers – those guys, the rest of you don’t matter"
Why even bother?
After MahTweets 3 (which is a very major version/update), I won’t be bothering – I’ll be getting out of the "game". MahTweets will be maintained/major bug fixes, the others may continue working on it, but I have no more interest in creating Twitter clients.
Why is it so personal?
For lack of a better cliché, I am MahTweets. I don’t mean to diminish the role or contributions of others, far from it, when I say I am MahTweets, I mean that I’ve poured a lot of myself into it, I’m the public face, I’m the "overlord", I started the project. For the others, it’s a pet project – for me, I’m disabled and unable to get a ‘real job’ – it’s as close to a job as I’ll have for a long time.
MahTweets is my twitter client of choice. Why? Well, I wrote it. Okay, that isn’t the only reason, it has some pretty awesome features distinguishing it from many Twitter clients.
Features
Inline media viewing View twitpic, flickr, direct images, and youtube (working on it, an IE8 update broke it) all inside MahTweets. Support will be expanded to support yfrog and any other services people request.
Webcam support Use your webcam to directly upload to twitpic (flickr, yfrog, and others coming later) or as your avatar on Twitter
Conversation viewing
Tracking This was common in the "old days" of Twitter, but now it seems to be called saved/inline searches? Either way, if you’re particular interested in tweets on a particular subject, track keywords using twitter search.
Filtering No more "#followfriday" clogging up my Twitter stream
Scalable UI Because MahTweets is coded in WPF, I can scale everything (not just change font sizes) neatly at a click of a button.
Short URL expansion Tired of being Rick Rolled through tinyurl, is.gd, bit.ly (and many others)? By auto-expanding the shortened url’s (using Long URL Please), you won’t be launched into sites you know are bad
Multi-account support & grouping Coming soon!
Tech Goodness (Requirements and other details)
.NET 3.5 SP1
Built with WPF, C#, using a modified WPFCap library,
Through Windows 7′s "XP Mode" I’ve tested Windows XP support, and even in the virtualised environment it was smooth – so smooth that it took me a good 10 minutes or so to notice I’d launched it in XP Mode instead of "natively"!1
Below is a screenshot of an earlier build, running XP Mode and Windows 7 "natively"1 the two running side by side.
My Demo’s Happen Here entry (entries closed last month) was on Visual Studio 2008, how it can rock your socks by creating Twitter clients in WPF and Silverlight.
For interests sake, the screencast was recorded using Microsoft’s Community Clips Recorder and edited with Windows Movie Maker – both free (well, providing you have Windows). Community Clips Recorder is fairly basic when you compare it against Camtasia, as it has no editing, zooming, or highlighting capabilities. However depending on the situation Camtasia is overly complex and the price difference is something to be considered.
