words by patrick

Good news: The Adium Time Zone Plugin is now out. I hoped to have it out by the end of the week, and (I think) I squashed the last two bugs that were preventing me from releasing, so off it goes! I made a page for it that I will keep updated with the latest version and other news. The BSD licensed source code is also there if you want to check it out.

I’m proud of the code. I’m not super proud of the model, in fact I’m sure it will become something that I will look back on one day and say “What the hell was I thinking?!”. I’ll probably refactor it in the future, it’s just that I’ve held off on releasing this for long enough, and with my finals looming I was scared that If I didn’t release by my self-imposed deadline of this week then I wouldn’t have time to work on it again in a while.

I hope you like it. I hope it doesn’t sink your Adium. Please send me some feedback if it does (or if it doesn’t). Thanks!

Last time I wrote about unit testing Adium, I was actually writing about unit testing Adium.framework - The public API that plugin developers and the like can use to tie into Adium. After talking with David Smith from Adium about some of my other SoC Ideas (such as improving plugin support) I realized that Adium’s API really shouldn’t be considered stable, and that using it as a starting point for unit testing is a bad idea.

That being said, I switched gears and started again, this time unit testing the application itself as oppose to the framework. In hindsight I guess I probably should have started here first, but being familiar with Adium.framework from my plugin development, I assumed that would come more quickly. Wrongo.

Anyways, thanks again to Chris Hanson, his short tutorial on getting unit testing up and running in cocoa apps helped me get started, and everything is now working as expected. When you build the test bundle, it launches the Adium build, executes it’s tests, quits, and reports any failures. Good stuff.

Here’s a bit of what my AIEmoticonPack unit test looks like:

- (void)setUp
{
	fileManager = [NSFileManager defaultManager];
	//NSLog(@"Current Directory is %@/", [fileManager currentDirectoryPath]);

	emoticonPack = [AIEmoticonPack emoticonPackFromPath:[[fileManager currentDirectoryPath] stringByAppendingString:EMOTICONSET_PATH1]];
	//NSLog(@"Testing Emoticon Pack: %@", emoticonPack);

	NSArray *fooarray = [emoticonPack emoticons];
	//NSLog(@"Foo: %@", fooarray);
}

- (void)tearDown
{
	// No necessary tear down.
}

- (void)testPath
{
	NSString *expectedPath = [[fileManager currentDirectoryPath] stringByAppendingString:EMOTICONSET_PATH1];

	STAssertEqualObjects(expectedPath, [emoticonPack path], @"Path wasn't right, should have been %@ but was %@", expectedPath, [emoticonPack path]);
}

- (void)testName
{
	NSString *expectedName = [[[NSString stringWithString:EMOTICONSET_PATH1] lastPathComponent] stringByDeletingPathExtension];

	STAssertEqualObjects(expectedName, [emoticonPack name], @"Name wasn't right, should have been %@ but was %@", expectedName, [emoticonPack name]);
}

- (void)testEnabled
{
	[emoticonPack setIsEnabled:YES];
	STAssertTrue([emoticonPack isEnabled], @"Emoticon Pack isn't enabled by default");
	[emoticonPack setIsEnabled:NO];
	STAssertFalse([emoticonPack isEnabled], @"Emoticon Pack is enabled when it shouldn't be");
	[emoticonPack setIsEnabled:YES];
	STAssertTrue([emoticonPack isEnabled], @"Emoticon Pack isn't enabled when it shouldn't be");
}

Hmm. I really need to write my own wordpress theme.

Adium devs look out, incoming SoC application!

With Google’s Summer of Code roaring up again this summer and me without summer job plans yet, I have dug into investigating one of the project ideas by my favourite OSS project, Adium. The project idea I’m looking into submitting a proposal for is that of unit testing much of Adium’s code. Currently Adium does no unit testing. Although my experience with Cocoa is growing to a point where I am fairly comfortable with it, my experience with unit testing doesn’t stretch as far. It’s not a difficult concept, however, so I decided to try and put it into action and see what I could come up with.

I chose to write a unit test for the emoticon classes, AIEmoticon and AIEmoticonPack. I choose these classes because they are documented, making understanding them quicker and easier, and because they aren’t ridiculously large. A good start for a unit test.

Creating a new test bundle target and the test classes were easy thanks to the fact that OCUnit is bundled with Xcode. As soon as I added the necessary frameworks though, I ran into a problem.

Adium.framework references FriBidi.framework, but because the unit test actually runs from /Developer/Tools/otest, the FriBidi.framework isn’t found in the @executable_path (where dyld is looking for it). Copying it to the build products Frameworks directory is no help since it doesn’t look there either. You could create a symlink to the build products directory but that’s rather messy and Xcode provides us with a much easier way of doing this: In the Run Script phase of the build process for your Test Bundle target, define DYLD_FRAMEWORK_PATH to the directory containing your referenced frameworks before the tests are run. Mine looks like this:

export DYLD_FRAMEWORK_PATH="${PROJECT_DIR}/Frameworks"


I spent several hours figuring this little detail out. Big thanks to both Peter Hosey and chanson of #macdev for helping me nail this down and explaining it to me.

I now have the beginnings of a working unit test of AIEmoticonPack. I’ve run into a new problem where certain methods cannot be tested since they require a running instance of Adium. I plan to address this by defining a base test class which instantiates such an Adium instance then changing my test case to inherit from that class. We’ll see how it goes.

Creating a Plugin for Adium is actually really easy. Here’s a quick guide through the proper set up to help get you started. There is even a skeleton project at the end.

