WWDC2004 Session 317

Transcript

Kind: captions
Language: en
so at the end of the week your your
brains are probably filled with lots of
ideas about how you might use some of
the new api's that have been discussed a
lot of the new technology that's been
demo'd and what i'd like to do today is
talk about the tool that hopefully
you'll be using one of the tools anyway
that hopefully you'll be using to
implement some of your new ideas
interface builder since this is
announced it sort of an advanced session
I'm assuming you you're comfortable with
interface builder what I want to do
though is focus on part of interface
builder that I think up until recently
has been fairly unutilized or
underutilized until recently because if
you went to the quartz composer session
today or the QT kit session the other
day you saw some great interface builder
palettes that have been created also if
you look in flash developer / extras /
pallets on your DVD you'll see a number
of new palettes that have been created
by teams outside of the interface
builder team and what that means is
basically well to some extent i didn't
know that these other teams were working
on these pallets but more importantly it
means that these other teams did this
without the help of interface builder
team and in particular they'll be using
basically the same process that we're
going to be talking about today so again
if you have an opportunity to see or
look at the slides from those previous
two sessions or say one of the cocoa
binding sessions you'll see some
interesting new palettes that have been
created and as well as look on your disk
so John was going to introduce me but
I'm Chuck Fleming manager new manager of
the IB team and again what we want to
talk about today is interface builder
and how to extend it
make it more powerful and extend it by
creating your own pallets so you should
I guess first of all I ask why would you
want to write an interface builder
palette what does it do for what does
that do for you and first of all it
gives you a very convenient way to get
your objects in the hands of your
developers in a way that they can use
those objects to build applications and
customize those objects to fit the
application that they're building you
can have of course two different sets of
developers your internal developers
developers in your company or your
colleagues here in a university setting
but if your objects that you're creating
our innovative enough or interesting
enough or useful enough you may actually
consider number two which is go ahead
and sell these things as object where
and I think I've listed on the screen
one company that's doing that producing
some very nice pallets so you might take
a peek at the website and check out what
some other folks are doing and the third
reason if you if you've gone to any of
the cocoa binding sessions you know Coco
bindings is introduced was introduced
last year and is very exciting
technology that's been displayed this
year as well particular in the quartz
composer session this morning terrific
use of bindings was as shown in the
setting of interface builder palette so
third reason why you might want to write
appellate is to take full advantage of
cocoa bindings for your custom views
with in interface builder the only way
really to expose your bindings at this
point is to implement a pallid so very
quickly topics we're hoping cover number
one building and debugging palettes sort
of getting things going quickly step 2
some additional pallet task that's we're
going to talk about how to make things a
little bit more fully functional add
some features that you would expect to
have your inspectors fully working maybe
undo support tooltips things like that
third and fourth topics a little bit
miscellaneous collection of topics here
are some tips not entirely related to
palettes but they touch on topics that
you should know as you're writing palace
or playing with nibs in general and then
very quickly i'll just give some
performance suggestions okay so how do
you make a pallet you use the two tools
that two of the tools apple provides
Xcode we are going to provide you with
an enhanced template project template
for specifically for making pallets it's
a significantly improved over the one
that's currently shipping that's in the
disk image that will be available for
download at the end of this session and
then interface builder itself because
you're going to assemble the pallet
graphically and also assemble the
inspector graphically and that's what
interface builder is all about
assembling you eyes graphically so the
first thing we're going to take the very
simplest case how many of you guys have
built a palette before okay a smattering
but not overwhelming which is good
because even though this is advanced
topics i'm going to start with the real
basic stuff and it's very easy to do so
hopefully i won't bore the advanced
users here too much so we're going to
start with the template that we're going
to provide and then we're going to make
some modifications to the three classes
that get generated with the template
which is the palette inspector and view
class itself so i'm going to bring John
Hef whose newest member of the IB team
he's just joined us recently and he's
going to help me do some real quick demo
so we're going to do a lot of switching
back and forth and just try to focus on
a few things as we go so the first thing
John's just going to show us you know
sort of a very basic process of getting
started with the new template and John
one thing that I don't think we
mentioned was could you just tell folks
where that template live that temple is
going to be on a disk image that we're
going to provide to you at the end of
the day it will be available for
download and also in the file system
well we're going to actually get the
template to work with interface builder
you're going to need to put it in your
home folder in the library okay let me
just go ahead and show you in the finder
we're going to step through the the
template lives in home library
application support apple developer
tools project templates standard apple
plugins in here we have our IV palace
wewt 2012's that's a long path but it's
also the place where the standard xcode
templates live so if you're familiar
with that it's the same place except
starting in your home directory so i'd
like to go ahead and introduce you guys
to the wwc 2004 template for building
interface builder pallets so i'm gonna
go ahead and launch xcode and create a
new project now since we have that
template living in that folder will be
able to see it here in the standard
apple plugins so i'm going to select the
IV palette WT 2004 and create a new
project named widget so our new project
here on the screen it's going to include
everything we need to do to get started
building an interface builder palette
the most important thing to notice about
the the project is that it's been
divided into two targets we have a
widget target in a framework target the
widget target is going to hold our
interface builder palette which is going
to be everything we need to configure
our our object that we're exposing
through interface graphically where
while the widget framework is everything
that application needs to consume the
widget at runtime so let's go ahead and
take a look first at the widget
framework I'm gonna go ahead and expose
the target membership here so you can
see exactly which files belong to which
groups so in our framework folders all
the files that by default belong to the
widget framework and here we have a view
object that subclasses from nfcu so
we're going to use this to provide a new
view accusers and also in our palates
and our pilot folder we have two
interesting classes of nodes we have an
inspector that we're going to use to
configure the pallet graphically to
configure the view graphically and a
palette it's going to hold the view so
that users can drag and drop it into
their projects
so with this I'd like to give it back
the Chuck to continue the presentation
okay can we get the flies again okay so
very quickly what was generated for us
three classes the widget class which is
a view that's going to pier on your
palette the inspector which is going to
be the files owner for the inspector nib
file and the palette which is sort of a
controller object is also the files
owner for the palette nib that got
created for us we'll look at those in
details in a second so again widget
that's the view object that's going to
go on the palette and by by default it's
the subclass of ennis view when we
switch over to looking at non view based
palette objects you're going to have to
change that yourself to make it whatever
class you want it to be in we did them
again that's the view that you're going
to put on your palette it has the
template creates a skeleton
implementation of three methods for you
that you do need to fully implement and
it with frames and it with coder and
encode with coder and it with frame you
need because that gets called when your
view first appears on the pallet ni b
and that gets loaded lazily so it
doesn't happen automatically it will
happen say for example the first time
you click on the tab that represents
your palette in the palace window and I
be and it with frame will get called so
any initialization you'll do there the
nitwit coder encode with coder are
needed because for example when you drag
your widget off the pallet in ib into
your design window we're going to
archive that object and put it on the
pasteboard so in code with coder will
get called there and then we drop it in
the design window it'll get unarchive
and so a nitwit coder will get called
and finally for example when you save
your nib file with the new object in it
that object will get freeze-dried again
or archived and so in code with coder
will get called so you need to implement
those three methods and again since this
is an advanced or advanced session I'm
assuming you guys know about coding and
some of the standard app kid and
foundation
techniques what else was created would
you palette that's a subclass of IV
palette and basically the most important
to take home point on this one is it
should be the files owner of the widget
pallid nib in there again skeleton
implementations of a couple of methods
finish instantiate this guy is primarily
used when you have the non view case
when you have an object that you're
going to put on the palette which is a
subclass of ennis view but you need to
associate a visual proxy for that object
so that you can graphically manipulate
it even though it's not of you normally
you do that association in finish
instantiate and we'll show you the teeny
bit of code you need to make that happen
and then also the inspector class name
by default a reasonable choice is given
there that isn't what you need then you
can certainly modify that the inspector
class is created for you that's the
subclass of ib inspector it's the
attributes inspector for your widget and
again it should be the files owner of
the inspector nib okay again here's the
stub implementations that are created
for you in it okay in revert and it is
probably where you want to load the
bundle that contains your inspector nib
file in co or sorry okay and revert
mirror each other revert is going to be
called by ID and give you the
opportunity to pull information from the
inspected object and insert it into the
UI your inspector and okay does the
opposite when you get when you trigger
the okay action you'll be responsible
for pulling information out of the UI
and pushing it into the object that
you're being expected so these guys are
trying to keep things in sync and so in
the back here heads you should be
thinking cocoa bindings so this is the
old style it works fine think in terms
of cocoa bindings as you go forward
because this is a synchronization issue
based
let's see what else couple of nib John's
going to show us those in just a second
basically the palette is where you
assemble what's going to appear in IV in
its pallet window files owner you're
going to have to change that because we
couldn't do that for you in the template
and the inspector knit itself that's
where you're going to inspect or
assemble the widgets that will get
extracted and then put in the inspector
in interface builder is running and
again the files owner i'll mention this
several times files owner needs to be a
setup set appropriately right so John I
think you were going to just give us a
quick look at those nib file okay so
let's go ahead and try to make this a
sample project run a bowl with interface
builder and the first thing we're going
to do is we're going to fix those files
owners like Chuck mentioned so I'm going
to open up through the files that i'm
going to show you now which are the
widget pallet nib and interface folder
and next we'll do the widget inspector
so in the widget palette viously we have
the files owner in one window is very
important that the files owner has this
custom class set to be a widget palette
also the files owner needs to be
connected to the to this palette view
right here and we can see it's connected
this palette view is what's going to be
loaded into the interview they spill
their palates section over here and
we'll be modifying that later let's also
open up the widget inspector and make
sure that it's files owner is set to be
an instance of widget inspector also we
need to make sure the files owner is
bound to the widget fitted to the widget
inspectors window so now we have our nip
set up and will be ready to move on
shortly Chuck exercise okay so that's
sort of the the minimal setup and now we
just want to add a tiny bit of code so
you can see that well we have a
functioning pallet at this point so
John's going to do a real quick
modification to the code build it load
the pallet and see that it really is
sort of functional so back to the demo
okay so we have our palette here and on
our palate we'd like to place a widget
view so what we're going to do to do
this is put in an NS custom view they
were to change the custom views custom
class to be a widget now at this point
we have everything that's needed to get
a widget loaded into interface builder
but unfortunately our widget doesn't
paint itself so we wouldn't be able to
see it so we're going to modify the
widget scales and it was generated for
us by the template and we're going to
include a draw rect method so in the
draw method we just want to make it
visible for now so I'm going to go ahead
and choose the blue color and go ahead
and fill our clip rectangle with blue
now from here we can build a project
and we wind up we want to go ahead and
make sure it gets installed in the
correct location so I'm going to go to
my to go to our home folder move to
libraries frameworks library framework
going to framework frameworks and here's
our widget framework and then also we go
two pallets will see that we have our
widget palette so let's go ahead and go
back to interface builder and let's go
ahead and load up our widget palette so
in interface shoulders preferences its
last tab is the palette tab we can
choose to include our our palette here
here's our widget palette i'm going to
select it and it's going to load up in
interface builder at this point we can
create a new nib and our widget is fully
functional and ready to be dragged and
dropped into new applications so that's
all we have to do to get a view on to a
pallet chef and also the inspector looks
like he did command one yep so we can
see in the inspector that interface
builder is aware that this inspector is
expecting a widget object and if we were
to have edited our inspector nib the
properties would appear that ok back to
the client please
okay so I want to kind of move on to the
non view case which is really not much
different from the view case just a
slight modifications but before leaving
the view example I wanted to point out
that on the shipping panther and i'm not
sure if it was earlier but certainly
panther and tiger if you look at on your
hard disk ian flash developer / examples
/ interface builder you'll find a nice
fully featured sample project called
progress view pallet that illustrates in
some more detail the process of getting
a view based object on a pallet ok so
again heading towards the non view based
object case before i get to their what i
want to do is just mention something
that's probably obvious but when you
assemble an application and you're
bringing things off the pallet that say
your palette objects into the
application and building it designing it
and then you save and build at runtime
of course your application needs to have
access to the code for those pallet
objects so clearly one way to do that
would be you've got the source code to m
and H for your custom views you could
distribute those but that would get
pretty tedious probably a better
approach is to make sure that the
classes for objects on your palette and
associated objects that may be needed
are wrapped up in a library or sorry a
framework and so one of the things our
new palette does is it make that job
easy for you certainly customizable but
it will create the framework for you and
install it in convenient location as
well as the same for the palette as John
showed so what we do with the framework
is it will end up installed until the
library frameworks and the palette gets
installed in till the library palette
okay so back to getting an object on a
pallet where that object may not be a
view based object or a subclass of NS
view so it requires a small change to
the nibs and some small code monkey
asians so the templates going to make
that easy John's going to show us again
in detail some of these things but what
the palette project does for us the new
project is it sets up three different
targets one for the framework one for
the palette and an aggregate target ten
sets of several new groups to organize
your code in a reasonable way
establishes build dependencies for you
exposes the headers that you might need
it provided create some files to support
undo implements the or gives you a
palette table in which you can store
some other information like tooltips
things like that so John I guess you're
going to show us some more of the
details then about what we actually give
you in this template and by the way I
should mention I'm old goswami from
universe filter team helped us out in
designing and building this this project
so this is a big help it's much superior
to the shipping one so here we have
another Xcode project generated from our
template this is we're going to use
we're gonna use this project to put a
non view based palette object onto a
palette and we will see that again where
art project is divided into two targets
a palette for interface builder in a
framework the framework includes the
object that we're going to place on to
the interface builder Palace which is
here a random number generator and the
palette folder a group contains all the
stuff we need for interface builder to
let us edit our graduate or objects
graphically so it's like the previous
project we have an inspector and we have
a palette and we also have the niche
generated for both the the inspector and
the palette again we also have Bill
dependency set up in this so there's a
palette requires the framework to build
this way the random number generator
only lives in one library and interface
builders women need both the palette and
the actual random number generator in
order to include those anger projects
whereas application developers will only
need your framework to use your random
number generator so you want to show the
command
so we show that we could we can see
those projects those dependencies here
by looking at one of our targets in the
inspector and we can see that the random
number palette requires the random
number framework I also showed the
dependencies on which which files belong
to which target if you would fetch sure
so in the the framework is all the coke
like that like I said all the files that
belong to the framework which
applications are going to need we can
see these two files belong to that and
if we look at the interface builder
palette will see that all the rest of
files belong to the individual or cosmic
Center facial they will need this code
in these nibs in order to edit the
object graphically in its runtime and
also if you could disclose the undo
support as well so we will provide birth
sorry couldn't ok so when an object is
being edited in interface builder we're
going to take snapshots that object when
you tell us to when we know that you're
that your inspector is about to head its
object and these IV class description
files expose the property for the object
you want to have snapshot at runtime so
for example for a random number
generator we're going to take a snapshot
of the men value the max value and the
frequency attributes which are the
instance variables of the random number
generator and so when the user presses
undo we'll be able to swap back to old
values and swap in as the user modify
things and presses on do so these
classes are key to implementing I do
support and interface builder okay that
could define please
okay so as we mentioned earlier you've
got a non view-based object like a
random number generator you want it on
the palate you need to graphically
manipulate it so you need to assign a
proxy view to it very simple process
you're going to instantiate to the
object and then you're going to
associate a view with that object so
John's going to quickly show us where we
do that in the code so it's interesting
to think of how we can put a non
view-based object into an interface
color palette since the palette contains
a few objects so we go out to look at
our random number palette which I'm
opening interface shoulder now we see
that we have this are here representing
a random number generator this is what
we want the user to see in the interface
builder palette when they're using our
palette that we're generating for them
however we inspect this we'll see this
in NS image you not a random number
generator so what's going on behind the
scenes is in our palate up in our palate
classes finish instantiate method we're
telling our base class to associate a
random number object with that image
view so the so our base class which is
the IV palette is going to know that
when the user drags one of these images
that when he deposits the image onto his
object browser he really means to
deposit a random number generator and
not the NSM HBO that he initially
dragged so that's how we're able to put
non view-based objects into palettes and
have the IV runtime manage that for us
ok next two slides ok so before going
any farther there is a very nice example
again that shipped with answer a little
and tiger that you might want to take a
look at that shows you in addition to
the tips and tricks will show you today
some additional features that we won't
have time to get into for example some
supporting drag and drop onto your
objects that in fact gives you a nice
example where you might need something
done before the instantiate object which
is where we just did that mapping
between the view object and the non view
object or the view proxy and the non
view objects sometimes you need to do
stuff before finishing fancy eight and
one of the things is for drag and drop
support so you will implement your and
knit method and do that there so a place
to look for some some other very good
tips is / developer
sample interface builder and look at the
busy pallet example okay so at this
point we we have the bare minimal
functionality and we want to go on in
and show what's involved in making your
inspector fully functional I'm sure you
have a pretty good idea what we need to
do supporting undo and redo which
hopefully John's given us an indication
that that's pretty trivial and then what
about working with cocoa bindings hey
John ok so we've already seen putting an
object on to a pallet twice now let's go
ahead and take a look and see how the
inspectors work I'm going to go ahead
and open the inspector nib that was
genitive was generated for us and we had
modified and in the inspector you'll see
that we have properties reflecting what
was in on do support we have a text
field for setting the maximum and
minimum value along with the frequency
of a random number generator will see
that each of these has an action that's
bound to the files owner through his o
each of these three text fields has its
ok method bound to the targets owner so
when you finish editing either the text
boxes the files owner which is the
inspector is going to get the ok message
and no to push the properties that are
reflected in the inspector to the object
that is representing you'll also notice
that each of these texts feels is
connected to the files owner via outlets
so the files owner knows where to read
the values from let's go ahead and build
our project now
like we did with the previous project
and make sure that it gets installed in
the correct location quickly we can note
while it's building that in the random
number inspector in the ok and in in ok
and revert methods where we're pushing
the properties from the view to the
object and from the object to the view
we can see it it into ok method we're
telling interface builder to the object
will change this is the point when
interface folder is going to use that IV
class description that you generated to
take a snapshot of your object for an
archiving the future to implement undo
so now that our projects built let's go
make sure it's in the correct location
which again is in your library
frameworks folder there's our random
number generator and let's also make
sure we've got the talent and our
palette so back in interface builder we
can go to the preferences we can choose
palettes we can press add and select our
random number palette so in the random
number pal let's go ahead and actually
utilize this in Xcode i'm going to
create a new project and we'll make it a
sample will use the cocoa template for
an application and we'll call it random
harness so since I random harness is
going to want to use our random number
generator we need to import the
framework that we generated with the
random number project so we're gonna add
that to our project so in a hour library
in library frameworks we're going to
grab random number framework we're going
depend on that and let's go ahead and
put a random number generator into our
nib file so in our resources we're going
to go to the main menu did
okay we should start that back up so in
our main menu so we got to grab the
random number generator again so here we
go and in our nip that we just generated
were going to grab one of these random
numbers and like we said we associated
random number generator with the Senate
image view and when we drop it we're
going to get a random number generator
okay so to utilize this let's go ahead
and put some graphical elements on our
window to expose what's going on with
the random number generator I'm gonna
put a text tool here and two buttons put
a start button and a stop button and
let's go ahead and configure our random
number generator with the inspector that
was shown earlier so let's say it will
have a min value between 0 100 and let's
go ahead and make it fast so we'll have
the frequency 2.2 so if we set the stop
buttons action to be stopped on the
random number generator and do the
equivalent for start and we're going to
go head and use cocoa bindings tell the
text field to bind to the value that's
exported by the random number generator
so tell us actually able to get its
value
now it looks like we have a bug yeah we
should be able to see random number
generator here and choose random number
here are we running tiger I don't think
so no that's probably our problem that
is our problem so the latest release of
interface builder you can choose other
optics besides NS controllers the bound
2 for cocoa bindings so when you go
ahead and use your latest copy of Tiger
that you'll provide with you'll be able
to bind to over this random numbers
random number I bar for your text field
display the value is automatically but
with the older version we're not allowed
to do that so that's yeah we should have
been kind of surprising that there's no
object controller here so we've added
preliminary support so that you can bind
directly to model objects and not just
controllers so unfortunately though it
looks like we're running a version of
Panther here so okay go back to the
slide okay so what did we just do well
we really didn't do anything we had this
all pre can but basically the steps that
you would need to do as John pointed out
you've got the inspector you're going to
drag some text fields or graphical
widgets in there you'll take the
inspector which is the files owner and
hook up and set up outlets to point to
those widgets so that when the revert
method gets called i should say when the
revert message gets sent otherwise John
will scold me so when that message gets
set the revert message that we can get
to those objects in the inspector and
pull the values out and insert them into
the inspected object and then you also
want to set up your actions your okay
actions so that when say you do
something in the inspector you trig
enact trigger an action which will then
get sent to your inspector object and
the result is your inspector object and
wants to take the values from the UI and
push those into the inspected object
that's basically what what you'll need
to do okay undo support is very easy on
you make slight change to your ok mess
and add a IV class description file now
the template that we provided has done
that for you in fact here's John
actually showed us this as he was
looking at the inspector implementation
but the highlighted text shows you how
basically to support undo you'll want to
call that second line or have that
second line implemented for every object
that happens to get changed when you're
doing the inspection and then the class
description file again you just list the
instance variables the names of the
instance variables that you want to
participate in undo if you have a class
that has a bunch of I bars and only a
small subset and obviously you want to a
little performance enhancement is just a
list of ones that need to participate
okay inspectors and cocoa bindings so as
I mentioned earlier we've got this okay
and revert method thing going on that
keep things in sync and that's precisely
what Coco bindings is good at doing for
you without writing those those those
methods implementing those methods so it
works very well with on on Tiger with
you sorry nan view based objects
interface builder is have been around
for a long time it much earlier than
Coco bindings so that means there are
pots impossible edge cases when you're
working with view based objects in
particular we do some caching of the
images that might make you work a little
bit harder to get things to refresh when
you implement undo and redo but
basically it should work there might be
a few edge cases so you might have to do
a little tweaking so I think John you
were just going to show us the example
what's involved what's what's left in
your project after you use the cocoa
bindings approach for an inspector so
like Chuck said bindings are a great
thing to use in inspectors because all
you have is one to get set mappings
keeping the objects in sync so here
instead of having an ok and revert
method in
slightly different instance of the
random number generator project instead
we just have set value we're overwriting
the key value coding for our class to
push the values from the inspector back
to the object and we have on do support
here by telling like just like we said
in okay we're telling IV this object is
about to change so we can take a
snapshot and save it for later so really
now has eliminated all that getting set
code and both the okay and revert
methods more inspector and instead we
just have this one set value method
which is a short three lines okay so
normally you see the people bring up the
project with the file merge so you know
the okay and revert methods are now gone
there were no instance variables left
and you're down to a minimal amount of
code okay that's fine okay just a few
additional details where does ib look
for pallets where should you put the
pallets it looks in a bunch of places
but the places we recommend till the
library pallets till the developer
pallets classes that you want to expose
you know the main class that you've put
on the pallet plus maybe some auxiliary
classes make sure those are mentioned in
the palette table file tool tips when
you're in the palette window in ID
itself and your mousing over objects in
your palette you can specify tooltips
you do that also in your palate table
one thing I did mention on the slide is
the image that represents your objects
on the palette that you click on you can
specify that in the palette table file
okay very quickly I just want to mention
a couple approaches to debugging your
palettes and then a couple of topics
that may be useful while you're
debugging palettes but also may be
useful in general to let you modify how
things look depending on whether you're
running in ib or whether or not you're
running in ivs test mode so first of all
debugging well if you're from the old
UNIX world then you're
old friends you know terminal Emacs GDB
still work great okay so you always a
fallback but if you want to do at the
xcode way xcode now provides a very nice
way to debug your palettes you've got
your palate project you're working in i
sorry xcode has a facility for assigning
a custom executable to your project and
basically the custom executable you want
is interface builder so when you launch
the application your custom application
will be interface builder you're in your
palate project you set breakpoints in
the appropriate places or reasonable
places for example in your inspector
class name finish instantiate ok revert
any reasonable places you want to see
this code being executed or not
something's going wrong why then simply
start gdb in Xcode your and load the
palette so that makes gives you a nice
graphical environment in which to
actually debug your palate ok the other
two questions can you determine if
you're actually running in ib or not
well you can just basically ask does
your widget class for example responded
selector is in interface builder I be
defines that in a category on nsobject
so you can simply see if and the
implementation is highlighted here so
you can just test do your respond to
that and if you're in interface builder
but maybe you want to know whether
you're in test mode or not maybe you
want to do some drawing differently so
you can see you know what what state
you're in you can simply ask in its
application are you in test interface
mode so that's a method that's made
available through IV application
editions which is a public header ok
so you're going to switch gears just a
little bit now and talk about some
things that are perhaps not entirely
late it related to pallets but good
things to know they do help you if you
understood so in your understanding of
how pallets work good things to keep in
mind but also for nib loading in general
and some of these we see a lot of
questions on the mailing list especially
from beginning pallet programmers about
what methods get called messages get
sent and when in particular an it or an
it with frame depending whether your
view or non view object awake from the
other net with coder and so on so the
first case is you've just clicked on
your palette in the palette window and I
be what happens first well that's where
your net with frame will get called on
your view class let's take the example
again this is a view based object so in
it with frame gets called there then the
next thing you drag that view into your
design window again it gets archived
when it gets put on the pasteboard when
you drop it it gets an archived so in it
with coder gets called first and then
I'm sorry in code with coder when we
archive it and then in it with coder
when we drop it then you save the nib
and then in your running application
that nib gets loaded so what happens
when the nib gets loaded this
freeze-dried object mysteries
freeze-dried view that you had in your
nib file gets unarchive so an it with
coder gets called some folks expect so
this is a view mine it with frame will
get called but no it's the anit with
coder that gets called because again
it's a freeze draw and we're following
this object when the application runs so
this slide just basically summarizes
what we saw in the previous slides so a
nitwit coder the second side I think is
a little bit more important than it with
coder is going to get called not your
knit with frame and then of course after
that awake from nib will get called a
couple of caveats to keep in mind you
count on your connections have all
having been formed in the in it with
coder you have to wait until away from
nib to make sure all your connections
are formed so again this was a case of
you in the case of a non view object on
the palette instead of basically
everything is the same except in it with
frame gets called are sorry admit gets
called instead of an it with frame and
it's important to note if your non view
object has an initializer other than in
it that's not going to get called so
this only works well if your view and it
would frame or if your non view it needs
an init to work in an IV pally here's
another case suppose the time you take a
custom view which is one of the system
provided on one of the system provided
palettes and you drop that into your
design window but you want to make that
view a special subclass some subclass
that you've provided either you've
dragged in the header or you pick
another class subclass of view that's
available in ib itself so you have a new
view here now called my view so what
happens when that gets saved well the
custom view is the thing that actually
gets encoded okay and it keeps track of
the fact that oh by the way I really
wanted my subclass of view to be used at
runtime so the next step say at runtime
when that maybe gets loaded the custom
view is the thing that gets on archived
and then it realizes oh we really didn't
want to cut the custom view we wanted
that subclass of view so basically the
custom view kills itself off and allows
for your subclass of view to get created
so in this case and it with frame does
get called your subclass didn't get
unarchive it actually got created the
normal way so in this case and it with
frame gets called
okay and then that previous slide was
just a summary of what we saw on screen
let me skip that for save us some time
here the final and probably the most
confusing case that we run into is
suppose you dragged off a system view
not a custom view not a palette but some
sort of system view from ib palette
typical case might be an in its button
even more typical a lot of people taken
GL view which we provide on the pallet
you drag that off into your design
window and then you want to change what
class it is so instead of say in its
button you've got your subclass of
button and so you use the classes tab in
IV or the class inspector and you switch
what class it is so again you might have
a subclass of button or subclass of
OpenGL view so again there's two ways
you can come up with a subclass of
OpenGL view you could bring a custom
view in and change it or you could bring
in an OpenGL view in and then change it
so we're in the second case where we've
taken a system view we're changing its
class what happens in that case well
this is a little bit strange but what
happens is the NS button in this case
gets archived so it's in code with coder
gets called when we save the nib and
then when the mid gets loaded at runtime
well something gets unarchive in fact
the emit with coder to your sub class
gets called even though what got encoded
was the NS button so you have to be
careful if you do implement some encode
with coder on your sub class that's not
going to get called and furthermore you
probably shouldn't be pulling out
especially for type stream the old type
stream version of archiving you don't
want to be pulling things out of the
stream assuming that those are things
that you put in there for your sub class
because it's actually the superclass
that got encoded ok so the behaviors a
little bit strange there so because of
that strangest you should be asking well
why would you ever want to do that why
would
want to bring in a button and then
change its class well one answer is say
button or some widget that the system
provided may have a lot of attributes
that and state that needs to be set and
that state can easily be set in the
inspector for that object so you can
take advantage of setting up all that
state by using the inspector that you
inherit okay all right so looks like
we're in pretty good shape for time the
final topics that I want to talk about
basically are related to performance and
some some tips on on designing your nibs
so for example one way to get some nice
performance in certain cases is used in
a snit which is reasonably new if you
use NF nib you can get enhanced speed
improvements at possibly a cost of
memory you get to load the nib from the
disk just one time and then once it's in
memory you can instantiate it as often
as you want very quickly and again the
trade-off is between loading speed in
the memory footprint okay so here's a
little bit of sample code about if you
haven't used in its need before
something like this give you a start so
for example if I wake from nib I'm going
to get a hold of the main bundle for my
application and the next line is
basically setting up a dictionary which
is used to set the files owner on the
nib file and then I have an action
method here which basically if I haven't
already allocated the NS nib I'm going
to go ahead and call Alex and it was me
obtain colon bundle colon that's going
to load it from the disk but it doesn't
instantiates that objects are not
created they're not in memory and then
the next line is how you actually
instantiate the nib and then the final
line is say that if had some window in
it so you could do making order for
so you see it come on screen so a
possible use for something like this is
say i chat where you have incoming
requests from people to start a
conversation you might want to get those
chat windows up as fast as possible you
might not want to hit the hit the disk
okay something like that a couple of
pointers system documentation on loading
resources okay good for some more detail
okay the mid content strategies that are
related to this nibs are fairly cheap if
you load them into memory you can get
them on screen fast if you load them
from disk as long as they're not too
heavy weight that that's really not
shouldn't be a problem but remember that
every object in your nib is going to get
instantiated so excuse me so they're
cheap as long as they're skinny don't
try not to put a bunch of windows in
your nib file don't put a lot of objects
that perhaps could be lazily loaded
stored in other nibs and loaded or other
bundles and loaded when needed okay and
the other thing when you're finished
with a nib file make sure you free the
top-level objects okay and against more
details on where you can get information
on those topics slides will be available