Re: File's Owner

FROM : Andy Lee
DATE : Fri May 23 22:55:13 2008

On May 23, 2008, at 2:49 PM, Johnny Lundy wrote:
> I decided to once again go verbatim through Cocoa Fundamentals. So 
> far it has been largely "uh-huh, yep", but the File's Owner, my 
> nemesis, comes up again.


I tried to answer your File's Owner and NSApp questions last week 
(copied below).  If you can indicate at what point in my explanations 
you start getting lost, I can try to explain better.

Again, I'm sensing a very fundamental disconnect, perhaps more 
fundamental than you realize.  Anybody can recite documentation, so 
there's no need to tell us that and no need to recite the 
documentation.  I think it would be more helpful to tell us at what 
*part* of the documentation you start to get lost, and what 
specifically is confusing about it, perhaps as relates to your other 
programming experience.  If the answer is that you draw a complete 
blank, then we shouldn't be addressing that issue at all; you need to 
step back to a more fundamental level and see if you feel fluent at 
that level.

--Andy


Here's my reply from last week:

On May 15, 2008, at 11:11 AM, Andy Lee wrote:

> On May 14, 2008, at 10:33 PM, Johnny Lundy wrote:

>> So it's the application instance. I don't understand what the 
>> application instance is. I can recite the documentation, which says 
>> it is a shared instance of NSApplication, also known as NSApp which 
>> is a global variable, none of which help me.

>
> To me this indicates a very fundamental disconnect, because what you 
> recited explains NSApp perfectly.  I can't tell where the disconnect 
> is, so I'll try to spell this out quickly.  No offense intended here 
> -- I honestly don't know where the disconnect is.
>
> You are writing a Cocoa application.  There is a class called 
> NSApplication that represents the concept of a Cocoa application. 
> That's the purpose of a class in an object-oriented language, to 
> describe a *class* of things conceptually.  Classes are usually 
> named for the thing they describe -- hence "NSApplication". 
> NSApplication handles the generic things that Cocoa applications do: 
> managing the main menu, managing the window list, dealing with mouse 
> and keyboard events, and so on.
>
> Cocoa applications create objects (instances of classes).  That's 
> what they do all day.  Objects get created, they send messages to 
> each other, they get dealloc'ed.  Thousands and thousands of 
> objects, all day long.  In your application there is one special 
> object that is an instance of NSApplication.  It represents the 
> application itself.  I repeat: there is an object in your 
> application that represents the running application itself.  There 
> is only one such object, and it is stored in a global variable 
> called NSApp.  That is what "application instance" means.
>

>> Why would someone bind to File's Owner? What specifically is it?

>
> Unlike most other objects in a nib file (First Responder being the 
> exception), File's Owner is not a specific object.  It is a 
> placeholder for an "owner" object that will be specified when the 
> nib file is loaded.  You edit a nib file knowing that it will be 
> loaded at some point in your program, and *at that future time* the 
> owner of the file (hence "File's Owner") will be specified.
>
> The file's owner gives your program access to the objects in the nib 
> file, through the connections you made to it in the nib.
>
> I think newcomers sometimes assume that when you load a nib you get 
> some sort of NibObject that you can query to get at the objects in 
> the nib, perhaps using the name you assigned in the nib file.  This 
> is an understandable assumption, but you don't get any such object. 
> You need to specify a file's owner for the nib (using the second 
> argument to +loadNibNamed:owner:), and you need to have constructed 
> the nib so it connects the file's owner to at least one of its 
> objects.
>
> --Andy