Marc Charbonneau’s Blog

Cultured Code writes about designing the user interface for creating repeating items in their upcoming task management application, Things:

It seemed fine in theory. But after implementing and combining it with the underlying logic, it took us only minutes to discover that it didn’t work as expected. Not that anyone was able to tell exactly why. And that’s often the case when developing user interfaces. It just didn’t feel right.

Looking at the sheer number of rejected designs, it’s no wonder why Things is my favorite task management tool at the moment.

Great writeup from Daniel Jalkut on examining crash logs with the atos command line tool:

Many developers seem to think that gathering useful crash logs requires shipping a symbol-laden application, but aren’t willing to do so. The fact is, you can have the best of both worlds by shipping a symbol-stripped version of your application, but keeping a symbol-laden version on-hand for the developer’s convenience.

What am I getting at? Apple offers a tool called “atos”, which makes it relatively easy to map an address from a symbol-stripped application to a name in a symbol-laden version of that same application. As long as the two applications were built with the same sources and using the same build options, the addresses are bound to match up. It’s just the symbols that are “stripped” from the shipping application.

One of the changes I made to Runner’s Log recently is a small update to some drawing code to better match the new look and feel of Leopard. Since I’m still supporting OS X 10.4, I had to determine at run time what operating system I’m running under. There are a few ways to do this, but the best method I found was to use the Gestalt system call:

SInt32 version = 0;
Gestalt( gestaltSystemVersion, &version );

if ( version >= 0x1050 )
{
// New Leopard specific drawing code.
}
else
{
// Old drawing code.
}

Easy enough; see this Cocoadev page for more information, including checking for older versions of Mac OS X. If it’s just API calls in the operating system you’re worried about, you can just check the function pointer for a null value before calling it. See the Cross-Development Programming Guide for more information.

Mac OS X 10.5 Leopard: the Ars Technica review:

DTrace and Xray invite good questions. “How many files does my application open on launch?” “How many times is a particular function called?” “What does the memory usage of my application look like over time?” DTrace and Xray make the previously daunting task of answering these questions almost trivial and (dare I say it) fun. I can’t imagine any Mac developer seeing Xray and not instantly longing to sic it on his application.

A Quick Objective-C 2.0 Tutorial:

There’s a lot more ground to cover, but this should give you a good start. We can look at more advanced topics in future tutorials. The 64-bit runtime has some features that the 32-bit version does not, such as the ability to synthesize instance variables. All of the hardware Apple currently ships is 64-bit, but we’re a ways off from 64-bit being a majority of the installed base.

Remember that all of the new features in Objective-C 2.0 are optional. Aside from some lower-level runtime functions and hacks, anything that was valid code in Objective 1.x is valid in 2.0, as well.

Get rid of your code with Leopard:

I’ve been using Leopard for the last few months, and I thought I’d post a partial list of new and improved APIs which may be of interest to Cocoa application developers. I’m going to classify these in terms of what you can do with them, rather than by class-name or other such relatively obscure aspect, and I’ll include some screenshots where appropriate. Please feel free to add your own observations via the comments. I’ll stick roughly to the order used in the AppKit and Foundation release notes, which you should also read if you’re serious about getting the skinny on what’s new in Leopard.

From iBanjo, on the topic of distributed version control systems in small corporate development environments:

In 2007, Distributed Version Control Systems (DVCS) are all the range among the alpha-geeks. They’re thrilled with tools like git, mercurial, bazaar-ng, darcs, monotone… and they view Subversion as a dinosaur. Bleeding-edge open source projects are switching to DVCS. Many of these early adopters come off as either incredibly pretentious and self-righteous (like Linus Torvalds!), or are just obnoxious fanboys who love DVCS because it’s new and shiny.

And what’s not to love about DVCS? It is really cool. It liberates users, empowers them to work in disconnected situations, makes branching and merging into trivial operations.

Shocking statement #3: No matter how cool DVCS is, anyone who tells you that DVCS is perfect for everyone is completely out of touch with reality.

I’ve been using git, a popular distributed version control system, for a few months (and I’ll write about it soon).

Daring Fireball:

