After about two and a half years, another update for
Rechnungs Checker has arrived. Most of the changes in the new version are tiny, so I never bothered to release a new version as the old one kept working just fine, but they do add up: a few UI tweaks here, a new file parser there, a 64bit binary, a new version numbering scheme there (I had to get rid of that idiotic zero in the middle) and an improved icon. Nothing earth shattering, but here it is.
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.
]]>
It has been quite a while since the previous UnicodeChecker update, a bit over two years in fact. Thus, people may have been left with the impression that the application is dead by now. That, however, would be quite far from the truth. The 
The updated Unihan data file format is a royal pain as it is is now delivered in a bunch of files instead of a single one which makes gathering the information much harder. To keep the a reasonably short launch time for the people who use Unihan, UnicodeChecker now reads those files in the background after launching. Which means that the application will be available right away but not provide Unihan information in the first few seconds after launching. And if you look carefully, you can watch a little progress bar as the loading progresses. The bad news is that this totally destroys the very clever and efficient scheme UnicodeChecker used previously which let it use Unihan without storing all of the data in memory. As a consequence memory consumption increases by an obscene amount (about 100MB) because of that.
A few more ideas and fixes for Earth Addresser have been released in version 2.3 that went online today.
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.
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.
It’s always a bad sign when you offer an update for one of your applications within a few days of the previous release. But, alas, that’s just what’s happening for Earth Addresser today to fix a memory problem which people with many addresses in their Address Book started to run into.
A little update to the wonderful GeburtstagsChecker has just been released. It fixes a problem with the computation of people’s ages that was somehow related to time zone differences. A lesson one should probably learn from this: Testing should include the use of different time zones just as it should include characters beyond ASCII.
]]>
As a user I always like it when applications are scriptable as it makes applications more useful in the sense that you it lets you use them in ways the developer hasn’t anticipated. As a programmer I am thus happy that Cocoa makes it rather easy to add basic scriptability to your application. In fact, for accessing and setting data in documents all you need are KVC complicant classes inside your documents and a scripting definition XML file.
