Marc Charbonneau’s Blog

It seems like most Cocoa developers are doing unit testing these days. This presentation by Peter Hosey is a great introduction.

Unit testing from Peter Hosey on Vimeo.

I love it, indie iPhone developers bake cake representations of their applications. The iPhone development community is largely new and doesn’t seem to have the same sense of community as in the Mac OS X development world, so it’s great to see things like this pop up.

Earlier today I bought a new, thicker rug to replace a cheap thin one my Roomba would push across the floor unless I stacked furniture on top of it (in theory the Roomba is supposed to take the work out of vacuuming, but it doesn’t always work this way). Despite hearing about some problems with dark rugs, I decided to pick up a solid black one and see what happened.

It turned out to be as bad as I’ve heard. The Roomba completely avoided the rug, and wouldn’t work at all when placed on top of it. Worse, my initial idea of blocking off the edge sensors by sticking pieces of styrofoam inside didn’t work at all.

It turns out there’s actually an easier way to get it working though. Just put a piece of clear packing tape across each of the four edge sensors on the front of the Roomba. The tape diffuses the light enough to trick it into working. On mine, it worked perfectly. Of course, this will prevent the Roomba from avoiding actual drop-offs, so if you have stairs in your house you’ll want to come up with something else.

BWToolkit is a new Interface Builder 3 plugin that includes some common UI widgets that are missing from AppKit, such as preference windows and styled controls for the new Leopard HUD panel. If you haven’t made your own controls for these situations yet, this is sure to save you some time. I’m looking forward to seeing if this can replace some of my own custom code in Runner’s Log.

When I bought my iPhone last month I picked up a Griffin PowerDock to bring some order to the number of iPod charging cables I have. For $50, I’m a little disappointed. It didn’t come with an iPhone 3G dock adaptor (I should have read the box more carefully), although you can order one online for around $5 + S&H. Worse though, the iPod Nano 2G dock barely fits, so much that I was almost afraid of breaking it the first time I tried to put the iPod in. Plus, the whole dock is just slightly uneven on the bottom, so despite having a big rubber pad it tends to slide around a lot.

I’ve always been happy with Griffin in the past, I would have expected more from them. It would have been different if it was made Belkin or another mass-market company.

Runner’s Log uses a license file for registration, instead of a typical 20 digit serial number. With a license file, instead of sending users a code they type or paste into your application, you send them a file that contains the serial number along with any other registration information. Usually this is just a plain text file, although it doesn’t have to be.

Lately I’ve been thinking about the advantages and disadvantages of one method versus another. Here are the major points I came up with.

Advantages

• When done correctly, license files can be easier than typing in a serial number. Just drag the file onto your app, or double click it. On the other hand, if you only require one field for your license key, and handle copy/paste correctly, serial numbers are not that much harder.
• You can include whatever information you want in you license files. You don’t want to force the user to type in their name, email address, transaction number, but there’s no reason not to include these when you generate the license. It’s good to make sure to associate a license with a real life name or email address, to discourage casual piracy.
• License files (should be) very secure. I’m not saying you can beat software piracy, don’t believe anyone who tells you you can. What you can do, is prevent someone from creating a serial number generator for your app. Unlike shared keys or cracked copies, which you can fight by releasing updates and blacklists, a serial number generator can be especially damaging. As far as I know, using OpenSSL it’s possible to create a licensing scheme that can not be beat by serial generators.

Disadvantages

• License files don’t always fit with other company’s distribution models. Right now I’m talking with a company about localizing and selling Runner’s Log in Japan, both online and in a boxed software bundle with other applications. Although I’m sure I’ll work it out somehow, they assume applications use a serial number which can be sent via email or printed out. I would guess that some of the other promotional bundles, like MacZot or Mac Heist, work the same way.
• License files can go against the way users expect applications to work, or interfere with the way they store license codes for future use. I haven’t had any specific complaints, but it’s possible some people might be annoyed.
• It takes a little more work to implement license files. You need to associate the .applicense extension with your application, implement methods for loading external files, and make sure your online store can correctly send attachments in the registration email. In my case, I also ran into some unicode text encoding bugs I had to rush to fix. None of these require big investments in time; what I’m getting at is that the little things add up, and I don’t know any developers who wished they had more on their plate right before shipping 1.0.

No matter which method you use, there’s room to make your application stand out if you put in enough effort. I remember seeing a mock-up of a license file that was actually a generated .gif or .png image. The image looked like a key card, complete with the user’s information and the license key shown as a barcode (the actual license data could be stored in embedded metadata or headers for your application to read). If you use license codes, instead of random numbers and letters you could use a series of four or five letter english words.

For the most part, license files have worked well for Runner’s Log. However, there has been a small amount of overhead that I would have rather avoided. I’m going to keep this in mind for future projects; hopefully this will help new developers who might be in the same position I was.

I finally received my Gelaskins order in the mail this week. It looks cool, seems durable, but I ended up with some creases around the corners that drive me crazy when I’m holding the iPhone. The print itself is also kind of low resolution, when you look at it closely. Think inkjet quality, not photo quality.

I’m wouldn’t say I’m unhappy with it or it wasn’t worth the money, but I was hoping for a little more for a $20 sticker.

Most eBook readers let you download books online, or transfer them from your computer. Classics takes an entirely different approach by bundling only a select few books, each with its own cover and illustration drawn from scratch by artists David Lanham and Sebastiaan de With. The result (packaged together with a great custom UI, sound and animation) really makes the app shine in a way that no other eBook reader I’ve seen has attempted. It’s the interface you’re paying for though; all the books are public domain and are available for free through other eBook readers.

Currently 12 books have been packaged and included in Classics. Free updates will include more books in the future. My only concern is the possibility that after two or three more books the developers will stop development and move on to something new. A lot of recent talk about the App Store indicates that sales fall dramatically once your app drops out of the new and featured lists. However, both Phil Ryu and Andrew Kaz have told me via Twitter that they are in fact dedicated to continual updates, and a have a lot of great stuff lined up for it.

Another great UI component from Matt Legend Gemmell’s source code library. MGScopeBar is a “filter bar” style control, similar to the one found in iTunes and many other recent Cocoa apps. I wish I had this earlier in the year when I was developing the filter bar for Runner’s Log, it would have saved me a lot of work.

Fundware is just one announcement from United Lemur, a company founded recently by engineer Mike Lee. The idea is for new software companies to start out with a small (but high quality) offering, such as an iPhone App. Visitors to Fundware decide to purchase the application not just on its own merit, but also on the potential of the company itself. If successful, the revenue from Fundware will give the new company capital they need to get off the ground and start producing great full-sized applications.

Most “indie” Macintosh software companies (including mine!) are started with free time and a savings account, not investment venture capital or loans. This seems like a great way to help out developers who have great ideas, but lack the time or money to implement them.

The first featured application is Puzzllotto, United Lemur’s own initial iPhone offering. Apart from being the driving force behind some great applications, Mike Lee has some lofty goals for United Lemur and how it will impact the Mac software development community— I hope he’s successful.