Something's up with the source code

First, I want to apologize to everyone whose emailed me. I'm sorry I haven't gotten back in touch with you. I've been incredibly busy the last few months, and I just haven't had a chance to look into the issue yet.

Having said that, let me backtrack and start at the beginning. Apparently (judging from the emails) there is a problem with the source code for my 2-part iPhone Productivity Application article in MacTech. And the code does not compile.

As I said earlier, I haven't had a chance to look at this yet. However, here is some background information. As you may know, MacTech accidentally printed the articles out of order. To make things even more confusing, I changed some of the source code between the first and second version. No, I don't remember exactly what I changed--just cleaned things up a bit as I remember. Anyway, I provided MacTech with two copies of the source code. Both compiled fine on my machine (though I didn't test them on others). I think they should be pretty compatible, but obviously I only tested the first set of source code with the first article, and the second set with the second.

So, if MacTech only has one version online, I'm not sure which one it is. Also, the SDK has changed somewhat since I originally wrote the code. It shouldn't have affected anything, but if you're compiling against a newer (or for that matter, an older version of the SDK), the code might not work. I believe I compiled it against version 2.0, but I'm not sure.

I will try to look into this more in the near future. If you've had any success with the source code, please go ahead and add a comment with whatever information you have.

Thanks, and sorry for the confusion.

-Rich-

iPhone Production Application Articles

Well, this is really old news by now. I wanted to post something about it earlier, but never seemed to find the time.

Apparently there was a mixup at MacTech magazine, and my two-part article on developing productivity applications was printed out of order. Part II came out in February's issue. I'm not sure whether Part I will follow in March.

However, there is an upside to this. The good folks at MacTech have released both articles in their entirety onto the web. So, I encourage you to check them out:

Part I: http://www.mactech.com/articles/mactech/Vol.25/25.03/iPhoneProductivityApplicationsPart1/

Part II: http://www.mactech.com/articles/mactech/Vol.25/25.02/iPhoneProductivityApplicationsPart2/

I'm also currently working on a third iPhone article, this time focusing on immersive apps, images and Quartz 2d.

-Rich-

Things that bug me about Objective-C (and iPhone development)

Ok, before I get started, don't get me wrong. Objective-C is still one of my favorite programming languages. But, as I continue to use it, I can't help but feel that it has some rough edges.

First, it has the same essential flaw as Java. It's not a pure Object-oriented language. There is this dichotomy between things that are objects and things that are not. For example, you cannot put a raw int or a c-style array into an NSArray--not without wrapping it first.

In some ways, this gives us a lot of power. We can drop down and write lower-level code when the performance demands require it. And, when working on a limited device (like the iPhone), those demands can be frequent. But I feel it's a bad design choice. It encourages mixing C and Objective-C, and I think the two programming styles are best kept separate.

I guess the biggest problem with Objective-C is really just C. Anytime I have to use C code, I loose many of the strengths and benefits of using Objective-C. I also expose myself to pointer and array-overrun errors. These are often the hardest to debug, since they may appear as mysterious errors in unrelated parts of the application.

And then we get to the iPhone. I love Xcode and I love the iPhone, but sometimes the two just don't play well together. Yes, debugger, I'm looking at you. I mean, really. What's up with the breakpoints? Sometimes they work. Sometimes they don't. Sometimes I can trick them into working again by cleaning all targets and rebuilding. Other times I have to reboot the computer. One time I could only fix the problem by reinstalling Xcode.

OK, that's it. Enough complaining for one day.

-Rich-

Lessons in iPhone Development

I've been spending a lot of time working on iPhone projects, and I've learned a couple of important lessons (the hard way).

1) Computationally intensive code runs slow on the iPhone. When it comes to raw number crunching, code ran 60 times slower on the iPhone than on my old MacBook Pro. If it takes one second on the simulator, it will need at least a minute on the phone.

Even worse, something that is so fast that you cannot even see it in the simulator may take several seconds to complete. This can cause all sorts of unexpected problems. The lesson here, test everything on the phone as early as possible.

