Learning iPhone Programming

This last weekend I taught an Objective-C and iOS bootcamp to a group of students and faculty at WVU down in Morgantown WV. They have a cool “AppLaunch” project going on, to inspire students to write real applications on iDevices and encourage an entrepreneurial spirit (sorry, link is broken now), and they invited me down to kick off the technical portion.  Slides are available at my Free Talks for CocoaHeads page

A common question I got beforehand was “what’s the best way to get up to speed on this stuff?” That’s kind of like asking “what’s the best kind of pizza”. It all depends on where you’re coming from, where you want to go, and how fast.

If money is no object, take a Big Nerd Ranch class. In addition to teaching there, I have taken a number of Ranch classes from a bunch of different instructors, and they are all top-notch. The Ranch has a way of doing things that ends up with a really high quality product, enjoyable to both instructor and student. This will cost you a couple thousand dollars and take a week of your life, but you will be well on your way to iPhone programming studliness. Check out AnneKate Halsall’s Taming the Wild Dogcow tumblog for impressions and ah-has during the course of a class.

There are a number of video courses available. Stanford CS 193P iPhone Application Development is online. There is another set of materials from the Rose-Hulmn Institute of Technology for their CSSE490: iOS SDK Programming class.  Also, check the comments here, with some links to videos courtesy of Richard Smiley.

The next level down is books. I love books. I learned to program from books and magazines. Old folks may remember back in the day when computer magazines had pages of BASIC program listings. Keying those in and debugging the inevitable typos is how I learned to program. There are two books I really like for iOS programming: the Apress Beginning iPhone 6 Development: Exploring the iOS SDK by Dave Mark, Jack Nutting, Jeff LaMarche et.al.; and the Big Nerd Ranch iPhone Programming, the Big Nerd Ranch Guide by Aaron Hillegass and Joe Conway. I recommend people read both of them. If one book glosses over a topic the other covers in depth. Disclaimer: I’ve been the technical reviewer for the Apress Beginning iPhone books since the first edition.

What order to read them? If you’re strapped for time, read the Ranch one first. It’s short and to the point. Dedicate a weekend or a couple of evenings and type in everything. Then start working through the Apress book at your leisure.

If you’ve got more time, or you’re working over a longer period of time with other people, such as the Pittsburgh CocoaHeads Learn iPhone project, use the Apress book. It’s longer and wordier (764 vs 380 pages), but goes into topics in more detail. Some of the code is repetitious so you might not want to type in everything.

You’ll want some introductory books if you’ve never programmed before. The Aaron Hillegass Objective-C Programming: The Big Nerd Ranch Guide is very good. I’m partial to the Apress Learn C on the Mac by Dave Mark, followed by Learn Objective-C on the Mac the latter written by me and my hero Scott Knaster. This pair was designed to take you from “loops are cool!” up through Categories, Properties, and Predicates. If you already know C you can go straight into Learn Objective-C. If you already know how to program in something else and just want a quick brush-up on what’s peculiar to C, I’ve broken out the first two chapters of the first edition of Core Mac OS X Programming into a C Refresher. Learn Objective-C has an appendix on what weirdnesses to expect if you’re coming from other languages like VB or Java. I know I get frustrated when I have to wade through “loops are cool!” when picking up a new language, so it’s nice having different places you can catch the train.

Finally, take a look around your community. You may have an active CocoaHeads or an NSCoderNight chapter, or perhaps an iPhone programming MeetUp. If there’s not one now, start one! There’s nothing like having living breathing people to ask questions of, and to generally hang around with. You might discover one-off classes like what I did at WVU, or longer-term learning projects like what we’re doing at our local CocoaHeads.

The NeXT Chapter

I guess folks liked my little WWDC guide. I got more traffic from than than everything else around here gets, combined. Poring through my referrer logs I found one tumble about it from @alanQuatermain who said:

“I have a suspicion that someone at NeXT went around with a huge bucketful of awesome one day, because everyone I’ve met with a NeXT association seems to have a fair amount of it these days.”

I can’t argue with that. Over the years, everyone I’ve met with NeXT affiliations has been incredibly smart, and usually very kind and gracious as well. The funny thing is, NeXT wanted nothing to do with me at the time.

I remember when the NeXT cube first hit the mainstream press. BYTE Magazine had a cover story with the cube along with a pretty in-depth article about the tech inside. The 68040 processor, the DSP, scads of memory, the advanced OS and the toolkit. There was even a centerfold. I was in love. I wanted one of those machines. Who cares if the optical drive was slow.  It was mag-NEATO! 256 megs of space! Who cares if the machine was $10,000? Somehow I managed to secure funding for it. Now all I needed was someone who would exchange a pile of money for a black cube of 2-bit graphic goodness.

The first NeXT machines were only sold to educational institutions. At the time, around 1989-90, I was still in college,  fairly small liberal arts college in central Arkansas you’ve probably never heard of. Hendrix College was too small to qualify for any kind of educational co-op with NeXT. UCA, the larger school across town, was large enough though. A friend of mine was the trombone professor over there even had a visit from a NeXT sales representative. I got an invite, and was blown away. I really wanted that machine. Unfortunately, I was told point-blank that there would be no way I could get a machine for myself through regular channels.

Plan B. I’m a programmer. They had a developer program. I got an application and sent it in. I didn’t have a huge number of qualifications (Unix? Is that like VMS?), but I have programmed Macs since they first came out. I even had a couple of application ideas in mind, including a MacDraw-like diagramming app, and a medical database system similar to one I built in high school.

