Re: What Happens When a Nib File is Loaded
Re: What Happens When a Nib File is Loaded
- Subject: Re: What Happens When a Nib File is Loaded
- From: Erik Buck <email@hidden>
- Date: Sat, 12 May 2007 18:50:28 -0400
I don't know where "What Happens When a Nib File is Loaded" is in
Apple's documentation, but you might like this explanation:
http://www.stepwise.com/Articles/Technical/FreezeDriedObjects.html
Here is a short excerpt from "Cocoa Programming" Chapter 8 "The
Application Kit Framework Overview":
Archived Objects and Nibs
The encoding and decoding of objects is briefly described in Chapter
5 as one of the
conventions used by the Cocoa frameworks. Most objects defined in
Apple’s frame-
works can be encoded and decoded whether they are nongraphical
objects from the
Foundation framework or graphical objects like windows and buttons
from the
Application Kit. Encoding and decoding are frequently used to
implement copy-and-
paste operations, drag-and-drop operations, and distributed-object
messaging. When
interconnected objects are encoded as data into a block of memory or
a file, the data
is called an archive. One key to using the Application Kit
effectively is the knowledge
that user interface elements and their interconnections can be stored
in just such an
archive.
The objects stored in an archive are conceptually freeze dried. A
freeze-dried object is
an actual software object including data and code. It was running in
memory at one
time, but is now in cold storage. It can be decoded from an archive
and revived so
that it begins running from right where it left off at the time it
was frozen. In fact,
when a user interface is designed in Interface Builder, the file that
is saved is an
archive of freeze-dried objects. Interface Builder names files that
contain such
archives with the extension .nib. Nib originally stood for Next
Interface Builder, but
the term has become generic and now just refers to an archive of user
interface
objects. When an application loads a .nib file, the objects are
decoded to the same
state they where in when encoded.
Most object-oriented environments include a visual tool for laying
out user inter-
faces. Such tools usually generate code and resources which much be
edited and
compiled. Cocoa’s Interface Builder generates freeze-dried objects
instead of code.
This is an important distinction. Generating code is a static
approach, whereas the
freeze-dried objects present a dynamic solution. The static solution
mimics the
dynamic solution but lacks much of its underlying power. Freeze dried
objects retain
all their interconnections including delegates, targets, actions,
superviews, current
displayed values, and so on. It is possible to create nontrivial
applications entirely
with Interface Builder and run them in Interface Builder’s Test
Interface mode
without ever compiling.
Interface Builder could have been called Object Connector because in
addition to
positioning and sizing graphical objects, Interface Builder enables
the interconnec-
tion of objects. Interface Builder is not limited to editing the
objects that Apple
provides with Cocoa. New objects can be edited and connected within
Interface
Builder with varying degrees of sophistication. Any object can be
instantiated and
have outlets and actions that are set within Interface Builder. New
Interface Builder
palettes can be created to enable more complex editing and
configuration as well.
It is possible to write Cocoa applications without using Interface
Builder or any .nib
files, but loading .nib files is so convenient and powerful that
almost every applica-
tion uses them. Unless the programmer intervenes, Cocoa applications
automatically
load a main nib file when launched. The main nib file contains the
objects that
define the application’s menu bar. The main nib file for an
application can be set in
Project Builder’s Application Settings tab.
Nib Awaking
A problem can arise when objects that have been encoded into a .nib
file are
decoded. As an object is decoded, it might need to access a reference
to an object
that has not yet been decoded. How does an object know when during
decoding it is
safe to access the objects to which it is connected? The answer is
the –awakeFromNib
method.
When objects are decoded from a .nib file, the Application Kit
automatically sends
the –awakeFromNib message to every decoded object that can respond to
it. The
–awakeFromNib message is only called after all the objects in the
archive have been
loaded and initialized. When an object receives an –awakeFromNib
message, it’s guar-
anteed to have all its outlet instance variables set. The –
awakeFromNib message is also
sent to objects when Interface Builder enters Test Interface mode
because Interface
Builder actually copies the interface before it is run. Interface
Builder encodes objects
into a nib archive in memory, and then immediately decodes them to
create a fully
functional copy, ready to test.
Implement –awakeFromNib to perform any initialization that needs to
occur after all
an object’s outlets have been reconnected after decoding from a .nib.
.nib files can be loaded into an application multiple times to create
multiple copies
of the objects within the .nib. The multidocument architecture
described in this
chapter loads the .nibs that define document windows as many times as
needed to
create as many documents as needed.
The File’s Owner
When direct communication between objects within a .nib and objects
outside the
.nib is required, the .nib file’s owner provides that communication.
The file’s owner
represents an object that is not in the .nib file. Figure 8.10 shows
the Interface
Builder icon that represents the file’s owner of the nib being
edited. Connections to
the outlets and actions of the file’s owner can be set in Interface
Builder, but the
actual object that is used as the file’s owner is only specified when
the .nib is loaded.
FIGURE 8.10 Interface Builder uses an icon labeled File’s Owner as a
placeholder for an
object that is not in the .nib.
In many cases, direct connections between objects can be avoided by
using notifica-
tions and the responder chain. For example, an object decoded from
a .nibcan regis-
ter to receive notifications from within its –
awakeFromNibimplementation. Objects
can also send notifications to anonymous receivers or to the current
first responder.
Objects within a .nibcan use the shared NSApplication instance in
every application
by referring to the NSAppglobal variable or calling [NSApplication
sharedApplication].
.nibs are explicitly loaded into an application by calling the –
loadNibNamed:owner:
method declared in a category of the NSBundleclass. The category is
part of the
Application Kit. As a result, .nibs cannot be loaded by programs that
do not link to
the Application Kit, even if the .nibthat is loaded does not contain
any objects that
depend on the Application Kit.
The owner argument to –loadNibNamed:owner:is the object that is used
as the file’s
owner for the nib. Any connections made to the file’s owner within
the .nibare
made to the owner, specified when the .nibis loaded. Connections that
cannot be
made because of inconsistencies between the owner used when
the .nibis loaded
and the outlets and actions specified for the file’s owner when
the .nibwas created
are discarded. The –awakeFromNibmethod is also sent to the file’s
owner specified
with –loadNibNamed:owner:. The file’s owner is not technically part
of the .nib, but a
.nib’s owner can implement –awakeFromNibto perform any logic needed
after a nib
has been loaded. If several .nibs are loaded using the same owner,
that owner’s
–awakeFromNibmethod is called multiple times.
The application’s main .nib is loaded automatically by the
NSApplicationobject
when the application is launched. The NSApplication object itself is
the file’s owner
of the main.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden