Thanks to those reports – the application’s specialist nature seems to ensure that UnicodeChecker’s users are generally both helpful and qualified – the bug in the algorithm could be fixed quickly. As could the other issues. To further support for Mac OS X.6, UnicodeChecker also starts supporting Sudden Termination with version 1.15.1.

The ‘star’ new feature of UnicodeChecker 1.15 is that it ships with files for the newly available Unicode 6 standard. It finally brings us emoticons (say hello to 😁: U+1F601 GRINNING FACE WITH SMILING EYES [interesting note: something in the blogging software decides to truncate the post at that character, escaping it seems mandatory]) and other, more serious, new codepoints. It’s highly unlikely that these codepoints are supported by any font on your Mac right now, but that’s the pleasure of living on the cutting edge.

The other major update is the IDNA. As the recently RFCified IDNA 2008 is quite a different beast in specification, implementation details, terminology and – potentially – also results than IDNA 2003, UnicodeChecker’s Utility now supports both versions (with the AppleScript interface defaulting to the new one). I’m curious where this development is going but the changes suggest that IDNA 2003 wasn’t the most precise and reasonable standard.

A further, technical, change is that UnicodeChecker now ships as a 64bit binary. Mac OS X.3 compatibility had to be dropped to make that possible. Crazy, I know…

All other changes are fixes for small glitches in the user interface as well as work on internal details.

I started Rechnungs Checker about seven years ago to learn Cocoa and simplify the mundane task of splitting up the phone bill because Deutsche Telekom’s website was (and still is) a monstrous mess which makes this task pretty much impossible if you like your sanity. Over time the application grew to support the online billing files created by other phone companies and Mac OS X matured a lot in the time: A lot of the code I had to write back then would be unnecessary for applications written today.

Many new APIs became available as well and Rechnungs Checker tried to keep up with those it could benefit from or be a better OS X ‘citizen’: Integration with the system-wide address book, Spotlight support or, in the latest version, support for ‘Sudden Termination’ and 512px icons. Over time the application has also grown from a PowerPC only application in 2003, to a Universal Binary running natively on PowerPC as well as 32bit and 64bit Intel machines today.

As Rechnungs Checker is a fairly simple application using standard Cocoa techniques only, those seemingly big transitions were not very complicated. In fact, I don’t think that any of them was particularly difficult from a technical point-of-view. However, those weren’t completely pain-free either as Apple’s developer documentation tends to be far less specific and complete than one would like it to be and XCode’s behaviour remains somewhat incomprehensible. If they put some more effort into those details, which are probably ‘completely obvious’ for the people who made up Cocoa and XCode, one’s sanity would benefit. None of these problems are terribly hard. But they may require a lot of fiddling to make the tools to just the right thing.

Just to add some examples to illustrate this: Think about version numbers and Info.plists. I, and, judging from other people’s projects I downloaded, many other people’s projects have severe difficulties in getting XCode to copy a new Info.plist into the compiled application, leading to things like version number confusion all over; Sometimes only a time consuming Clean action will sort that out properly. Then there’s XCode’s habit of linking the wrong libraries (just think about the pain that is Sparkle which requires you to have loads of different versions of it around for different projects, each, possibly, with different set-ups for languages, architectures and garbage-collection) which I still find unpredictable. An interesting bit of documentation-difficulty I ran into for this release was the following: My document class’ -readFromURL:ofType:error: received different type strings in the 64bit and 32bit versions, the UTI in the former and the name of the file type in the latter. Thanks to a helpful hint I learned that this is actually documented - but I would have to read the Mac OS X.5 Cocoa release notes to learn it. Definitely not the first place I’m looking at when making my application ready for X.6. Stronger cross referencing in Cocoa’s documentation or a non-useless search in the XCode documentation browser would help here.

Bonus material: Let me express how much I loathe VersionTracker/cnet or whatever they are called these days. They provided a fine service a decade ago but seemed to focus only on selling their company over and over again since. The result is a messy site with poor results. And a site which does not let me update my software listing unless I agree to them hosting my files. Which I have no intention to agree to. As a consequence I’ll have to hope that they steal the updated listing from iusethis or macupdate (let’s see whether macupdate manage updating the icon…) and I’ll be fairly sure that they’ll manage to only copy incomplete data or fuck things up otherwise when doing so. Because that’s the level of competence at which they operate. The same level of competence that turns ‘ä’s in my application description into ‘Ò¤’ - which looks a bit but not quite like a double UTF-8 fuck-up.

My idea would be that Safari lets you ‘share’ the pages you are currently viewing and those bookmarks then appear in the iPod’s Safari via Bonjour. But things don’t work this way. As Safari on the Mac lacks such a sharing feature, the URLs of the currently open pages have to be advertised by an additional application. As Safari on the iPod lacks Bonjour support, you can’t possibly see any advertised services in the application itself anyway (and implementing the bookmark sharing in such a way would require a bit of cleverness and background work because the standard advertising of web servers via Bonjour only works for services with addresses on your own machine).