2) The camera image picker is apparently designed to be used only once then thrown away. The photo library picker (even though they're the same class) doesn't seem to have this limitation.

I put both in tabbed windows, so the user could easily switch images. The user could return to the photo library picker as many times as they wished. However, the camera picker would only take a single picture, then it would only display the last picture taken. There seems to be no way to reset it.

Bottom line, use them as modal views and toss them. Instantiate a new picker the next time you need one.

3) Memory management is hard. Even when I thought I'd been careful, when I tested it in Instruments, I had leaks all over the place.

4) Using Objective-C serialization to save off large collections of objects can be very slow. Encoding the collection into a NSData object, then saving that can vastly improve performance. At least, it did for me.

I'm sure there's more, but that's all I can remember at the moment.

-Rich-

Where does the model go in iPhone MVC Apps?

I've just finished debugging a iPhone demo application for an article. I ran into an interesting problem, however.

Apple's documentation strongly pushes using a Model-View-Controller design for iPhone applications. That's good. Having struggled to debug large applications that didn't use MVC, I definitely see the benefits.

Here, the application should be separated into three distinct partitions. Roughly speaking, the model controls the state. The view displays information to the user, and the Control manages the other two.

In my iPhone app, the views are built in Interface Builder. Each view has its own UIViewController. But, where should the model go? Where should it live? How do I connect it to my view controllers?

Here's the problem, most of the views are instantiated in my code. I can easily pass in the model when I instantiate the class. My root view, however, is instantiated by the nib, secretly and mysteriously in the background.

So far, the best solution I've found is to access the root view in my application delegate as follows:

- (void)applicationDidFinishLaunching:(UIApplication *)application {

model = [[Model alloc] init];

id rootController = [navigationController visibleViewController];
[rootController setModel:model];

[window addSubview:[navigationController view]];
[window makeKeyAndVisible];
}

This is not as clean as I'd like, but it's better than the other options I've come up with. In particular, there's an intriguing Proxy Object in interface builder, which sounds like an ideal solution--but I can't make it work and I haven't found any documentation on it yet.

If anyone out there has any suggestions, please let me know.

-Rich-

Last Time Machine Update

Ok, this is the last thing I'll say on the subject (probably).

Forget everything I've ever said about hosting Time Machine backups on a shared drive. Yes, it's technically possible. But, trust me. Don't do it. Just don't. It's not worth the heartache.

Go out and buy a Time Capsule. Wireless backups that actually work! I've been running mine for two months now, and I haven't had a single hiccup. Much, much better than the shared drive option.

-Rich-

Object Lesson in Single Points of Failure

So, I bought my wife a new iPhone. Before we attached it to her computer, I decided to update all the software, and (of course) the machine choked and died. I tried everything I could think of, but I couldn't get it back up and running. We took it to the Genius Bar, and the genius in question tried everything he could think of. No luck. According to our tests, the hard drive was fine, but Leopard would not install properly.

I decided to re-partition and reformat the hard drive. But, before doing that, I wanted to make sure the user drive was backed up. I took the 500 G disk we were using for Time Machine backups and attached it directly to my wife's machine, and copied over her user directory. Then I partitioned, reformatted the disk and reloaded Leopard. Everything went well.

Until...

My lovely wife walked by, accidentally snagged her hand on the USB cable for the hard drive, and knocked it to the floor. Now it only fell a few feet onto soft carpet, but when I plugged it back in, it refused to mount and only made a strange clicking sound.

All our backups were on that drive. The time machine backups. The new backups I'd just made. Everything. All of it gone. Poof.

Now, I have secondary backups for my most important files. But, alas, my wife did not.

It's easy to feel over-confident when you have backups. But backups can fail. Whenever you only have a single copy of your data, even if it's only for a split second, you're at risk.

Lesson learned. It's not a new lesson, but one I seem to need to be reminded of from time to time. Single points of failure are bad.

-Rich-