1. Create a new Xcode project, choose Bundle -> Cocoa Bundle.
2. Add the following frameworks to your project:
   • Adium.framework
   • AIUtilities.framework
   • FriBidi.framework

   These are necessary if you plan on using or changing any part of Adium, which you will likely be doing.

3. Create your main class. It should be named something like ABMyTestPlugin. Your class should inherit from AIPlugin, found in Adium/AIPlugin. So you will need to import that.
4. Override the -installPlugin and (if necessary) -uninstallPlugin methods. The meat of your code goes there.
5. Override -pluginAuthor, -pluginVersion, -pluginDescription, and -pluginURL as well, to all return appropriate NSStrings. This isn’t required, but is good practice, so do it anyways.
6. Get info on the build target (your bundle). Change the build settings to add the following:
   • Other Linker Flags: -undefined dynamic_lookup
   • Wrapper Extension: AdiumPlugin

   Also, under the Properties tab change the Creator to “AdiM” and the set the Principal class to the name of your main class (ABMyTestPlugin).

7. Build your bundle, drag and drop it onto the Adium icon and test it out.

That’s pretty much all there is to it. More information on what you can do once you hook into adium can be found at the Map of Adium. It’s not really complete, but if you poke around inside the Adium.framework headers you will find that most of the methods are “self-documenting” and not to difficult to figure out. I’d also suggest looking at some existing plugins, like my Time Zone Plugin and the ones included within Adium itself.

If you’d like a skeleton of the Xcode project, grab it right here: AdiumTestPlugin.zip

You might want to also grab the Adium Source and compile your own frameworks since the ones included may be out of date.

Update: luapffuh pointed me to Toby’s guide to creating an Adium Plugin. Although mostly the same, his has bit more detail and is definitely worth checking out.

Apple’s transition from the PowerPC architecture to the x86 architecture is going rather well. All their machines are now intel-based, and have been for about half a year. Lots of people have already made the switch: 3/5ths of my family, myself, my dad and now my brother, are such people. This is in line with Adium’s usage metrics, which show that a bit over half of it’s users are now running Intel machines. My brother recently decided to pack up and move to China (WTF?) and in doing so bought an Intel Mac Mini to replace his not-too-old, 1.33Ghz 12-inch iBook G4. He was nice enough to let me, um, hold on to it, while he is off in the land of the rising sun far east.

With my recent purchase of a Core 2 Duo Macbook Pro (Thanks, ADC Student Discount!), I didn’t really have a huge need for it, but being a geek I of course jumped at the chance of picking up another computer. But, what to do with it?

At first I thought I’d install FreeBSD. A lot of my friends use some linux variant, but I recently read a cool essay on FreeBSD vs. Linux and decided I wanted to try out FreeBSD. Unfortunately, driver support for Apple machines isn’t exactly stellar in FreeBSD 6.2, and is missing a few little things, like you know, keyboard, trackpad, and wireless drivers. Next Idea.

Okay, fine, I’ll install Kubuntu. I’m kinda familiar with Ubuntu, and I’ve been wanting to play with it and KDE. Driver support was much better, but Linux on Apple laptops is still pretty rough around the edges. No advanced power management (no sleep), and graphical glitches in X/KDE really turned me off. I was going to install XGL/Compiz and play around, but rather than fight with it all night I just decided to do a fresh OS X install. I still wasn’t sure what I was going to use the machine for, but running Linux was never a necessity anyways.

So with a fresh OS X install, I christened the machine Spartacus. What now? Hmmm…

I’d always wanted a MythTV box, but I don’t really watch that much television, and it’d be annoying to have to set up a cable hook-up in my room and tether it to a laptop. But then I had a sweet idea: What about that Democracy TV app?

1. Democracy

I had never noticed before, but Democracy is a sweet app. I had tried it out briefly once before, but it was too heavy on ram usage and somewhat unnecessary to be have running all the time for someone like me, who then had no interest in net TV. Now that I’ve seen that there’s some good stuff out there and I have a machine I can leave running all day downloading stuff, I can tell it is going to be getting a lot of use.

If I’m going to be watching videos I’m going to need codecs, which reminded me of something else: Perian.

2. Perian

Perian is pretty much exactly what it says it is, the swiss army knife of video codecs for the mac. I don’t need to talk a lot about this, it’s just really simple and really useful. Hooray!

But now that we are talking media apps, what else is there out there? Ah yes, what about that songbird app?

3. Songbird

When I first tried Songbird when it was announced some months ago, I was totally nonplussed. “It’s just a black iTunes”. I was wrong. I’ve been using it more now, and it’s a pretty powerful app. The ability to automagically list, download, and create a playlist for all the mp3s linked to by a particular site while browsing around is awesome. It makes reading MP3 blogs so much more enjoyable. The tight integration of other features like lyric searching, wikipedia band info, and tour info make listening to music much more of an experience than a secondary, background activity. I love it, and while there are some annoyances (no minimize on command-m?!) I can’t wait for it to go 1.0. I still keep iTunes around to stream music from my main machine, but I don’t plan on using it heavily.

Was there anything else? Ah, yes.

4. Games

Wesnoth. Quinn. X-Moto. Just a few free, light games that I love to play when killing time or just to relax a bit.

That’s essentially it so far. I’ve now got a sweet little media machine that can sit beside my bed downloading music and videos (totally legally) all day that I can peruse at my leisure. It’s got some games as well to keep me amused. It’s light, it’s fast, it’s Mac OS X, it’s great.

Thanks James.