iPhone OS Filename Case Sensitivity

I hit a little snag while adding a feature to an iPhone app today. I added this code to load a logo to be displayed in a view:

UIImage *logoImage = [UIImage imageNamed:@"Icon.png"];

This worked fine in the iPhone Simulator, so I thought I was done. I loaded the app onto my iPod Touch, and it didn't work. Running in the debugger, I discovered that logoImage was being set to nil.

Why would this not work on a device, when it ran fine in the simulator?

It turns out that the iPhone OS filesystem is case-sensitive, while the Mac OS X filesystem is not case-sensitive. The actual name of the image file was icon.png, with a lowercase-i, so it didn't match on iPhone OS.

No big deal, but it's another reminder that you always need to test on an actual device before considering an iPhone development task done.

Introducing Kids to Programming

No time for a real blog entry today, but instead of nothing, here are some links to really cool toys that kids (and curious adults) can play with to learn about programming and multimedia:

Automator Service: Copy Current UTC Timestamp to Clipboard

Yeah, I know, you're probably getting sick of these Automator services. But I really do create a new one of these practically every day to make my life a little easier, and maybe some of these will be useful to others.

This one puts a UTC timestamp on the clipboard. The timestamp is an ISO 8601-format string like "2009-11-09T13:14:03Z". If you'd like a different format, type "man date" in Terminal to see how to change the output format of the date command in the shell script below.

Authenticating with Google App Engine

I've finally got around to doing some work on that iPhone application that I've committed to finishing this month.

On days I do a lot of work on the app, I don't feel obligated to work too hard on the blog, but I will post a little something about whatever I worked on. Today, I got my iPhone app to connect to a Google App Engine-based web site.

Without giving away too much, I'll just say that the iPhone app and the web site work together to provide a service to iPhone users. I put the web site together in a couple of weekends. I decided to use Google Accounts for authentication, meaning that to log into my web site, either via a web browser or via the iPhone app, a user has to provide a Google account ID and password.

If you do things this way, the server-side authentication stuff is easy. However, writing the client side is not easy, because the mechanism for authenticating with a Google account and connecting to a Google App Engine web site is not well documented. Luckily, I found a Stack Overflow question and answer that provided all the clues I needed to get my iPhone app working.

After using Google's API for implementing the web site, I'm growing increasingly frustrated with the Cocoa APIs. What takes two lines of code on the web side takes dozens of lines of code on the client side. Simple operations like connecting to a URL, downloading data, and storing it to a local database requires a lot of boilerplate code on the Cocoa side. It's not difficult, but it's incredibly verbose.

I should note that I'm using the Python API for Google App Engine. If I was using the Java API, then I'm sure it would be as grotesque as the Objective-C stuff.

How Does One Become a Good Programmer?

This is a quote I like:

The really good programmers spend a lot of time programming. I haven't seen very good programmers who don't spend a lot of time programming. If I don't program for two or three days, I need to do it. And you get better at it—you get quicker at it. The side effect of writing all this other stuff is that when you get to doing ordinary problems, you can do them very quickly.

That's from Joe Armstrong, creator of Erlang, in Peter Seibel's Coders at Work (which, by the way, every programmer should read).

This jibes with what I've seen over the years. Really good programmers don't treat coding as a nine-to-five job. It's something they want to do whether they are being paid for it or not.

A very easy way to weed out bad candidates when interviewing is to ask them about their personal programming projects. If they don't have any, then I'm pretty sure I don't want to work with them.

In this respect, programming is little different from other creative pursuits. You become a good writer by writing a lot; you become a good sculptor by sculpting a lot; you become a good musician by playing music a lot.

So go out there and write some code. That's what I'm about to do.

Automator Service: Scale Images by 75%

Here is yet another Snow Leopard Automator service: This one takes an image file and scales it down to 75% of its original size. This is great for screenshots, as all the text is still readable at that size, but you can put it in a web page or document without filling the screen.

Automator Service: Copy File Paths to Clipboard

Here's another Snow Leopard Automator-based service: It takes the Finder selection and puts the file paths on the clipboard, for easy pasting into command lines or scripts.

Mac Software for Software Developers

A fellow developer who is getting his first Mac asked me what software he should get. Here is a list of Mac software that I, as a software developer, find useful.

The "Easy Part" vs. the "Hard Part" of Software Development

In his essay "Where Do You Get Your Ideas?," Neil Gaiman relates a common situation faced by authors:

Every published writer has had it - the people who come up to you and tell you that they've Got An Idea. And boy, is it a Doozy. It's such a Doozy that they want to Cut You In On It. The proposal is always the same - they'll tell you the Idea (the hard bit), you write it down and turn it into a novel (the easy bit), the two of you can split the money fifty-fifty.

Computer programmers often find themselves in similar situations. Some well-meaning person says they have a Great Idea for an application. They'll tell the programmer the idea, and then all the programmer has to do is write the code to implement it. The Idea Person will get the bulk of the credit, but the lucky programmer gets to ride those coattails. After all, coding must be easy: it's just a bunch of stuff somebody has to type. The idea, the design, the inspiration - that's the hard part, right?

Usually, no.

Don't get me wrong: a great idea is a great idea, and a talented application designer is certainly worth more than the average programmer. But most people just aren't that smart.

And even if the idea is amazing and the designer creates a brilliant user experience, the bulk of the work still falls on the programmers' shoulders. If you take all the man-hours spent designing the iPhone, and all the man-hours spent implementing the operating system, frameworks, and standard applications, and making it all work the way the designers intended, I'd bet the latter number would be at least ten times the former. Maybe twenty times.

Programming is just plain hard, in a way that related software-development activities are not. And it is unforgiving. If a programmer makes a mistake, the program crashes or gives incorrect results. In contrast, if the UI designer makes a mistake, the consequences are not so dire; it just means the application is not quite as good as it could be.

It's usually a programmer who has to fill in all the details of someone else's grand design. When it's 2:00 AM, and the architects are snuggled in their beds, and some program is crashing because nobody thought about how to handle a certain condition, it's a programmer who has to decide how to fix it. Programmers make dozens of these kinds of decisions every day, while the Big Picture guys talk about golf.

I don't intend to put programmers up on a pedestal. Developing good software also requires good designers, good artists, good technical writers, good testers, good managers, and a good user community. But, please, don't insult coders by treating them like a bunch of glorified typists. Programming requires as much imagination, inspiration, and perspiration as any other creative endeavour.

Easy Gradient Backgrounds for UITextViewCells

When you create a table-view-based iPhone app, by default you get tables with plain white rows. But all the cool kids are making apps with 3D-ish gradient backgrounds. You want to make those kinds of apps too, right? This article explains how.

Syndicate content