iPad Uproar!

Wow. Apple seems to have kicked over the beehive this time. Everyone's talking about the iPad, and I thought I would add my small voice to the roar.

My impression, it's a slick device that will be a lot of fun to use for media consumption and light content generation. I don't expect it to replace my laptop. I don't think it will change the world, but I do have an iPad-size hole in my life. Once I can get my hands on one, it will definitely be put to good use.

Interestingly, a lot of the day-after press that I have seen has been very negative. This isn't that surprising. The iPad, like the iPhone before it, is a very closed environment, and that doesn't sit well with some people. Still, some of the reaction seems to be a bit knee-jerk. And I wanted to address some of that criticism here.

It's not really mobile

OK, I'm not sure what people are complaining about. Yes, you can't fit it into your jeans pocket. Big deal. If that's what you want, buy an iPod Touch.

See, I remember the early days of mobile computing. Where you had a 25 lb. box, the keyboard clamped onto the front, and you had to heft it using a luggage-style handle bolted to the top. So maybe I have a different understanding of the word "mobile" than most folks.

Here's the thing. The iPad is smaller than my laptop. The iPad is smaller than a stack of text book. In many cases, I will be able to use it instead, greatly reducing the amount of gear that I need to lug around. To me, that's mobile.


It's just a big iPhone

Well, size has a quantity all its own. The additional screen real estate will allow developers to build applications that just wouldn't work on the iPhone.

But, even if it is just a big iPhone, so what. My iPhone has already replaced a lot of the work I used to do on my laptop. My biggest complaint, the screen is too small. Give me a bigger screen. Make it a little easier to browse the web and do email, and I'll be ecstatic. For me, one of the biggest features will be the ability to read full-page PDFs without having to squint at microscopic type. I print out a lot of research papers because I don't yet have a good alternative. If it's a two-column document I can stick it on my iPhone and zoom in on a single column at a time. That works OK. A bigger iPhone would let me comfortably read even the single-column articles.

And don't even get me started about the gaming opportunities.

So yes, a bigger iPhone would be nice.

A netbook can do everything the iPad does, and do it cheaper

This ignores the whole touch interface, the accelerometers, GPS and a host of other features. I think the touch interface is going to be a big winner here, once people actually get their hands on the device. It's a much more natural way to interact with software than the traditional mouse/keyboard combination, at least judging by the number of fingerprints I keep finding on my laptop's screen.

Being able to reposition the screen between landscape and portrait mode is also very nice. Even nicer, applications can detect this change and respond in interesting, useful ways.

It doesn't support a mouse?

You can buy the keyboard dock or link the iPad with any bluetooth keyboard (which makes Apple's tiny bluetooth keyboard suddenly very attractive). But you cannot link with a bluetooth mouse. This fact has made some peoples head explode.

Here's the thing. The iPhone OS doesn't have a mouse pointer. How would you even use a mouse. And why would you want to, when you can just tap the object directly.

A multi-touch interface allows a considerably wider range of interaction than most mice. Yes, long term mouse users may find the mouse more accurate--but, if you've ever watched a newbie use a mouse, you know that accuracy is a learned skill, not an inherent feature of the interface.

It doesn't support multi-tasking

Why is multitasking such a big deal? To me, multitasking is mostly needed when two or more applications are running on the same screen. The iPad is specifically designed to have each application take up the entire screen. And I think that's the right decision for devices like this.

So, as long as an application saves it state as you use it, restarts wherever you left off, and opens and closes quickly, moving between applications isn't a problem, even without multitasking.

Already, on the iPhone I can be writing an email, close the email-app to look up a word using a dictionary app. Copy the correct spelling, and reopen and paste the word. It's really quite seamless. I've seen bigger delays when switching tasks on multi-tasking machines. And there are definite technical advantages to only doing one thing at a time.

There is, however, one place where multitasking would be useful. Every once in a while, I find myself waiting for an application to download a big file. I would like to switch to a different app until the download was finished. It's not a big deal, but some sort of limited multitasking would be nice.

It doesn't support Flash

OK, this is the one complaint that I agree with. Mind you, I don't like Flash. I think HTML 5.0 is a much more compelling and robust technology. But, I also think it's ridiculous to expect everyone else to rewrite their web pages just because I have a new gadget.

The iPad is supposed to be a premium web-browsing tool. So, its annoying that it cannot be used to access broad swaths of the web.

iPhone App Released.

Hey,

So, my iPhone app has finally been released. My work had me develop this for them over Christmas, then it kinda fell between the cracks for a bit. But, it's out now and in the wild.

The app lets you take a picture (or select a picture from your photo album), and converts it into a "coloring book," where you can select a color then touch a segment to fill it in. You can turn on and off the segment lines, and adjust how much the underlying image shows through.

If you have an iPhone, search for "ColorIt!" in the app store.

-Rich-

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-