Sunday, June 6, 2010

TwitCh - my Chatter developer challenge entry - plus OAuth and JQuery

Well I've finally got my entry in for the Chatter challenge, here's hoping that it stacks up against some of the others! Haven't got the official submitted entry page yet for voting, but you can check out an overview on Youtube if you're interested. There's also some pics I've put up on flickr.

And of course the 30 sec summary..
"TwitCh provides a central point to aggregate not only important information from Chatter, but also feeds from external accounts like Twitter or Facebook. Because collaboration in the enterprise isn't only limited to employees within an organisation, TwitCh enables the display of all social feed information that might be important to a business."

Pulling TwitCh together has been a great learning experience for me, and as per my previous post it's given me a chance to get up to speed on 2 areas I've been meaning to look into for a while - OAuth and JQuery.

OAuth

When I started thinking about the idea for TwitCh, the key initial idea was around pulling back information from Twitter and combining it with Chatter feed info in salesforce.com. I started by looking into the Twitter dev area, and soon found that OAuth would have to form a key component of the solution. Twitter still supports xAuth (user/password) but only up to June 30th. I could have done it this way in time for the Chatter challenge, but OAuth is a much more elegant solution in so many ways, so I went for the more complex but more satisfying solution at the same time!

Twitter uses OAuth 1.0A, whereas Facebook uses OAuth 2 (much easier), but the solution had to fit with both providers. So I charged into building an OAuth consumer library within Apex. I looked round but didn't find anything out there for oauth/Apex, so built an extendable set of libraries that could be used across any service provider. I'm sure with OAuth becoming more prevalent Salesforce will incorporate this nativately some time soon but until then, there's a library which I will put on codeshare for others to use...

I've created the following:
  • Base OAuth class which handles common properties (eg. access token, consumer key) and methods (eg. Authorise() ). This also handles common functions which are required in the OAuth process - eg. get the Epoch value for the current time, signing with HMAC-SHA1, etc
  • For each service provider, an extension to this base class should be created, where common services are implemented (eg. For Twitter, getHomeFeed(), UpdateStatus() ). This extension uses the base Authorise() and the properties, and exposes the provider-specific services
For my TwitCh app, I then encapsulated all of this into a higher level class - eg. TwitterAccount, FacebookAccount - so I could refer to the concept of an 'Account' in my app, and attach other requirements such as account-specific settings, feed colour, nickname etc

Here's a screenshot of the layout of the class in Eclipse - showing the Base class as well as the Twitter extension:





You can see for example that a Twitter account has parameters sich as User ID and Screen Name - these are captured in the extension rather than the base class. All that really exists in the base class are the requirements for authorisation and persistence (eg. tokens).

The only requirement on the salesforce object side is somewhere to store these tokens once they are returned - both at the initial request token stage (as we are then passed over from salesforce to the service provider for further authorisation) and then again once the access token has been returned. This is stored along with an account name and User lookup.

JQuery

After OAuth work in Apex, JQuery was a breeze to get into my Visualforce page. TwitCh is all just the 1 main Visualforce page, with components for settings and a separate controller. I wanted to factor in some nice usability, so used the following:
Was just a matter of including the CSS and JS from the first 2 in my page (in the case of the settings sections, I had to ensure the CSS was in the main page not the component) and using the styleClass= tag in my Visualforce tags.

I'm also grateful to tgerm.com for their work on the XML DOM that they've put on google code (https://code.google.com/p/apex-fast-xml-dom) - this saved me a LOT of XML parsing work on the responses.

Finally, if you're super-super keen then I've put some of my 'blueprints' up here on flickr also - these are some of the first notes I made when I had the idea for TwitCh and how the class structure might look. Seems like months ago but it was only about 3 or 4 weeks when I seriously decided to do this, so I for one am pleased I've been able to go from concept to product in about 25 days!

I will also come clean and say that while TwitCh posts status updates to Facebook fine, I didn't get a successful feed back where I could present this info in TwitCh. Facebook returns their info as JSON, and while there is a JSON parser out there (thanks Ron H - it's on codeshare) this unfortunately isn't up to parsing a 1000+ line feed from FB. Basically I hit the script limit of 200k lines pretty easily ;) So my idea for coming SFDC releases will be native JSON support! In the mean time though I'm currently looking into an external JSON to XML parser which could potentially run in google app engine - my pet project in the coming weeks!

Thanks for reading.

No comments:

Post a Comment