R – Cocoa – Suggested techniques for debugging binding problems between Xcode and Interface Builder

First, placeholder is a better word than proxy here.

Normally when you have an object in a NIB/XIB file it means that loading the NIB file will create that instance. The placeholder objects are objects that will already exist when the NIB file is loaded, and they appear inside of the NIB so that you can make connections between the objects that will be created by loading the NIB and the objects that already exist.

The file's owner, first responder and application are all placeholders.

The file's owner is placeholder for the object that will load the nib. All of the NIB loading methods take an 'owner' parameter. When you make a connection with the File's owner, when it's established at runtime, it will be connected to the owner object passed in to the nib loading method. Many UIKit and AppKit classes invoke the nib loading methods for you. NSApplication, NSViewController, NSWindowController, UIApplication, and UIViewController all load NIB files on your behalf. When they do that they pass self as the owner parameter to the nib loading methods. That's why when you use a view controller or a window controller you set the file's owner to your subclass and make most of the connections between your views and the file's owner.

The NSApplication instance is a simple placeholder for [NSApplication sharedApplication]. That's a global singleton and the icon in Interface Builder represents that global singleton. Loading the NIB file does not create a second NSApplication instance. By contrast, when a NIB file contains a window, if you load it a dozen times, you'll have a dozen window instances, but still one NSApplication instance.

The first responder is unique. Connecting an action to the first responder means that when the action is fired, it should dynamically be sent to the responder chain. The responder chain typically starts with the focused view, and continues up through the view hierarchy and includes some controllers and delegates. Each object in the chain gets a shot at handling the action. Menu items work great with the responder chain. If you had a menu item for "Make Bold" that is supposed to make the currently selected text bold, you might start by hooking that up to an NSApplication subclass, but then you'd have to know all of the situations that "Make Bold" applies, and how to handle them. A text view and an editable web view would probably need different code to handle "make bold" and bottling this all up in one object would get quite complex and wouldn't be very extensible. Instead you could connect the "Make Bold" menu item's action up to a makeBold: action on the First Responder. This would mean that when the menu item was selected, the focused object, or one of its parents that responded to makeBold:, would get the makeBold: message. Now many classes can implement a makeBold: method and respond to this menu item when they're in focus.

The bounds of an UIView is the rectangle, expressed as a location (x,y) and size (width,height) relative to its own coordinate system (0,0).

The frame of an UIView is the rectangle, expressed as a location (x,y) and size (width,height) relative to the superview it is contained within.

So, imagine a view that has a size of 100x100 (width x height) positioned at 25,25 (x,y) of its superview. The following code prints out this view's bounds and frame:

// This method is in the view controller of the superview
- (void)viewDidLoad {
    [super viewDidLoad];

    NSLog(@"bounds.origin.x: %f", label.bounds.origin.x);
    NSLog(@"bounds.origin.y: %f", label.bounds.origin.y);
    NSLog(@"bounds.size.width: %f", label.bounds.size.width);
    NSLog(@"bounds.size.height: %f", label.bounds.size.height);

    NSLog(@"frame.origin.x: %f", label.frame.origin.x);
    NSLog(@"frame.origin.y: %f", label.frame.origin.y);
    NSLog(@"frame.size.width: %f", label.frame.size.width);
    NSLog(@"frame.size.height: %f", label.frame.size.height);
}

And the output of this code is:

bounds.origin.x: 0
bounds.origin.y: 0
bounds.size.width: 100
bounds.size.height: 100

frame.origin.x: 25
frame.origin.y: 25
frame.size.width: 100
frame.size.height: 100

So, we can see that in both cases, the width and the height of the view is the same regardless of whether we are looking at the bounds or frame. What is different is the x,y positioning of the view. In the case of the bounds, the x and y coordinates are at 0,0 as these coordinates are relative to the view itself. However, the frame x and y coordinates are relative to the position of the view within the parent view (which earlier we said was at 25,25).

There is also a great presentation that covers UIViews. See slides 1-20 which not only explain the difference between frames and bounds but also show visual examples.