iPhone Programming 101, part Deux
Sorry for the long delay since the previous column. Something called an ‘iPad’ I think, came out last week and I was in a rush to have something in the store on day 1.
This column is to either help software neophytes get going on their own great app ideas, or to at least illustrate the process for the curious.
We left off the previous story with our hero puzzled over something called “Objective-C” and “Xcode” with very little knowledge of what to do.
As with any craft, developers have a set of tools. With iPhone and now iPad programming the main tool is something called Xcode.
By comparison, Microsofties use Visual Studio while Android types opt for an open-source system called Eclipse. While Xcode and Eclipse are free, Visual Studio can cost upwards of $1000 depending what options you need.
So, what does Xcode do? It will simply let you input, organize, “compile” and test your program from beginning to end. Software input is via a fancy-pants text-editor. In just the same way that Microsoft Word has all sorts of little tools and utilities to compose a book, Xcode’s editor has equivalent tools for typing in a program. It has things that keep track of the specialized syntax needed for the code to minimize errors, color coding parts of the text to make it more clear, or linking parts with the documentation.
After typing in your code, then comes the moment of truth, “compiling.” Compiling is taking the human readable (well, for some humans at least) text and converting it, or rather, “compiling” it down to the binary codes the iPhone’s chip can understand. If you made an error, the compiler will typically flag it for you, in which case you fix it and compile again. (and again and again…)
Going hand in hand with the compiling process is something called “linking.” Authors rarely have to write every bit of code that ends up in their apps. There are common bits of code that handle the repetitive tasks such as searching some text for a special character, drawing a line on the screen or even creating a button in a dialog. These reusable fiddly-bits are located in things called libraries or in Apple’s terminology, frameworks. And fortunately much of the heavy lifting has already been done for us by Apple’s engineers. For example Distant Suns relies on 15 such frameworks including “Corelocation.Framework” (handles the GPS duties) or the UIKit.framework that encapsulates all of the user-interface gizmos and gewgaws.
If your code survives both the compiling and linking portion of today’s show, then it might be able to spring to life and do something amazing like print out “hello world.”
Yet another tool that comes free with Xcode is the iPhone simulator. It is a piece of software the looks like and pretends to be an iPhone sitting on your desktop. The simulator was particularly handy when trying to develop for the iPad, since only a few were blessed enough to actually have hardware before April 3. (Strange but true: I had racked up about 100 sales before the iPad was actually available).
The simulator is also helpful, as it tends to take less time to copy over and launch an app than real hardware. And it is a little less fussy as well.
That’s all there is! And over the course of developing your app you’ll become good friends with this compile-link-run process, invoking it thousands of times. And since commercial apps can easily run tens to hundreds of thousands of lines of code, well, you get the picture.
But now what happens if your program thinks it’s time to misbehave and works in ways you never imagined. Well, fortunately there’s an app for that. It’s called the debugger. Xcode’s debugger is very powerful and will help you trace down even some of the most obscure problems. In fact, debugging is as much a black art as actual coding is. Some of the things that Xcode’s debugger can do are to set breakpoints, dump memory contents and examine the internal nooks and crannies (just what exactly is a cranny anyway?) of your app while it is actually running. Breakpoints are like rest stops for your code where it can stop, sit down, and take a little breather as you examine the state of things. In Distant Suns, if Jupiter isn’t working right I can tell the debugger to stop it executing right before it draws Jupiter to the screen. At that point I can step through the code one line at a time until something just looks funny. As I said, very powerful, and sure beats the days when the “debugger” was nothing more than a print statement dumping text to a green monitor.
Well, that’s all for now. It can take literally years to really learn all the tricks a particular dev system has to offer. I’ve been using Xcode for two years now and still come across new things every week. But don’t let that scare you off.
Next time well give a shallow overview on actually writing some software in Objective-C.