About a month later I got my rejection letter. I think I still have it in my archives somewhere. I purchased the developer documentation anyway so I could live vicariously. Boy did Objective-C look weird. And Display Postscript.

And so there ended my dreams of being a NeXT programmer. I spent the money on a Mac IIci with an ungodly amount of memory (maybe 8 megs?) to continue my Mac programming. A little while later at my first job I discovered we had some NeXT cubes. They were in the corners being used for print servers. But dutifully I got a login, worked through the programing tutorials, had some fun, learned a lot, and then went back to my day job of Unix and C because there was No Future in the NeXT technology.

Needless to say I was pretty happy when NeXT bought Apple for -429 million dollars. I now had all my favorite worlds in one place: Mac, Unix, and now NeXTstuff.

My first professional bug

Mike Ash’s recent Friday Q&A about signals mentioned SIGWINCH, the hearing of which always sends me down memory lane.  My first professional bug was centered around SIGWINCH.  By “professional bug”, I mean a bug that someone paid me actual money to fix during a period of employment.

I went to work for a company called Visix straight out of college in the early 90’s, which at the time sold a product called Looking Glass, a file browser much like the Macintosh Finder but for Unix.  Eventually Looking Glass would become the Caldera Linux desktop.  Looking Glass supported the major graphical windowing systems of the time: X11, Intergraph’s Environ V, and Sun’s SunView.  The image at the top of this posting is the only screen shot I could find of the version of Looking Glass I worked on running on SunView.  Notice the awesome desktop widgets at the top.  That was typical SunView style, so Looking Glass was pure awesome eye candy in comparison.

I was hired for the tech support team, and our duties were phone support (typically debugging network configurations and X server font paths) and porting Looking Glass to other platforms.  Being the Lo Mein on the totem pole I got given the old platform nobody wanted to touch any more: SunView.

SunOS 4.1.X had just come out, and Looking Glass would hang randomly.  It worked fine on 4.0.3.  My job was to find and fix this hang.  This was my first introduction to a lot of things: C, unix systems, windowing systems, navigating large code bases, conditional compilation, debuggers, vendor documentation that wasn’t from Apple, working in a company, and so on.  Luckily the SunView version didn’t sell terribly well any more because everyone was moving to X11, but there were a couple of customers bitten by this problem.

So what is SunView?  SunView is a windowing system: different programs run displaying graphical output into a window.  Nowadays that’s commonplace, but back when SunView came out it was pretty cool.  SunView was one of the earlier windowing systems,so it had a bunch of peculiarities: the biggest was that each window on the screen was represented by an honest-to-god kernel device.  /dev/wnd5 is a window, as would be /dev/wnd12.  There were a finite number of these window devices, so once the system ran out of windows you couldn’t open any more.

There was a definite assumption of “one window to one process” in SunView.  Your window was your only playground.  Looking Glass was different because it could open multiple windows.  Because of the finite number of windows available system-wide, we had to create the alert that said “You can’t open any more windows because you’re out of windows” at launch time, thereby consuming a precious window resource, and hide it offscreen.  It was the only way we could reliably tell users why they couldn’t open any more windows.  Glad I wasn’t the one that had to make this work in the first place.  I was just fixing Legacy Code.

The other peculiarity is that you never got window events.  Even in the 1.0 version of the Macintosh toolbox you could easily figure out if the user dragged the window, or resized it, or changed its stacking order.  In SunView you just got a signal. SIGWINCH, for WINdow CHange, and hence the memory-lane trigger.  The user moved a window?  SIGWINCH.  The user resized it?  SIGWINCH.  The user changed the z-order?  SIGWINCH.

With just one window that’s not too bad.  Just query your only window for its current size.  For us, though, we had to cache every window’s location, size, and stacking order.  Upon receipt of a SIGWINCH we would walk all of our windows and compare the new values to the cached version.  If something interesting changed we would need to do the work of laying out the window’s contents.

So, back to my bug.  It took me a solid month to fix.  All this time I thought I was a failure and was worried I’d get fired.  That would be embarrassing. It took so long to fix because it was part time work in amongst my other responsibilities, and also because it was difficult to reproduce.  Spastic clicking and dragging could make it lock up, but not reliably.  Using the debugger was pointless – a 4 meg Sun 3/50 swapped for two hours as dbx tried to load Looking Glass.  I ended up using a lot of caveman debugging.

The application event architecture we used is shown right up there.  Each window had an event queue (remember that one window to one process assumption) that held all of the mouse and keyboard events.  Upon receipt of new events (I forget if we got a signal for that, or if some file descriptor became readable), we would walk our windows: read each event, handle it, then move on to the next window.

I was getting some printouts, though, showing an window receiving mouse-downs and mouse-drags, but no mouse-up.  Occasionally I would see a mouse-up, with no mouse-downs.  Ah-ha!  The mouse-up was being delivered to the wrong window’s event queue, probably due to some race condition down in the system that didn’t notice the current window changed during the drag. The fix was easy once I found it : just merge the events from all the windows first, and then process them.  Happiness and light.

It was then I learned how expensive malloc is.  I malloc’d and free’d event structures, but performance was dog-slow, especially during mouse drags.  Caching the structures made life fast again.

Memories like these make me so happy with the cool tech we get to play with these days.