So the hackish workaround is the following: You launch the Bookmark Advertiser application, it grabs the addresses of the web pages you are currently viewing in Safari and advertises them via Bonjour as a service of type ‘urlbookmark’. Flame then just happens to recognise that service type and display it as an openable service which will display the web page in Safari on the iPod.

This is very lightweight, only supports Safari, doesn’t automatically refresh and fails for URLs which are too long. Yet it does the trick for the applications I had in mind.

The most notable new feature, inspired by a user request, was to give users the option to not have all their addresses in a single placemarks folder in Google Earth, but to let Earth Addresser create a folder for each address label. For people on business travel this will make it easy to view only the home addresses of their friends or the businesses they have to visit for work, for example.

Nice side effects of this new feature were two-fold. On a technical level it forced me to change the internal code a little, so it can take into account address labels and create groups for them. Which in turn finally made me re-structure (well, the ‘re’ may be inadequate there) my atrocious KML file generation code into smaller pieces that are easier to handle. On a user level, this also let me implement a feature which I wanted for quite a while now: Earth Addresser can now deactivate certain addresses (those labelled ‘Old’ in English, German or French) in the KML file it creates by default. As I tend to keep people’s old addresses in my Address Book, this ensures that the old addresses don’t clutter things up when displayed in Google Earth.

Small improvements in GUI word capitalisation, keyboard navigation, accessibility setup and error handling made it into the version as well.

Said excuse came by one of our heavy Earth Addresser users suggesting we could display distinct icons for home and work addresses on the map. While I couldn’t figure out a way to make that look reasonable for contacts that are displayed with their address book photo instead of Google Earth’s standard drawing pin, it makes a good addition for all the other addresses, giving a bit of extra information right there on the map.

In addition to that, I figured out that Earth Addresser’s handling of situations without a network connection was rather poor. So instead of pretending to do the job and not getting anything done, Earth Addresser now stops trying immediately if there is an error and displays a message for that. I must say that the infrastructure NSError provides for that - complete with localised error messages - comes in handy here.

More technically, the problem was that I do create the necessary NSAutoreleasePool in the thread that looks up the addresses to make sure no objects are leaked. But I underestimated the amount of memory that gets autoreleased by running the web download. As I never noticed any memory related problems myself - not even unexpected swapping - I never gave much thought to that, having in mind that each download I do only retrieves a very small file and even with the string processing I do before and after it, only a few kilobytes of RAM should be needed.

But I didn’t have in mind that doing the download may cause many other things to happen. One of them apparently being that a few megabytes of my (virtual) address space get eaten by each download. And I only recover those once my autorelease pool is released - after my loop has finished running, that is. Which means that after a small four digit number of address lookups Earth Addresser would hit the virtual memory ceiling and give a nice crash somewhere in Apple’s code (it appears that gracefully handling a lack of memory remains out of vogue even in the basic libraries).

Had the original bug reporter not pointed out that he observed high memory usage, I’m not sure I could have made sense of the crash reports, but with this in mind, creating a new autorelease pool for each iteration of my lookup loop was an easy way to solve the problem. Phew.

Another issue that cropped up - and which I fail to understand - is the following: Currently Earth Addresser is available in French for everything but the readme. My understanding of Cocoa’s localised resource loading is that in this case the code

NSWorkspace * WORKSPACE = [NSWorkspace sharedWorkspace];
[WORKSPACE openFile:[[NSBundle mainBundle] pathForResource:@"readme" ofType:@"html"]];

should open the readme.html file in the next best language as the French version is not available. But somehow it doesn’t do anything as the path returned by the NSBundle is nil. Am I misunderstanding anything there? And how can I deal with such situations without needing to put a copy of the English file into the French localisation?

It turned out that doing the relevant lookups through Google’s Maps API isn’t too hard, and I eventually even got my act together to give that a little testing, revamp the user interface, get to know about a few cool use cases for the application and add an ugly icon. And thus, today, I present the ‘all new’ Earth Addresser 2 which will send your addresses around the internet - without name or other information attached to them - and create a KML file for them to use in Google Earth. A nice toy.

Next up, I’d like Cocoa minded people to discuss whether or not Apple’s Address Book framework is somewhat half-assed in the way it handles country information. For automated lookups having country codes is extremely helpful as they avoid problems with the many ways you can write a country’s name (just think about the many ways one could designate the country information for someone living in London: England? U.K.? GB? Great Britain? United Kingdom? Vereinigtes Königreich? Großbritannien? Großbritannien und Nordirland (UK)? … and that’s just the start of it).

Apple’s current Address Book framework does provide a ‘country code’ which works reasonably well. Unfortunately said country code is only exposed via the slightly obscure address format setting in the Address Book and - even worse - the list of countries supported by the framework is extremely incomplete. If you know people in poor countries, you lose. So there’s more room for improvement in this. Perhaps I’ll get to that at a later stage, perhaps I’ll just try to sit it out and hope that Apple improve their Address Book framework (haha!).