Everywhere you look these days you read about iPhone users screaming for multitasking. Here’s one counter opinion.

Yesterday I was trying to shoot off a quick text message. I was happily typing away on my iPhone 3G when the keyboard became unresponsive. You know what I’m talking about — type along and nothing appears, no comforting click, click, click of the keys. Then a familiar ‘vling!’ of the You’ve Got Mail variety, then several words of my typing spill forth.

That’s multitasking on the iPhone and I don’t like it.

When I’m actively doing something, anything, on my iPhone I want it to be all about me. When I’m done, or if I’m dull and slow and the wee CPU can get some work done without my even knowing, fine.

Maybe I’m the only one who doesn’t use or care about Pandora. I also don’t believe in human multitasking, so having just a single app open that I’m focused on and actively engaged with suits me just fine.

I just hope with whatever iPhone 4.0 brings us that my iPhone doesn’t forget about me and spend all it’s time on background tasks leaving my keyboard slow and chunky. It would really ruin the user experience, which should be all about me.

iPhone · user experience

I’ve been working on setting up a database for an iPhone app. I haven’t worked with sqlite before so it’s yet another new thing to learn. I’ve been going through a few tutorials on the web and was partway through this one when I took the advice of his sidebar at the end of Step 3 to keep my database definition in sql and have it built when the app compiles. He linked to this screenshot by way of a how-to, which unfortunately didn’t work for me.

First off, to find the build rules for your project, right click on Targets in xcode and select Get Info:

I also added a check to see if your db already exists to avoid build errors if it doesn’t. I decided to put it into an external file and execute that from the build rule. Here’s what my build rule looks like:

Uploaded with plasq‘s Skitch!

Here’s the bash shell script:

#!/bin/bash
cd ${TARGET_BUILD_DIR}
if [ -f ${INPUT_FILE_BASE}.db ];
then
rm ${INPUT_FILE_BASE}.db;
fi
cat ${INPUT_FILE_PATH} | sqlite3 ${INPUT_FILE_BASE}.db


Put it in a file (sqlbuildrule.sh, for example) and place it in your project directory and set it to executable:
chmod +x sqlbuildrule.sh

At the end of the rule, click the + below “with output files” and enter this:
$(TARGET_BUILD_DIR)/$(INPUT_FILE_BASE).db

The script will look for a .sql file in your project directory and build it with the output going to your target build directory.

If you need to edit the shell script or change the “with output files” setting of the build rule, note that the way you use the environment variables is different. The shell uses them as regular bash variables: ${MY_VAR}, where Xcode uses parens: $(MY_VAR).

No tags

I’ve started looking into development on iPhone and was a little surprised that unit testing was challenging. I found this project by Google that seems promising:
iPhoneUnitTesting – google-toolbox-for-mac – Google Code – How to do iPhone unit testing.

I’m going through Bill Dudney’s book from the Prags, which seems very good. You get up and running quickly, though it isn’t (and doesn’t claim to be) an in-depth resource on Objective C. I also got Daniel Steinberg’s Cocoa Programming book, which is a great quick start and good companion to the iPhone book.

Now I just need an iPhone…

iPhone