Lloyd's Lounge

I should start by saying that I am not anywhere near an authority on Xcode so some what I say here is probably wrong or at least not entirely true. It is just my own observations while trying to program for OS X.

Over Christmas, for fun I wrote the majority of the Drops Screen Saver. It was a great way to flex my coding muscles now that I'm in self-inflicted unemployment, plus it never hurts to expand one's skills.

Seeing how Xcode is the new and improved IDE for writing applications on the Mac it must be worth something so I gave it a wack (IDE stands for Integrated Development Environment, the application that developers use to write, test, and build code). Starting out learning Objective C is hard enough, but having to learn an entirely new IDE at the same time compounds the difficulty many times over.

I was completely out of my element. I'm a Java developer by trade so I was already at a disadvantage because I didn't know, nor could I really find any helpful documentation on, how an application's source should be arranged. Java has a concept of packages and where many Java IDEs differ in their approach to arranging source code my fellow developers and I had eventually come to use the Open Source style arrangement that worked so well with Ant, a Java build tool along the same lines as the old-school Unix make utility. This allowed us freedom to use whatever IDE we choose as long as Ant could compile the source in the end. Ant is so popular as a build tool for Java developers that many third party apps have been written to integrate it with a variety of IDEs so there really was no issue with this.

So, as I said before, when it came to Xcode I was completely out of my element. I had just "switched" to the Mac mere months before, I had no idea how applications were supposed to be set up. Xcode, despite having assistants to help you create your new project, wasn't much help at all in this regard. Oh I could set up a project just fine, I just had no idea what the different files and directories did. I imagine if I had any history with macintosh computers besides showing people how to print in my school's computer lab it might not have been so bad. The "Groups and Files" navigation within a project confused me to no end. What's the difference between seeing a file in under the "Implementation Files" folder and the "Classes" folder? What the hell is a NIB file?

To make matters worse I was trying to create a screen saver. The screen saver executable is completely different from a normal executable file and isn't something that Xcode's new project "assistant" knows how to set up. Eventually I got fed up trying to massage a normal executable project into a screen saver project and copied and modified by hand a set of project files I had from the source to a freeware Matrix screen saver (should be found here but it's no longer at the site. Looks like they just had a baby, congrats!). It was ridiculous, I had to go in with a text editor to change all these names and paths in the project.pbxproj file which was in a format I'd never seen before. It ended up working much better then I hoped so I never visited it again. It just seemed strange to me that there was no way for me to change these values within the IDE. Perhaps these settings were not supported by Xcode, I don't know. From what I recall they were things that needed to change to get the code to compile.

I also had problems with the general set up of the IDE. The process didn't seem to make much sense to me. When talking in general about IDEs, there seems to be two types of styles. One type is to have a very large window with all of the bits and pieces in different panels that can be re-sized and scrolled in and sometimes re-arranged. JBuilder does this and so does Eclipse. The second type is the method that Xcode employs; havinh lots of little windows floating about that you move around and place yourself. To make a completely arbitrary value judgement here, the second way is lame. Well, to be fairer, it drives me up the wall. I do like everything to have its own place, but there should be no way that one component obscures another one, especially partially. I should never have to resort to the mouse (or command-tab) to find out some information I need to know while editing code. It's a subjective thing, I know. It just drives me nuts (arr).

So by this point I'm already frustrated. I'm able to compile, so that's a step in the right direction. I even switched it to use Vim as its primary code editor which was a plus. I already mentioned the lovely documentation viewer in a previous post. Staying in Vim was looking tastier by the minute. Doing a little research I found the Unix command /usr/bin/xcodebuild. It takes Xcode projects and compiles them from the terminal. I didn't even need to have Xcode running any more, I could do all of my compiling in Vim. Plus, I'd be faster since the Vim's quickfix functionality would show me which line of code was causing the error. All I had to do was set up one line in my .vimrc and I was good to go:

autocmd FileType objc set makeprg=/usr/bin/xcodebuild

xcodebuild uses a standard way of describing errors so I didn't need to do any special handling. It was beauty and that's how I finished my Drops project.

So I have a lot to learn it seems. By the end I was starting to appreciate the standards that Apple has regulated to specify how an application source code should be set up even though I still don't understand what all the bits do. I just wish I could find some documentation on how it came to be that way and what each piece does. I'm sure all that will come with time and when I started this project I know I wasn't as proactive as I should have been about reading documentation and doing research. I'll be learning and reading quite a bit more now that I'm going to try and create a preference pane for the screen saver. I imagine this is where Xcode really shines. I've historically been reluctant to trust an IDE's UI creation tools; they tend to produce horrid, unmaintainable, and ugly code, but I'll give Xcode the benifit of the doubt.

On a related note, I think something that many languages would truly benefit from would be a essay on how to set up and work on a project in plain details. Not just what Xcode provides as a description of what each tool and widget does, but a document that teaches the philosophy of a given development method. Where each file is kept and what it does, how the build script should be created and more importantly, why we do it this way. I understand that this is also a subjective and personal thing, but I think at least showing a path, any path, would help students of the language. I have come across one such document for the GNU build system, the system that most Linux applications use. I think this is a step in the right direction but could be expanded some. Perhaps I will one day write an essay of this type on setting up Java application sources that use Ant, I'm not sure if one exists at the moment.

I'm still a complete newbie to using the Xcode tools, and to Objective-C and object oriented programming for that matter, so don't quote me on anything here.. But here's what I've been able to figure out (w/ the help of a Cocoa for Dummies book): A NIB file is the source for the interface of your app (windows, sliders, buttons, menus, etc.). The NIB extension stands for Next Interface Builder, as in NextStep. So "MainMenu.nib" would be your main interface builder file for your project. Much of OS X and its developer's tools came directly over from the Next operating system. So much so that most of the terminology, such as class/object names in Objective-C still retain the naming conventions from the Next days. For example, the "NS" in the class names NSWindow, NSObject, NSString - stand for NextStep as you might have already figured out.
As far as files being in the Implementation Files folder vs. the other ones.. That purple colored Implementation Files folder is a "smart folder". It just takes all your project files that end in a ".m" and puts a reference to them there so you don't have to search through your entire project to find them - it's dynamic, kinda like "smart playlists" in iTunes. As for the Classes folder - none of my tutorial projects seem to have any files in that one... so I don't know. Most of my source files just fall under the main directory (under the project name), and some go under "Other Sources", "Frameworks", and "Frameworks".
I totally agree w/ you on Interface Builder's.. uh.. interface. It sucks. I think the idea of the floating windows is to simulate how a Mac app would look - with different independently floating windows, instead of defaulting to full-screen. So maybe they think you ought to design the look of your app while working in that way as well. Whatever the reason, I think a better way might have been to grey out the rest of the desktop when the user opens Interface Builder, sort of like how Photoshop takes over when you open it in Windows.

oops.. I meant to say, "Other Sources", "Resources", and "Frameworks".

Cool thanks for the info! I actually bought an O'Reilly book on Objective-C but it's packed away in a box right now :) I don't think it has any info on Xcode though.
In any case I'm going to play with it a bit more to see if I can get the interface builder to work.