Understanding Xcode architecture

Discussion in 'Mac Programming' started by bahlquist, Oct 12, 2010.

  1. bahlquist macrumors member

    Oct 6, 2010
    I want to understand what code Xcode produces so that, if I wanted, I could write all the files for my program in a text editor and compile them from a Unix command line. In my simple example (using Interface Builder), I have a single button: an object of the class NSButton which I call buttonToPress, and some text: an object of the class NSTextField which I call numberToDisplay. Using Interface Builder, I make a new object of (my own) class BAFoo that tells what number to display when the button is pressed.

    Now, I have inspected the files that were made when I created this program, the only interesting ones being BAFoo.*, but I don't see where there is code instantiating the objects buttonToPress or numberToDisplay, nor do I see where the appropriate files (NSTextField.h and NSButton.h) were included. I am new to programming. Can you help me out? Feel free to correct me if I used the incorrect language.
  2. chown33 macrumors 604

    Aug 9, 2009
    Sailing beyond the sunset
    You can't duplicate Interface Builder's files using the command-line alone. Interface Builder doesn't generate code. Instead, it creates actual objects, changes their attributes according to the different UI elements you interact with, then serializes or archives those objects to an xib or nib file.

    When a program loads a nib or xib file, the opposite occurs: the file data is deserialized or unarchived and interpreted in a way that recreates the object.

    Some of the pivotal classes and protocols to do this are NSCoding, NSCoder, NSArchiver, and related.

    The advantages of separating the GUI's objects from compiled code should be obvious. First and foremost, it's not necessary to recompile any code in order to modify the appearance of the GUI. The extent to which the GUI can be modified can be quite large. It's entirely possible, given a suitable program design, to completely change the class of some GUI elements without any code recompilation. For example, buttons can be changed into popups, popups into radio-buttons, lists into tables, etc.

    If you're new to programming, this may all be over your head.

    Maybe I should have asked this first:
    What did you expect to see?
    Explain why you expected to see that.​
  3. bahlquist thread starter macrumors member

    Oct 6, 2010
    Well, I want to understand how the code/compiler works. It seems reasonable that I would be able to create a program that does exactly what I just created using Interface Builder, but without using Interface Builder. If I was able to do that (or someone did it for me), then I could examine the code and maybe learn from it. If some of my program is always locked away in .xib files, then I am missing a crucial part of the whole picture.
  4. foidulus macrumors 6502a

    Jan 15, 2007
    I think you are making this harder than it needs to be. In Cocoa you can code the entire interface just like you can in Java or almost any other language. Trying to reverse engineer the xibs is going to be much harder and you will get a lot less out of it than just coding your interface.
  5. bahlquist thread starter macrumors member

    Oct 6, 2010
    I am not saying that I plan doing this as a regular practice. I just want to understand what is going on.

    Has anyone here ever coded a simple program in with a GUI in Objective C and compiled it from a command line?
  6. Catfish_Man macrumors 68030


    Sep 13, 2001
    Portland, OR
    Sure. It's not hard, it's just a pain in the ass.

    NSWindow *win = [[NSWindow alloc] initWithContentRect:... styleMask:... backing:... defer: NO];
    SomeViewClass *contentView = [[SomeViewClass alloc] initWithFrame: ...];
    [win setContentView:contentView];
    [contentView addSubview: someOtherView];
    //more code to add other views, set autoresize masks, set positions, etc...
    [win makeKeyAndOrderFront];
    This isn't what Interface Builder is doing exactly though. IB-created objects will go through the -initWithCoder: path instead at runtime, since they're being "reconstituted", not created in the first place.
  7. gnasher729 macrumors P6


    Nov 25, 2005
    Look at the contents of main.m - just a call to NSApplicationMain. Read the documentation for NSApplicationMain and all the stuff it calls (which is a lot). At some point a .nib is loaded. Read what "loading a .nib file" means. Instead of loading a .nib file, you can do it all by hand if you like, by calling things like [[NSButton alloc] init...] over and over again, adding subviews to views to create the view hierarchy, setting selectors for actions and so on and so on and so on.

    What you could do instead: Write a program with a .nib file and make it run. Then add an "awakeFromNib:" method in the right place, just add an NSLog () first to see that it gets called. When that is done, remove _one_ object from the .nib file, then create it by hand in your awakeFromNib method.

    Definitely not from the Command Line, that is just pain without any gain. I've written code with an almost empty main .nib file, but not without one.
  8. bahlquist thread starter macrumors member

    Oct 6, 2010
    Thank you. All of the above comments were helpful.

Share This Page