Today I was writing some interceptors in Java, and I wanted to be able to filter the input based on whether it implemented a given interface or otherwise. Class<?> exposes a very handy isAssignableFrom method for this, but it doesn’t look very nice, so I tried to go for something a bit neater, like:
Neat, and much more readable. I didn’t quite make it there, but got close enough for my purposes, and had some (very little) deeper knowledge of generics inflicted upon me for my sins.
An application that uses WMI to check for USB drives attached to a PC.
Testing user interfaces is usually a pain in the butt. No matter how cool your UI is, it will often boil down to a brain-cell killing process clicking the same buttons over and over again. Thanks to the Geek Gods of .Net though, there are ways to automate this, and it’s not even that tough to do.
In this post, we’re going to use Automation peers to expose a button to a unit test, and have the test start the application, click the button, and confirm that the button does what it’s meant to do. We’re going to use MbUnit to write the test, and NBehave to make the tests nice and clear.
There’s been a project knocking around the back of my head for a while. I keep putting it off, doing some work on it now and again but never really settling down to really do it. This long weekend turned out to be one of those occasions; I’ve just finished playing Fallout 3 (Awesome game, the ending left a slightly bitter taste in my mouth though) and ended up with nothing to do. Visual Studio to the rescue…
If you ever worked on an application that requires Internet connectivity, you will have had to handle situations where the connection may be unavailable for certain periods of time. Sometimes you can get by that by trapping an exception; I know I have, though I still find that particular solution to be somewhat inelegant. What I wanted was some way to monitor the state of the connection and keep track of it. This way, if you need to send a message for example, you can have your application decide whether it should try to send it right away, or whether it should stash it away till the connection becomes available. This post is about how to determine whether a connection is up or down, and notify the application when the state changes. Continue reading
This week I found myself with some time on my hands, so I knocked up a simple object pool. It’s fairly standard stuff… you call Fetch to get something out of the pool, and Return to put it back. Fairly standard.
The call to Return felt a bit annoying. If we forget to call that, we end up leaking resources as we create more and more objects, or get an exception thrown at us. Not good. I wanted something like the using (whatever) syntax, which I think is the most awsome thing ever.
To do that, we’d have to ensure that all the items in the pool implement IDisposable, have a reference back to the pool, and call Return in their dispose method. This isn’t really feasible; for starters, it would tightly couple everything with the pool, which is, like, all sorts of bad. A far better approach is, in my opinion, to wrap the object being pooled to add whatever behaviour I need. Not necessarily a great idea if you don’t know what’s going to be pooled beforehand. Continue reading