WWDC2000 Session 128

Transcript

Kind: captions
Language: en
please welcome Ali ozar good afternoon
ok so today's talk is Coco in depth and
the the purpose of this session is to
build upon the cocoa overview session
which you might have attended on Tuesday
to give you some what's more detail into
some of the topics that Becky touched
upon that day and also to give you a
flavor more about how cocoa works and
how it's designed so that in-depth
discussions the topics that we're going
to provide you are the document object
scripting and undo which are three
topics that go in hand the text system
we're going to give you a little detail
on that then we're going to give you a
bit of performance tips and tools and
how it impacts cocoa in the context of
Mac OS 10 we're going to talk a few
minutes about using carbon from cocoa
and also how to use Java to program
cocoa ok so for the first part of the
talk documents scripting and undo I
would like to invite Mike Farris who's a
member of the engineering staff on stage
Mike hello
so I'm going to talk about 33 topics
here which all have a bit in common by
holding this wrong ah wrong button so
the document architecture and the
applescript support and the undo support
in the app kit all have some stuff in
common of the features in the kit a lot
of stuff in the kit is basically widgets
and things that you know you use in your
application but don't necessarily affect
the design of your application
traditionally with the kit in the past
you you know basically been able to
structure your app however you feel you
know you want to do that and it hasn't
really impactive you in your ability to
use the kit but as we try to add some of
these higher level features we find that
if your app has a particular structure
it's a lot easier for us to do a lot
more for you the structure that we've
kind of chosen to hang all this is off
of is the model view controller design
pattern and I want to mention that
basically all these features are
separate but they work really well
together and sort of with the document
stuff at the center of the equation so
if you're not familiar with the
model-view-controller pattern i want to
spend just a moment talking about that
this is basically a design pattern I
came from I think small talk originally
and it's a way of structuring user
interface applications and basically
splitting up your object model now it
divides models and the sort of three cat
or objects into three categories there's
your model objects that are basically
data bearing they have behaviors that
that behavior is basically concerned
with you know how your model the thing
that you're trying to represent in your
application works and so you know
have behaviors here that help ensure the
consistency in the invariants that you
need in your model the views are
basically the things that you use to
prevent data most of the objects in the
kit are basically view type objects they
help you to present your data to the
user and then finally the controller is
going to fit in the middle or denied
everything controllers are a large
amount of the code that you end up
writing in an application so here's a
little picture we can look at this two
ways there's a couple of dotted lines
which you actually can't see very
clearly here actually they don't even
look dotted anymore the little the black
lines that kind of go down the middle of
the box and divide everything into three
spaces on the far left we have the model
area in the middle where it says Dennis
document and it's window controller
that's the controller layer and then on
the far right you've got the view layer
now the two boxes that sort of span and
enclose different parts of this these
represent a couple of objects that are
key in the document system and show
where they kind of fit into this model
in the document system and it's document
objects tend to be the controller
objects that own your model and then
this window controller objects are the
controller objects that own your UI so
that's just a little little brief
introduction to model view controller
alright so let's dive right in to the
document architecture basically the
intent here is to provide a structure
where we can provide a lot of the common
behavior that all document applications
need and and provide you with a place to
put your behavior and easily customize
for the kinds of documents that your
application deals with now the the
classes in the kit have a lot of sort of
built-in implementation to do things
like running the open and save panel
loading nib files and managing
the objects that come out of them and
all the sorts of things you always have
to do and they also provide subclassing
and overriding points where you get to
plug in your specific stuff now the
document architecture is also heavily
tied into the application packaging and
in particular the same data that the
finder uses to know what kind of
documents your application opens the
document system uses so that your
application will know what kind of
documents your application opens there's
three main classes involved in the
document system the first and most
obvious one is the NS document class
basically each instance of this class
represents an open documents in your app
it's responsible for loading and saving
the document it also is responsible
primarily for owning the actual contents
of the document the model objects you
pretty much always subclass and it's
document to provide you know your
specific kind of document a text
document an image document whatever it
is that your app is going to do and just
to sort of look forward a little bit to
the other two topics in this in this
part of the session documents are
typically the primary entry point for
scripting in an application and then
also each document usually has an undo
manager so we'll get into those two
aspects a little bit later now the next
object is basically a singleton there's
one and it's document controller in your
application it knows about all the open
documents and it also handles behaviors
which are not associated with a
particular document like new and open
this is also where you would go if you
actually needed to query the metadata
that about your document types that's in
your info.plist it parses all that when
the application launches and provides
you with some queries that you can make
now you rarely have to subclass this
object you can it's easy but mostly you
don't need to bother
the majority of the kinds of things that
you're going to want to customize you
can actually customize through the
applications delegate object and then
finally there's Dennis window controller
basically this is a class which manages
a window that is typically loaded out of
the van in file and it usually manages
the window on behalf of a document now
documents can have multiple window
controllers so you might have a cab
application that had four windows you
know that was showing a top and a left
and a front view and you know maybe a
preview a wireframe of the 3d or
whatever you might also have an
application that allowed multiple views
of the same document to be open so that
you could look at a different scales or
whatever so documents can have multiple
window controllers and although you
don't have to subclass and its window
controller it's very common to do so and
one last point I'd like to make about
the window controllers you can actually
use them without and it's document you
can sub class in this window controller
to provide controller objects for your
auxiliary panels and everything else and
they provide management of the nib file
content so if you were at beckys talk a
couple days ago you saw this picture
this is a non document-based Coco
application and you may be wondering
what you know the document system sort
of changes this picture into basically
the delegate object the window delicate
objects become NS window controllers now
a window controller often is the
delegate of its window it doesn't have
to be but if you're going to subclass it
it may as well be and then there are in
a document objects right and you can see
that one of these document objects has a
couple of window controllers and other
than that everything's about the same
you can see also the NS document
controller object that it knows about
all the open documents
so that's a very brief introduction to
document now an equally brief
introduction scripting scripting is
based on key value coding we'll talk
about that in just a moment and the two
main areas of the scripting support is
classes that support you defining your
script terminologies and then classes
that support you handling script
commands alright first of all let's talk
a little bit about quezada coding
because this is a totally crucial
concept in the scripting framework we
get key value coding from the enterprise
objects framework and it is basically a
standardized way of accessing pieces of
an object what you do in your object is
implement access or methods and they
basically have a naming pattern you just
you know you have a get method that's
just the name of the key and then set
method that goes along with it keys for
example are things like the line width
of this circle and the line color and so
forth and so some of the methods might
be you know line width and set line with
wit and set width height and set height
whatever the standardization part of
this comes in in that there are two
methods value for key and take value for
key so value for key you just give it
the name of a key like line with it
figures out oh look okay this object has
a line which method I'm going to go out
and call this and return this the value
of that and then takes value for he
similarly works for settings but this
allows a subsystem that there's nothing
about your specific objects to
nonetheless be able to you know get at
the individual pieces of your object and
and deal with them and so the scripting
system makes heavy use of this how well
we use key value coding to provide
automatic evaluation of object
specifiers if you're familiar with apple
script you know that
basically the receiver of an applescript
command is usually an object that's
qualified along the lines of okay well
tell the the first graphic of the front
document of the application sketch to do
something right the first graphics of
the front document of application sketch
that's an object that's a fire we pretty
much provide automatic resolution of
these things using key value coding so
if your document object has a key which
is the graphics that that document
contains and your application has a key
which is the documents that the
application has open then we can
automatically find the first graphic at
the front document in addition to the
simple ones we can automatically do say
arbitrarily complex whose clauses in
this way we also use key value coding to
provide default implementations for a
lot of the common script commands you
can see that you know satin get those
are pretty easy to do with a key value
coding we can also do stuff like move
and create and you know count and exist
so a lot of the core scripting sweet
commands actually have default
implementations and your objects won't
have to specifically support them at all
all you need to do is claim that they
can support them and a lot of how to
please support them all right so let's
talk a little bit about terminologies in
applescript your scripting terminology
is usually broken up into sweets and so
this is the granularity that we have for
defining these things and script suites
are defined in frameworks or
applications or loadable bundles they
are property lists that live inside of
your frameworks or applications or
bundles and at runtime cocoa is going to
go out and find them all all of the
frameworks your length against all the
bundles you've loaded your app itself
will find all the script sweets and then
combine them all together and that
produces the terminology for your app
station now the contents of a script
suite is basically descriptions of the
classes that the suite defines and
descriptions of the commands that it
defines the classes are represented by
NF scripting class description objects
and basically classes have keys both
properties or if you're used to
databases sometimes those are called
attributes and elements sometimes called
relationships and then also a list of
the commands that the classes support
classes can inherit from each other just
like in an object-oriented programming
language and then the script command the
scripting command description class is
used to define commands in the script
sweet and commands basically have
arguments and have returned values and
the things you'd probably expect there's
a property list definition for all this
stuff so that you just sort of describe
in a property list the various classes
and commands and then at runtime those
will all be parsed in and these
instances that these objects will be
created to represent them now once the
script editors say knows your
terminology somebody might write a
script and then tell it to run and at
that point you're going to start getting
script commands in your application so
script commands come in if Apple events
just like they do for any application in
Mac OS 10 but we take them before you
ever see them and turn them into any
script command objects so these
basically end a script command objects
are the things that you'll see if you
have to implement a handler for a custom
command or if maybe your object knows
that it can do you know counting better
than the default implementation of the
count command and basically the script
command allows you access to all the
important pieces you know of that
command so it'll let you get at the
receivers of the command which is
basically an object specifier it'll let
you actually get at the real receivers
which is the result of evaluating that
object specifier and subclasses of NS
script command are actually where the
default implementations are provided in
cases where we can have a default
implementation so you'll see in the
framework you know NS set commands and
get to man's and NS count commands and
so on and so forth when you define your
own command you can choose to have a
subclass or not based on whether you're
going to have a default implementation
and possibly based on other things as
well and then the other object that we
have here is the ennis object reference
class this basically represents one
chunk of an object specifier so again
graphic one of the front document of
application sketch would turn into three
object references that are all chained
together and again object references
know how to evaluate themselves using p
value coding object references are found
as both the receivers of a script
command and also possibly as arguments
to that command so this is all you know
sounds pretty complicated it's actually
pretty easy to get started with this we
provide a lot of the behavior for you we
have a lot of the core sweet and text
sweet implemented in the frameworks that
come with cocoa so the application
applescript class is implemented by NS
application the document applescript
class is implemented by NS documents you
know the window classes implementers
window etc setter you can see where
that's going the text suite is pretty
much fully implemented by the end of
text storage class so what that means to
you is if you wanted to expose in your
object model something that conforms to
the text sweet you just have another
text storage object and so for instance
is sketch alright sketch has a text
graphic type and you can you know type
some text in whatever right and
text graphic type exposes one of this
instance variables which is a nanotech
storage to Apple script and then boom
automatically the text graphic in sketch
will support the text week so there's a
lot of the stuff built in there you can
you know incrementally start exposing
your own stuff you have to do a little
bit of work to start exposing some of
your model objects but often with just a
very small amount of work you can get a
lot of basic scripting functionality
almost for free all right finally even
briefer than the documents and the
scripting stuff i'll talk a little bit
about on do so first let me make the
point undo should be implemented in your
model okay you don't want to implement
undo in your interface layer because
then if something else comes along like
for instance Apple scripts and starts
talking directly to your model layer
that's not a good thing if you're going
to support multiple on do levels you
know if somebody you know changes the
font in through the user interface and
then a script comes along and you know
deletes that whole paragraph and then
later the user says undo well okay what
are you going to undo at that point
right you kind of lost the
synchronization of the undo stack of the
model so it's very important that undo
be implemented in your model it's also
the easiest place to put it so that
works out again for multiple undo every
change your document has to be undoable
because if not you're going to start
getting out of sync again now the class
and the kits actually in foundation that
supports undo is called NSM do manager
and it basically represents a stack of
undo operations as I said before a
document object typically owns an undo
manager so in document based apps undo
stacks or per document if you're not a
document based app then by default undo
stacks or per window
now NSM do manager is based on another
foundation class called NS invocation
and that what that means is that
basically to implement undo all you have
to do is do exactly the opposite of what
you're going to do every time you're
going to do something all right clear
enough alright so the code and yellow
here is all you have to do in order to
make set stroke color and sketch
undoable now this is one of the
primitive model methods and sketch right
the graphic object has this method this
is the way that the stroke color changes
no matter who's changing it and
therefore this is the appropriate place
to put this on do logic we know that the
stroke color is never going to change
unless it goes through this code and
every time it does change the first
thing we're going to do is tell the undo
manager to prepare a new invocation
which will basically if undo is chosen
end up sending the same graphic object
another set stroke color message with
the old stroke color that underbar
stroke color that's our instance
variable that you know contains the
stroke color so as long as we just say
oh ok well if I need to undo this just
call it again with the old value
everything is is going to be set up and
it's going to work just fine now a lot
of these undo invocations because
they're implemented in the primitives in
the model might happen during the vent
but NSM do manager by default will group
all of the invocations that get told to
it during a single run of the event loop
into one thing and now all undo together
so let me give you a little bit of a
demo mostly this will be a scripting
demo and if we could switch we've
switched ok good
so I have here script editor and I have
a little script which I've written that
does very small amount of sketch stuff
here so this script is targeted at the
sketch application and perhaps I wonder
if I can make that no bigger all right
never blind it so you don't need to read
this but basically this is going to this
is going to tell sketch to create a new
document and then put some graphics in
it and so and so forth so if i run that
you can see that it creates a new sketch
document puts a little content in there
and so forth and then the only other
thing i want to show here is a sketch
was implemented prior to scripting being
available so the scripting was kind of
put in later so nobody was thinking at
the time about the fact that somebody
might be coming in and changing things
besides the user interface but because
undo was implemented in the model that
all just worse when we added scripting
it's fine you know things that are done
through a scrip are undoable the same as
that if they were going to be live so
okay that's the end of the demo and I
believe have one more slide here which
is just where to get some more info on
this so there is a chapter of the
programming topics document I think it's
called app design and it basically goes
just a lot more detail on exactly these
three concepts document scripting and
undo there's a new fur I think dp3 is an
faq on NS document people have questions
a lot of them tend to be commonly asked
these are some answers there's pretty
good scripting documentation that tells
you how to do script sweets how to
handle scripting in your app so on and
so forth there's various release notes
that you might want to look at and then
of course there's the the cocoa
reference documentation
so okay now let's bring all the ups and
he can talk about text is if you are at
the cocoa overview session you saw Mike
Farris actually put together the text
edit demo and now we want to talk a
little bit about the text system that he
used in that demo the text system we
have a fairly sophisticated text system
in cocoa there are three major high
level teachers first of all it's
international it was designed with being
international in mind it's Unicode base
it supports in line input methods it
doesn't support every aspect of
internationalisation yet for instance
you cannot type bi-directional text or
vertical text in there however because
it's Unicode based and because the API
encourages use of Unicode and other
proper methodologies if you use it the
text system it's highly likely that your
application will just work with
bi-directional and even vertical text
it's also flexible it's got multiple
replaceable classes in there and we'll
just talk about the major ones and it
has a wide range of intended uses all
the text you see in Cocoa applications
ranging from a text field all the way up
to a large text view for instance the
text area of project builder which has
colored text and has a lot of
specialized behavior or the text area in
HTML edit which has even the totally
different object model behind it is
built using the text system it's also
powerful even if you don't want to
subclass and add stuff you're on your
own it has a lot of features out of the
box as Mike showed during the demo so
there are 22 even though you can
approach the text system casually and
just use it in your application without
doing anything else than just a simple
usage I'll just talk about two of these
one of them is NS text field this is a
class that represents in all of those
elements in that little window the
editable field the password field the
non-edible field those are all text
fields it's usually one line could be
multiple but usually one it's usually
non-rich but could be rich and it's read
only at are editable you see both
examples there and these are subclasses
of an ex-con
troll what it means is when the user
enters data and hit return a target
action that's the scent so you can take
action based on what the user changed so
it's obvious what the uses its for text
fields and stuff but you know little
fields that appear the other use is text
view the other class this is for more
sophisticated editing typically they're
rich you know that rulers they have
color panels on panels you can drop
graphics in there and so on it's got a
lot of lot of the additional powerful
features of the text system accessible
directly in there the good news about
both of these cases is they're both
available in interface builder now you
can say new application draga text field
drag a text view and you can check a few
boxes and most of the features are
available now so that's the text view
class let's look at what's beyond text
view we have the layout manager class
the layout manager is the piece of the
text system that coordinates the layout
of text and so on and we have the text
storage which might talked about earlier
which is basically the back end of text
where the text is actually stored and in
fact these three pieces form the Model
View and controller which is what Mike
just talked about the text storage
stores the text the the layout manager
lays text out and text you displays it
ok so the NS text storage class which is
the model the back end it basically
stores the text as an attributed string
there is a class in in foundation called
NS attributed string and just actually a
subclass of that and as attributed
string is basically aced NS string
meaning it has unicode characters in it
that you talked about this on Tuesday
and then it's got on every character in
an S dictionary of attributes and for
efficiency we put these on ranges of
characters let me show you a picture
here is a string which contains I
believe eight characters now because
this is unicode we can say there's just
eight characters in there in here if
you're not talking unicode and you're
talking classic one or two by top and
coatings you know this could be maybe 10
bytes or whatever you know i don't know
the exact byte count but would depend on
what
characters are being displayed for their
eight characters here now the first one
is an H with an underline so its
attributes for that range of one
character is that it's got a color of
light blue it's got a font of courier 72
and it's got an underline style that's
solid now if you look at the next five
characters the color there is light blue
and the fastest courier 72 we don't have
an underlying attribute in that case by
default if there's an underlying
attributes means there's no underlined
finally the last two characters they
don't have a color attribute which would
mean that we're using the default which
means white actually probably black ops
team it's reverse and the font there is
Sokka 72 now so there are three Rangers
here three bags of attributes and they
apply to these ranges now the one other
thing to say about attributes is you can
have your own attributes in these
dictionaries for instance if you want to
have a special indexing attribute you
add on to text you can just add them
into these dictionaries call to actually
whatever you want and you can add any
value you want these actress will be
maintained at the Texas edited pushed
around etc and so forth so it's you know
you can overload these things and add
your own information on any range of
character you want so the layout manager
is the middle piece the controller it
coordinates pipe fitting of text it
reads text from the text storage it lays
it out into lines and then it gives it
to text view to display so it's the
middle coordinator guy the other
interesting thing about layout managers
it also stores information about the
laid out text so if you want to ask
where is line 1 or where is the you know
where are the characters 1 through 20
displayed on the screen and so forth or
what's the bounding box that this text
to cup this is the place to go just has
API to give you that one thing to note
about layout manager in fact the whole
text system is you'll note that there AP
is that are in terms of characters in
api's that are in terms of glyphs most
of the time people use the term
characters to mean both but once the
distinction the important distinction in
our API is where we sort of have to be
exact is that characters refer to the
elements in the text storage each
unicode character is a character and
when we say character range we're
talking about the rain
unitech storage glyphs are to display a
displayable elements the glyphs are
usually elements of fonts and they are
computed as a result of laying the text
out and the characters and glyphs are
distinct and in fact one character might
lead two to three glyphs or maybe
several characters can be combined to
show one glyph and which glyphs get
shown display which goods are shown
basically depends on the font let me
give you an example most good text
systems would take an S and an I the two
characters and put them together to
display the ligature fi so the ligature
is really just one glyph for the
character range that contains two
characters corresponds to a glyph range
that only contains one good so you know
if you look at the NSA opmanager API
keep this distinction in mind because
it's important finally a little more
detail about the text view the view part
of the whole whole picture it's the user
interaction layer it displays the glyph
it also handles all the events key aapki
down etc all go to text view it also
deals with the ruler the font and all
the other color panels and all these all
the other users are elements that's
basically the user is doing it also
turns out that if you want to have
multiple columns multiple pages multiple
weird areas you just have multiple text
views that are attached to the same
layout manager now one thing to note
here is that NS text view is a subclass
of a classical and as text which in turn
the subclass of NS view and NS text is a
sort of a legacy class that's in there
and as text view is the class you should
use but for the whole picture the whole
API you should really look at both text
view and text and you know think of
those as the combined API for text view
it turns out you can do most things with
the text system using text view but for
more sophisticated usages you would go
beyond text you and talk to the layout
manager or or text storage so just to
recap text storage stores the text
layout manager lays it out and text view
displays it and two other interesting
tech system components are the texts
contain your class text containers
display they basically described the
areas that text should flow into in fact
you can use a text content to describe a
doughnut-shaped area or whatever you
want you know it's
it's basically describes the area it
turns out there is one picks container
per text view and in fact it turns out
that you can rip alpha text view from
this equation and just leave the text
container and have a text system that
doesn't display but instead can be used
to lay out a newspaper for instance in
the back end without ever displaying
it's because it's going to the printers
or whatever so text content is the part
of text view that describes the area and
finally we have typesetter there's
usually one instance of this types of
their purpose is to get the glyphs and
put them on a line and basically do all
the justification so typesetter is
invoked by layout manager as a part of
laying out the text okay so so much for
text now I want to talk a bit about
performance it turns out there is a
performance session going on right now
which you're all missing so we figured
we would give you some of the
interesting aspects of that talk here
especially how it relates to cocoa so in
the context of cocoa application and in
general actually Mac OS 10 as well there
certain causes for performance issues
memory or the lack thereof network or
disk operations or too much of them too
much drawing and pulling so these turn
out to be major concerns it turns out
that pure CPU usage is rarely the
problem I mean typically if your
application is slow you're rarely going
to find that it's because of lack of CPU
power but of course it happens you know
that algorithms can strike anywhere so
let's talk about memory 11 cause for
problem is maybe one problem that you
might not have on Mac OS is window
backing stores both carbon and Coco apps
all have backing stores corresponding to
every window that's on the screen in
fact everyone know that's even not on
the screen so if you're a 1k by 1k
window that's 32 bit steep that's I
think four megabytes of memory right
there for that window and of course this
window backing store is something that's
used to give you a really nice display
flicker-free and so on another reason is
the custom heat management a lot of
applications might be doing their own
heat management especially on Mac OS
and this turns out the cause this turns
out to be a potential problem for apps
running on Mac OS 10 finally failure to
release memory you're just leaking it or
holding on through too much turns out to
be a potential problem so window backing
stores as I said windows are by default
buffered also NS images which is the
image displaying component on cocoa in
ass image will sometimes use caches
which are basically window backing
stores to cash images in and again you
know you load hundreds of images that
could add up to a few megabytes in your
application now there are there are
tools to look at these and I'll mention
these in a few minutes but there are few
solutions in this area you can make your
windows one shot which means when the
window is no longer in the display its
memory is released and every time the
window comes back on the display and
memory region is created for it and then
the window is displayed and you can
assure that NS images are not creating
caches and there are several ways to do
this so one other solution that you
might think about is why why use the
buffering at all and it turns out that
using buffering allows windows 3
flicker-free if we don't have buffering
when you do that lovely window moving on
top of other windows all the exposed
regions would have to constantly be
drawing themselves to keep up with you
know keep up with the users moving and
you know that's a bit windows like maybe
and it's a bit you know not not in the
spirit of aqua custom heap management
again a lot of apps you know in order to
assure that they have enough memory to
complete an operation might be
allocating large blocks of memory which
they carve themselves maybe the memory
that they used before in Mac OS 9 was
not quite enough for them it doesn't do
the right interrupt handling whatever it
turns out that this is bad because it's
just causes fragmentation if every
subsystem allocated want megabytes per
node news and carved out there all these
little pieces of memory that are not
being used in the system and perhaps be
there being kept hot because the
customer memory management ends up
touching all of those bites and another
disadvantage here is that standard tools
to track memory which will show you one
of you know it won't work it doesn't
know how this memory is allocated so the
solution here is just to use
Android's memory system the standard mal
lock that comes with the system it's
pretty powerful it covers a wide range
of uses it should be good enough for
almost all uses on Mac OS 10 finally
failure to release memories the last
point here the beck you mentioned Coco
introduces reference counting where
objects can retain each other and so on
so one problem is that you know you
simply retain something or you have a
copy of it and you don't release it well
that's an obvious memory leak you know
you have to release it another problem
is sometimes one object can retain
another object and that object in return
retains me so these two objects are
retaining each other they might be
totally useless but they're just sitting
around not getting freed and to solve
that you really need to be consistent in
how you do retains and releases 11
guideline we use is if you have parents
child type things you know where you
have a hierarchy of objects typically
the top level objects retain the lower
level objects and the lower level
objects even if they point to the higher
level object do not retain the higher
level objects another case is loose
connections for instance of cocoa we
have delegates outlets targets those are
typically entities pointing at each
other typically those loose connections
do not involve retains meaning an object
does not retain its delegates or its
targets because those are all entities
of our objects in their own regard so
the performance tools to track malik's
memories there is object a lock and
malik debug i believe will show you
object alec in a few minutes to track
all memory meaning everything a nap
might be touching that includes all the
shared frameworks etc there is tools
like tops and PS which you run on the
command line now if you run leaves and
you see these sides which means virtual
sighs you might at first be shocked
you'll see numbers like 80 megabytes
that includes all of the shared
frameworks and all the other things that
are shared across the system so that's
not really the number that's you know
what your app is actually occupying but
looking that number and seeing whether
it's growing or getting smaller and
looking at trends that that number is
still interesting finally the track
window backing stores there is no tool
on DP for
no obvious no easy way to do it but
Chris will show you a tool that I think
going to be released pretty soon so
quickly the other reasons network or
disk operations please take a long time
relatively speaking and you probably I
mean all know you've had to deal with
these things these might have an
unpredictable effect on performance
because sometimes the disk is slow
sometimes network is slow one thing to
watch out for is on Mac OS and user
directories can be either on a local
machine or they can be in a network and
we go to the user directory to read
stuff like preferences or you might put
caches there or other documents if you
always test in the context of a local
user and then you might find out on the
network user case where the network
access is much slower you might find
that things are just way slower and you
weren't prepared for network accesses so
and the thing here is obviously you
should avoid or delay or call us
operations that touch the disk for
instance if you're writing preferences
out don't write them out every time
something gets changed maybe wait to
write them out at the end cocoa
applications actually write out the
preferences when they're quitting so you
could just let the cocoa system do it
for you when you update preferences
there are tools sampler I believe Chris
might show that in FS usage SS usage is
a command-line tool which will show you
all file system calls that a process or
the whole system is doing it's pretty
entertaining if you haven't seen it an
interesting a sad sort of way ok and
drawing too many times is another common
problem sometimes in object-oriented
environments because multiple subsystems
might be doing drawing you know to sub
different subsystems might cause update
of an element and you just might not
notice it might not be obvious NS view
the abstract drawing class actually
provides the facilities for managing and
coalescing dirty regions so instead of
causing a display immediately you should
call fit needs display which recorded in
its view that this region updated and
eventually it will display at the
appropriate time we have various tools
and again I think Chris might show one
of them i mentioned that show you
displaying as it happens so it gives you
an idea of what
on finally pulling pulling is bad
sometimes pulling is used i think
sometimes mac OS 9 applications use
pulling more than say on mac OS 10
polling is bad because it keeps
applications awake the colonel has to
schedule them in the applications memory
is kept hot and it also interferes with
power management and with scheduling I
mean the colonel was trying to schedule
applications in there's an application
of every tenth of a second says anything
happening anything happening anything
happening you know you eventually United
you can see how to be a problem so the
solutions are there are pretty good
solutions in the system there are event
mechanisms both in carbon and cocoa that
lets you catch event when interesting
things happen milestone happened mouse
will happen etc rather than you sitting
there pulling the mouse location and
there are also notifications that will
tell you that certain things change
another thing is even if you can't avoid
polling maybe you can do polling at key
points for instance when your
application becomes active you could
update the state of some certain thing
that you're displaying perhaps when your
app is active the chance that it's being
the split change behind you are very
small so it's not interesting to update
and sampler and tops will again show you
the cases for polling ok so i will now
invite chris cain on stage for a demo of
some of these tools
[Applause]
mo 1 let's see in the short time we have
I don't have nearly enough time to go
into any detail on these apps as far as
how you go about to use them to solve
particular problems I just want to show
that the apps exist and you know
generally what they're about the first
staff here I've launched a sampler and
I'm going to choose text edit I'm going
to sample the launch of texted and so
what I've done is I have just hit the
button that's a launch and sample and
all it's done and what we have is a call
graph on the left to the center of the
of the center of the window and this is
showing the call stack that sampler
found the app in if you will what
samplers doing is every in my case 50
millisecond it's going out to the other
app it's stopping it it's going and
plundering around in the application
finding out where all the threads are
what they're doing and it's recording
that information and so what it's
displaying in the call graph is the sort
of coalesced call tree view of that of
what was going on over in the call stack
lift over on the far right what's going
on is sampler has chosen the hottest
frame it hottest node at every frame in
this coalesced call graph to show you
you know what what's the hottest thing
going on what we're seeing here in this
case is the app spent most of its time
while it was sampling it launched very
quickly and then I let it run a little
bit and
spent most of its time just blocked
waiting so that's what this is what this
is doing we see and its application run
it's looking for a next event and you
know a lot of internal routines here we
see CF run loop is being run you know so
we're going down into the layers of the
system and eventually we trap into the
kernel and we're blocked in the kernel
waiting for an event to come on user
input event now I haven't clicked over
here so no user input events have come
into the app certainly not while I was
sampling so one thing I just wanted to
point out while I was here is that it's
very normal very normal to see this sort
of vac trace that if you find your app
in the situation where mock message over
right trap is you know stuck yet
essentially that is normal and that is
good and we want apps to be very quiet
not doing anything while they're in the
background like Texas Texas in the
background if I sample again here let me
we crank this down to one millisecond so
every one millisecond stopping the app
and sampling now one thing to note is
that I I have not built a special text
edit here this is just the text edit
that comes on the system I don't know if
there's any way for me to prove that I
guess you'll just have to trust me there
but to sample a nap you do not need to
especially build a profile version the
app or anything like that and so what we
see is while I was sampling all the
samples all 5439 of them are stuck in
mock message overwrite trap waiting for
events to come in you know so that would
wake up for example when I click the
window there and go and do some drawing
and stuff like that so that's sampler
that's just a very quick look the best
way to find out more about these
applications is to go in and play with
them and see what they do the next step
I'm going to show you is object Alex
object alec is a way of looking at the
memory usage of an application
I'm going to choose text edit again and
I'm going to choose the binary so here
we see the object Alex window the first
button over here is start button I'm
going to start to start up the task now
it's launching texted at what we see
here is the histogram of various
categories of allocations object alex is
seeing all the allocations that are done
by the applications and if categorizing
them as best I can in some ways it's
more sophisticated and in some ways in
some places that you know it really
doesn't know what how to category is an
allocation so it just gives it a generic
moniker now the fun is probably too
small for you to see there but the first
column is a category and the category
name in the first row here is zone malik
22 and what that means is just a generic
allocation occurred of size 22 we have a
current column that's the number of
blocks which are 22 bytes in length that
are currently still allocated and the
other interesting caught most
interesting column is the total column
which I selected here and we're sorting
on and that shows that 2075 of these
blocks blocks of length 22 were
allocated while the program was running
one interesting feature we've added
since dp3 to object alice is that we
understand some of the CF types so in
the second row you see CF strings
collected and it identifies these
particular strings as the immutable ones
and I'm going to go over it in the
second tab here and if i click on CF
string immutable here it's showing me a
list of all the CF strings that are
currently allocated in the application
so if I click on one it's showing me the
contents of the string down here for
example there's a string without global
preferences
there's a string with a path in it thank
you so that also works for very other
types of objects of CF array the mutable
variable kind of CF array here it's
showing the debug description this is an
empty array the count is 0 is there one
with something interesting a lot of
empty arrays are pretty common there's
an array with one thing in it which
looks like a string a path to the
application i launched in fact and and
so on of those so here's see a set and
here's a description of an assisi upset
with a bunch of stuff in it so that's
object Alex the last thing and then
there are other things you can do with
object outlook yeah I suggest you know
running it playing around with a little
bit here I'm going to demonstrate this
in a moment what's going on when this
happens but you can scale the view for
example sort by the different columns
and so on the last thing I want to show
and we stop that is let's move it over
here this new tool Holly alluded to
called quartz debug it might not be
called quartz debug when we release it
but hopefully it'll be released soon
it's not in DP for but it goes in and
talks to the core graphics server the
windows server window manager and tells
it to you know turn on various graphical
debugging features so I'm going to let's
see what let's turn on all of these so
what we see at what we saw briefly there
is the bits of the window that are being
redrawn our first drawn in yellow and
then they're drawn with their true
content so if I click on a button for
example
we see it is hard to see that the button
is actually being redrawn sense is so
quick let me turn on the delay if we
turn on the delay we see the very
labor-intensive process that graphical
drawing goes through to produce a window
as complicated as object Alex window so
here we see the text you know the table
tab view being drawn there that
background patterns being flatted onto
the screen here come the tabs on the
other the outline view every row and so
on so turning on the delay allows you to
see where you have redundant drawing I'm
going to turn that off that's just too
painful
ok so we've recovered but I turned off
the delay and now we're just you know
every time the window has to become
inactive of course we have to redraw all
the controls because they're now gray
into the blue and things like that one
thing I've noticed as far as debugging
here is that if I choose a different
column you can see if you look closely
that the whole outline view is being
redrawn and that's probably correct and
okay if I you know change the view
around the outline view is just drawn
once but if i change the slider here do
you see that it's being redrawn twice so
yeah really obviously i do it out here
nope there oh yeah twice and in fact the
slider is also being drawn twice with us
a little more subtle and you might not
be able to see that going on up in the
screen so i probably have a bug hear
that when I'm readjusting the scaling
I'm over over you know displaying the
system I might have a direct call to the
display method in there for example
rather than doing set needs display and
letting the app kit display system take
care of that for me like to call Ali
back where do you go
and if you could have the slide set
thank you Chris okay so we still have a
few minutes and I'm going to talk a
little about using carbon from cocoa now
as you know cocoa and carbon are
actually two separate programming
environments and there they don't share
the same windowing structures the
responder chains events and so on but
our goal is to you be four developers to
be able to use carbon features from
cocoa and cocoa features from carbon and
that's the ultimate goal we have and
I'll just talk about where we are in
debt now much of the plumbing under
carbon and cocoa apps is the same
calling conventions we use the same
compiler it's C so no problem there the
application packaging you've probably
heard about NS bundle CF bundled
application packaging exactly the same
between the two apps the low-level API
is POSIX etc the same and basic data
types an int isn't in both worlds so
that's all very good so fundamentally
there is no problem calling carbon
between carbon and cocoa you can call a
carbon function from cocoa no problem
but there are some restrictions as to
what you can do now if you look at the
umbrella framework picture which you've
seen about 40 times I bet you see that
we have the various levels below the two
I think in general we can say that you
can involve carbon services from
application services and core services
frameworks without any problem so
examples of carbon api's you can use
from cocoa include quick draw apple
event file manager resource manager text
encoding converters speech I'm anything
else that comes from low-level carbon
our application services and of course
core foundation now high-level toolbox
API is the high-level toolbox is the
fundamental drawing stuff that is in
carbon it sits in the carbon framework
bucket those in general are currently
not available you can try to call them
but in general events might not work the
drawing might not be right so at this
point this is not something you can do
in the context of a cocoa app now aight
also said that you could pass basic data
types back and forth so obviously see
types and structures no problem those
are all the same between the two
environment
now their api is to convert other types
some of the more fundamental types you
might be using in your app are file
paths or FS traps or URLs and for
instance file manager a carbon manager
in CF URL which is in corisande shin
both provide ways to convert urls and
tasks back to fsr and FS specs and so on
so you could actually intermix those two
api's by doing these conversions and
also in some carbon API still take
Pascal strings in the context of a core
Coco app you might have NF strings or CF
strings and then you can use CF string
or nsstring conversion facilities to
call down to those api's now I'm saying
NS string or CF string this brings us to
toll-free bridging which enables passing
which enables treating those two is the
same what toll-free bridging does is
some CF types are the same as their
cocoa counterparts CF string is the
exact same as an NF string array
dictionary data URL the same thing and
there are few other classes this is true
for what this means is if you have some
cocoa API and it gave you an enough
string and you have to call a carbonate
gala takes a CF string just cast away
it's the same thing no problem ok so
this is thank you so you can just pass
these back and forth ok so so much for
carbon now I mean as I said our intent
over time is to improve the bridging and
currently you might find that some areas
are not properly bridge yet and if you
hit upon a wall and she hits something
unique definitely please a lot of snow
and finally the last topic for today is
programming cocoa with Java as you know
Objective C and Java are both the
languages with which you can program
cocoa and here I'm going to talk about
some of the design philosophy of what
happens when you use Java to program
cocoa you can access most cocoa api's
using the Java language and I'll explain
why it's not everything Coco objects can
be subclassed in Java so if you have an
NS view which is a cocoa object with an
objective-c and you want to have a
subclass of it in Java you can do that
you can also pass objects back and forth
between Java and Objective C so
NSU is an objective c class it once you
know some objects it once have a window
pass to it you can pass the java version
of it back and forth it's all automatic
and your applications can either be one
hundred percent Java or you can make
them hybrid meaning parts of them can be
objective c parts of them can be java so
the philosophy we have in the Java API
is is that we want developers to be able
to use the Java language to program in
to create cochlea applications however
we want to preserve and expose the cocoa
programming model because you know we
have these this cocoa application model
it's you know one way and you should be
able to use that in the application but
we also want you to be able to use Java
paradigms and objects there possible and
where it makes sense one example is the
java string class it's very it's all
over the place in java and in the java
side you might you might it might be a
better idea to use the java string
rather than use the NS string class and
functioning functionally they're pretty
much equivalent the other goal we have
is that you want to be able to integrate
and use java libraries as much as
possible java network libraries well
whatever else you might have java
utility libraries you should be able to
use them in the context of your app and
this is pretty much confined to the
lower levels meaning it's DUI layer it
might not work so good but lower levels
networking etc those api's are all
available to you so I talked earlier
that I said earlier that most api's were
exposed it turns out almost all of the
apt-get is exposed using this name com
that Apple that beep that application
okay and then we have some of foundation
exposed when I say some it turns out to
be adding at least half of it combat
Apple yellow ducks foundation now the
areas that are not exposed as basically
areas where you know we decided that
Java has a link coolant and finally
there additional frameworks combat Apple
that yellow that scripting has the
scripting functionality that adds is
added on to the cloak of frameworks now
we will rename these things at some
point soon
okay so most objects are exposed
directly we call these rafts so NS view
in Objective C is the class combat Apple
yellow that application of NS view in
Java now I talked about the string class
which is not exposed those are more
meaning any time it goes to the other
side it goes to run change it basically
changes into an object of the other
language so nsstring instances are
converted to the string class in Java
and there are a few other classes to
which this happens and we repackage some
functionality for instance categories as
an objective-c feature which lets you
add methods on top of an existing class
it's not available in Java so in those
cases we either take the methods that
are in a category and fold it into the
base class or repackage them into a
separate object in c functions which
cocoa has some of are not exposed will
directly in Java so we've usually
package them into a utility class much
like the math class in Java and cocoa
also has a bunch of structs and
selectors and java does have a concept
of structs and selectors and those are
converts to java objects as well and as
far as method name mapping in
objective-c method names can have
arguments keyword arguments or keywords
for each argument for instance
post-event it starts there are two
arguments there one between each colon
in Java we convert that to post event
meaning we drop the other argument names
because often the main part of the name
is good enough and Java also allows
overloading which means you can have
various versions of that sometimes when
the name would be not very obvious or
sometimes when the second argument is
important is the first one we tend to
keep the whole thing so set object for
TV becomes said object for key finally
init method which are the Constructors
in objective-c in Java are just
converted to construct your methods for
instance the NS view in it with frame
method which is how you create a nice
view in Java is simply NS view which is
how you create objects in Java so those
of you who are familiar with job will
probably have tools to inspect and look
at Java api's like Java p and so on one
tool we provide on the system is this
app called Java browser
it's really handy it just shows you a
browser up there of all the classes it
knows about which includes the cocoa
classes plus all the other classes
including the Sun classes and you can
choose any class and down below it will
show you a nicely formatted API for that
class so it's a fairly handy tool if
you're if you want to browse through the
API ok so I think that you answer the
documentation there's documentation on
vp for release notes and so on the
release notes are really quite handy
there's documentation and system
developer documentation cocoa you can
also go to the website to see if there's
updated documentation any of these areas
with example code in both system to vote
for example zap kids and in system
developer examples java app kits for
java applications written with cocoa and
here's the roadmap some of these talks
have passed but you know if you have a
chance if they're the facilities will
provide to review them you can choose to
do so let's see the localization talk is
happening right after this i think
that's like talking about how to
localize cocoa and carbon applications
the courts talk is tomorrow where it
talks about courts AP is that you can
use directly from cocoa applications if
you want to and performance talk that is
pretty much wrapping up right now i
believe so okay let's see so i think we
have about 10 minutes i would like to
invite mike and chris back on stage for
some QA and becky i think i see her
there too now one one thing we have a
brand new address coco feedback at
Bluford apple com it works so if you
have comments and feedback on the API
new features you'd like to see added to
Abaddon foundation such please send send
us mail thank
you