• “IronCow Mobile” is a branch that adds support for the .NET Compact Framework. Thanks to jwboer for the initial patch.
• “IronCow Local Search” is a branch that adds local search for tasks. We basically cache all the tasks in memory, and handle search queries locally, instead of sending a request to the RTM server and parsing the response markup. The lexical analysis and AST building of the search query is a bit dodgy, as I can’t get a proper tool like ANTLR to work with RTM’s search grammar (probably me doing something wrong), but it’s not too much of a problem right now since search queries tend to be quite short, and we already are significantly faster than a web request.

Check them out!

Of course, one of the things that went into IronCow’s design was testability. IronCow ships with a suite of unit tests that, well, test that the API is working fine. However, there’s another testability aspect: how the clients of your API are going to test their stuff. These are 2 different things:

• Within IronCow, “design for testability” means I have to be able to mock the underlying client that communicates with the RTM REST API. Then, I can manipulate my objects and check that the correct requests are sent, and that those objects behave correctly according to the responses I give.
• From the point of view of a client, though, “design for testability” means they have to be able to make IronCow behave a certain way, and test that the rest of their application behave accordingly.

The easy way to make an API testing friendly is to put everything behind interfaces. This way, the client can replace your stuff with test objects. But for some reason, I don’t feel like adding this kind of complexity to IronCow. It’s a pretty small API, with an object models that contains less than a dozen of classes, and hiding everything behind interfaces would triple the number of classes, add a couple of abstract factories, and more generally confuse clients that would otherwise expect a straightforward API.

Therefore, right now, to use IronCow in a test environment, you can disable the “syncing” behaviour like this:

Rtm rtm = new Rtm(); // You can also pass in your apiKey and
// sharedSecret here but it doesn't matter.
rtm.DisabledSyncing();
// From now on, there's no requests being sent.

When syncing is disabled, the IronCow object model just acts like a “dumb” object tree. Setting the name of a task or adding a new contact won’t trigger a request to RTM. Instead, it will just modify the objects locally, as if it was just a classic simple in-memory object model.

Note that you can’t reenable syncing.

The problem with this is that although the complexity of the public interface stays the same, the complexity of the internal code increases. I find it doesn’t increase nearly as much as when I tried to hide everything behind interfaces though. The other bigger problem is that it’s more complicated for clients to do behavioural testing. For example, if they want to test what happens in their application when a certain action makes IronCow throw an exception, there’s nothing to help them do that… In that case, they have to mock the IRestClient class, and use it with their Rtm instance. There are helper classes and methods to build RTM XML responses, but it’s not what you would call super user friendly (check the IronCow.UnitTests assembly source code for examples of how to use it).

So is this fine? No? Should I bite the bullet, add interfaces, and make this simple API be 3 times bigger and more complex? Is there a third option?

One layer is a "dumb" wrapper around the public REST API, in way very similar to what FlickrNet does with Flickr’s own REST API. The second layer is a "rich" object model that exposes your tasks (and other data) through classes that stay in sync with the server as you manipulate them. This was done mainly with WPF applications in mind, enabling things like data binding and other reflection-based mechanisms.

IronCow is available on CodePlex.

A sample application that ships with IronCow is IronCow for Powershell. This is a Powershell snap-in that defines a few cmdlets that will let you manage your tasks through the command line! (if you don’t see the point, or think it’s lame, you’re obviously not enough of a geek) You’ll get to type command lines such as:

Get-RtmTask "dueBefore:tomorrow" | Sort Priority,Estimate | Export-Csv $Home\TasksToDoToday.csv

If that’s not cool, I don’t know what is.

This sample application is still a bit rough around the edges (understand: no installer – you need to compile and register the snap-in yourself, and no help file – you need to look at the code to know what parameters the cmdlets take!), but I’ll focus on that once IronCow itself is stabilized. Stay tuned!