Automated Zipping in Xcode

I like to automate everything. I'm a firm believer in the "one-click, build-all, distribute-all" type of solution.

Per Apple's recommendations, after you generate your .app file, you need to compress it by right clicking on the file and selecting, conveniently enough, "Compress." Not exactly automated. After doing some searching, I found this little gem:

• ditto -c -k --sequesterRsrc --keepParent "$PRODUCT_NAME.app" "$PRODUCT_NAME$revnum.zip"

Which, when I ran it on the command line (with $PRODUCT_NAME appropriately filled in), generated a perfectly acceptable zip file that I could submit to itunesconnect. But when I put the same command in my post-build script, I got an invalid zip file that itunesconnect would not accept. Ouch! The two files had different sizes; I'm really not sure what could have caused the problem (something in the bash shell, maybe?)

Luckily, I found an alternate gem:

• zip -r -T -y "$PRODUCT_NAME$revnum.zip" "$PRODUCT_NAME.app"

Now, I originally tried using zip before and it didn't work. the '-y' option is the key, as it preserves the symlinks. I won't pretend to understand exactly why that makes the difference, but the script does indeed now generate a valid zip file. Fantastic!

Unrecognized Selector Error

In case you get this:

2009-10-08 17:26:29.125 MyApp[5487:20b] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[HowToPlayViewController setDelegate:]: unrecognized selector sent to instance 0xd3dae0'

Remember to synthesize the property in question (in this case 'Delegate', which would require a 'setDelegate' selector if I were to hand-code the property). I like Objective-C overall so far, but there are a few quirks that bug me. The property + synthesize issue is one of them. You don't have to call @synthesize if you make the getter/setters yourself, but failure to do either thing should generate an error, not a warning like it does during compilation. I totally missed it.

Moving onto the Interface Builder

My student has been sick all week, so I haven't had an opportunity to continue on with lessons, which is great, since I didn't finish writing up all that he and I had talked about last time.

This time we'll talk about the Interface Builder (IB). The IB is an entirely separate application from Xcode and is used to visually create the user interface (whereas you would normally have to do it through code). The IB creates the .nib/.xib files mentioned last time and though IB is a separate app, you typically end up launching it by clicking on the .xib files that are in your Xcode project. In the case of a simple project, it's typically called MainWindow.xib.

Once in IB, you have four primary windows to worry about (sometimes more).

1) The nib list window -- this contains a summary of all the components of your UI.
2) Inspector window -- this contains the details of the particular component you're looking at. It has four tabs on it.
3) Library window -- this is were all the UI components come from.
4) The user interface window -- this is where you drag items from the library onto.

For the moment, I'm not going to go into intimate details. Each item will take a bit to get into. Try this, however. Drag some Library items (like buttons, labels, etc.) to the UI window. In particular, add a UIImageView item. Initially, it's a blank rectangle. But if you highlight the view and go into the Inspector window -> Attributes, you should see a drop down box called: Image.


You may not have anything listed in the drop down. In that case, return to Xcode and add a png or jpg file to your project (the Resources group is a nice place to put it), then relaunch IB. It should show up then. Select it from the list and you should then see the image in the UI window. You may need to play around with other attributes and the sizing of the window to get the image to look right.

If you go back to Xcode and run the app (assuming you created a basic Windows-based app), then image should show up. Fantastic!

Getting an image to display is trivial, as you can see. Adding buttons and labels is also quick and easy. However, getting them to respond to a user's touch is a different beast altogether. We will need to talk about IBOutlets and IBActions at that point, and those topics are for another day.

Auto Insert Closing Braces in Xcode

Just a side note... I find this very handy under Xcode->Preferences:

Automatically insert closing "}"

I don't know why it's not checked by default, but there you go.

Basics of Xcode

My buddy already knows the Mac well enough to move around and has installed Xcode before. I'm not going into the install process; the instructions are clear enough. After the install, you can launch Xcode from Developer:Applications:Xcode.app.

On first launch, you'll see the Xcode News; I usually uncheck the display again box. You can restore it from under the Help menu. Close it for now.


Click File->New Project. You get something like this:
Lots of options to choose from. In the selection column on the left, you can pick from iPhone OS and Mac OS X options, as Xcode is used to develop software for both platforms. We're interested in the iPhone OS section for now. Under "Library" you can produce a static library, which is basically a collection of code that you can create to re-use across multiple application and share with your friends and family. That's a topic for another day.

Under "Application," there are a variety of choices. They are all ways to quickly generate a foundation of pre-written code for specific needs. You could choose any one of them and by adding and removing the write code, create another one from the list. There is nothing special about any of the project templates other than the fact they generate extra code for you that you might have needed to write anyway.

That said, choose the "Window-based Application," click on "Choose...," name the project something like 'MyCoolApp' and save it. This should pop up:
There's a lot to look at. Here's the high level things we're concerned with:


Groups & Files is where the source code, resources, libraries and lots of other things live. You'll be spending much of your time in the Classes group. You add, move, and remove groups as you desire in order to best organize the project. A well organized project is a happy project.

The contents of whatever is highlighted here will show up in the upper, right side, dual-colored pane. Any files that you highlight will show up in the lower right side editor pane, including pictures and plists, but not the likes of xib/nib files.

It's useful to go backwards up the Groups & Files list, starting with Frameworks.

By default, the Frameworks group contains the basics: UIKit, Foundation and CoreGraphics. These libraries give you the basic tools to start writing sophisticated code. You'll end up using at least one thing out of each of them 99% of the time, so Xcode puts them there automatically.

Under Resources, you get a the MyCoolApp-Info.plist (or just Info.plist in some cases) and the MainWindow.xib. The plist is the property list for the application and is used to set, as would be expected, various properties concerning your application, including the name that is to be displayed on the iPhone (otherwise, your app would be named the same as your project, i.e. "MyCoolApp").

The xib file (called a 'nib' file, despite the spelling; Mac OS X uses nibs while iPhone uses xibs. Coding for the Mac has been around longer and the name has stuck, since nibs and xibs essentially do the same thing) contains "freeze-dried code." Without going into too much detail, it part of the system (which launches the Interface Builder app) where you can easily layout your user interface without having to write code. However, you will need to write code to actually get your nifty new layout to do anything when the user taps on the screen.

The Other Sources group never gets touched. You can look at the two files in it, but don't touch them. I may mention somethings about 'main.m' in a later post.

And lastly, the Classes group is where you will do the main bulk of your work (unless you create another group that you'd prefer to work in). Under the Window-base Application template, there are two files, MyCoolAppDelegate.h and MyCoolAppDelgate.m.

The .h file is a header file; it is in essence a public view into the code. If someone is interested in how your code works (as located in the .m file), they would look at the .h file (because the .m file is typically not available for viewing). The .m file is the source code itself and where all the work happens. You will have multiple .h and .m files in any app that is of reasonable complexity.

That's it for now. More coming soon, hopefully.