Long-term, within the next two years, if not far sooner, I feel certain there will be various ways for developers to write iPhone software. (In fact, in Gizmodo’s transcript of the same Q&A session with Jobs from the D conference, they quote Jobs’s response to the question of third-party iPhone development as follows (emphasis added): “This is a very important trade-off between security and openness. We want both. We’ve got good ideas, and sometime later this year, we can open it up to third-party apps, and keep security.”)

I’m looking forward to seeing what sort of options start to spring up once the iPhone is officially released. I had a few neat ideas for possible applications back when it was first announced, and I’d still like to pursue those.

It’s with great pleasure that I announce the 1.0 release of my latest application; Runner’s Log. I started work on Runner’s Log late last fall, when I was looking for the best solution to record distances and times when I went running. Looking at my options at the time, I realized I had a few neat ideas I didn’t see anywhere else, and so I began work on Runner’s Log.

Before posting this I spent a few days trying to think of any advice I could offer other developers, but I think if you spend a little time reading mailing lists and sites like CocoaDev, there’s not much anyone needs to add. Definitely start with a few core requirements, rather than try to come up with a laundry list of features that probably aren’t that important. Even the smallest of applications is going to take a lot of your time, especially when you start thinking about things like designing a licensing scheme, or making a nice website and storefront. Pay attention to your customers, and respond to any questions, comments or complaints they might have. Also try to make sure that all of the features of your application fit and work together in a nice way. Even if it’s something small, like the design of a toolbar icon, if it’s not done correctly it might detract from the genuinely good aspects of your application.

Most of all though, have fun. Take a break from your office desk every now and then and spend some time working outdoors, from cafes, or listening to some live music. It’s how I ended up programming a lot of Runner’s Log, especially parts that were becoming tedious or boring. I genuinely enjoyed working on it, and I hope some of that shows through in the application itself.

With 1.0 out of the way, it’s time to go back and fix some of the minor bugs that still exist. After that, there’s a lot I plan to add in the near future, so definitely check back in the future and send me an email if there are any features you would like to see.

One of the things I’ve been doing as I get ready to sell Runner’s Log is choosing a payment processing system. Since my expected sales don’t justify the cost and time of using a dedicated credit card gateway, I’m looking at services like Paypal, Google Checkout and Kagi, among others.

Doing some reading yesterday, I found a PDF from Global Talk Software comparing the popular options for OSX shareware developers. There’s plenty of good information, including estimated costs and income for different levels of pricing. It’s very useful stuff for anyone interested in selling a software product online.

If you’re in the same position, make sure you look closely at the technical details before you choose a service provider. Google Checkout, for instance, has very good pricing, but requires SSL encryption on your website to receive sales notifications (which you need if you want to automatically generate a license key for each sale). Since the payment details are handled on the providers side of things, there’s no other reason to have SSL encryption enabled on your site, and with other providers like Paypal you don’t need it at all. Purchasing an SSL certificate just to work with Google Checkout could end up costing you more than choosing another provider, even if they do have higher fees per sale.

One neat feature in Visual Studio I came across today is auto-incrementing build numbers. You can use this to avoid having to configure or write an external tool or version control system just (although you should be using the latter anyway).

To enable it, just open AssemblyInfo.cs in your project, and change the AssemblyVersion setting to [assembly: AssemblyVersion( "1.0.*" )];. Remove the [assembly: AssemblyFileVersion( "1.0.0.0" )]; line entirely; it doesn’t support auto incrementing, and you usually don’t need it in the first place.

The next time you build your project, Visual Studio will put its own values in for the build number and revision number. It’s not too important how it generates these; but if you’re wondering, it uses the number of days since Jan. 1st 2000 as the build number, and the number of seconds since midnight number of seconds since midnight divided by 2 as the revision.

SXSW 2007:

I’m searching my articles from last year regarding SXSW and I can’t find any documentation of one of the major discoveries. SXSW is the only conference I know where designers and developers hang out. Designers have design conferences. Developers have nerd conferences. SXSW has somehow convinced both parties to head to Austin and actually talk to each other.

It sounds like a good set of speakers are lined up, if you live near Austin. (via Daring Fireball.)