WWDC2010 Session 141

Transcript

>> Troy Stephens: Well, thank you.
My name is Troy Stephens.
I'm a software engineer on the AppKit team where I work
on the NSView system implementation among other things.
And as you know, right out of the box, AppKit and Mac
OS X's variety of other user interface frameworks things
like ImageKit and WebKit and QTKit and PDFKit provide
you with a pretty wide variety of standard controls
that you can often use as is or maybe
with a little bit of customization
to assemble your application's user interfaces.
A lot of the time, you can build an
entire app just out of standard parts.
But every once in a while, you may find the need to invent
something completely new, an entirely new kind of view
because you want to represent some data in a way that is
unique to your applications or you have a very unique kind
of data that none of the standard
views really can possibly provide for.
So, when you get into this situation-- and this is the
topic of our talk today really is starting from NSView,
subclassing NSView directly, building an
entirely new kind of view from scratch.
So when you find yourself in this kind of situation, how
do you go about making sure that you do a good job of it,
that you take care of everything that you need to
do in your responsibilities as a view subclasser?
Well, I've often wished for sort of a comprehensive
checklist that I could tick down and say, oh,
did I remember to do this, did I remember to do
this, oh, I forgot that, okay check, did that.
This talk aims to provide that checklist for you.
We have a couple of party favors for you today.
first is a custom view implementor's checklist,
and that accompanies a brand new code sample
that we're introducing here that
I'll talk about in just a moment.
But first to get us in a sort of the right frame of mind
to have lofty aspirations for our custom view building,
I want to talk for a moment about the
essential elements of good craftsmanship.
And to my mind, I thought of about six basic
characteristics that define good craftsmanship to me.
The first and maybe most obvious is attention
to detail, to the fit and finish of an object.
You know, it's a real pleasure to use a device
or tool that shows the designer really thought
about every little last aspect of
how it's assembled and designed.
And that kind of attention to detail
tends to stem from a philosophy of--
that something worth taking the time to
do is worth bothering to do a good job of.
Robustness is another aspect of good
craftsmanship that we tend to value.
You know, if you're building a tool, you wanted
to stand up to the rigors of real world use.
Otherwise, it's just sort of a pretty object
and not particularly good craftsmanship.
Functional completeness, you want something to do
everything that you expect it to do, of course,
but at the same time you want to balance
that with an appreciation for the fact
that elegance is the marriage of simplicity and power.
You want something especially in software to be only
just as complicated as you need it to be in order
to do what you need it to do and
no more complicated than that.
As we all probably know from experience,
any more complexity brings problems.
And lastly, use appropriate design.
You want something to fit in well in the real
world context where it's going to be used.
It's nice to show that you put some thought
into how this view is actually going to fit
into the context of an application or user's workflow.
So with those sort of lofty aspirations in mind to give
us goals to work toward, how do we apply these kinds
of principles of good craftsmanship to crafting views?
What are the essentials for crafting views?
The basics start with of course the presentation aspects.
So, how you handle layout and drawing, you know,
figuring out what size your content is or how to fit it
within the space that you're given, where is everything
going to go, and then of course how do you render
that content so that the user can see it.
The flip side of that presentation aspect is
the sort of input side and event handling.
Of course, how you handle keyboard, mouse, trackpad, and
other events that will come into your view to provide ways
for users to usefully interact with
your content that you're presenting.
Accessibility is really something that I think
nowadays we should think of as an essential,
as a part of the foundation, the basics of good
view craftsmanship by making your views accessible
as it has been pointed out in other sessions or earlier
this week, including the Cocoa Tips and Tricks session.
You really expand your application and
your view to a wider user audience,
and there are other benefits as
well that I'll talk about later.
Lastly, sort of an umbrella item,
supporting standard system features.
You know, we have all these user interface
paradigms that nowadays we take for granted.
Things like the ability to select content, cut, copy,
and paste, drag and drop, those sorts of UI paradigms
that if you support them in your
views at sort of a very basic level,
then of course that makes them more discoverable.
Your design is more discoverable to users.
They can intuit how to use your custom views.
So once we've got the basics in
place, we can look at refinements,
and those of course include tweaking the appearance
of your view, pushing every last pixel to get things
to look exactly the way you want them to.
Planning for animation, in a way this is a refinement.
It's sort of the icing on a cake or the
fit and finish from the user's perspective.
And that animates too.
Gee, isn't that nice?
You know, something that's kind of pleasing.
But if you want to do this and do it well and
have the versatility you need to do it well,
it helps to plan from it-- for it from the beginning.
And so in a way, this sort of belongs
in the basics category.
I'll talk about that in detail later.
Lastly, sort of responsiveness and scalability, you
want your view to respond as immediately as possible
when the user clicks in it or issues a keystroke.
Any kind of lag in responsiveness tends
to make users get frustrated easily.
And of course scalability, you want to think about
what's the maximum complexity of your view's content
or number of objects you want to be able to handle.
So, I mentioned we have a new code sample today,
and that is something that we call TreeView.
And TreeView simply put is a view
for presenting and allowing the user
to interact with tree graft node structure.
So any -- we're familiar with these -- anything that
has, where you have a root node and then conceptually
that root node may have children and those children may
in turn have children of their own and so on recursively.
And to give us a concrete idea of what TreeView is
and does, we'll just start with a quick look at demo.
[ Pause ]
So, here we have TreeView running in a sample app,
and this code is available for download already.
There is a 1.0 version that went up two days ago I think and
there should be a 1.1 version published very shortly today.
So here we have a TreeView and what we're
looking at for example content is a portion
of the Objective-C class hierarchy as discovered
through the runtime introspection facilities.
So here we're looking at NSControl and all of its
descendant classes in a TreeView and, you know,
we can-- here this TreeView is the document view.
The scroll view so we could scroll around
if it's extremely large as it is right now.
It can get even larger than that.
And the basic API model here is to try to decouple.
When you study the code, you'll notice that this
tries to decouple the model from the presentation.
So the API model is-- we give the TreeView a root
model object that represents the NSControl class
and then that model object is required to conform
to a very simple protocol that TreeView defines,
which allows the TreeView to determine that
model node's parent and all of it's child nodes.
And so, the TreeView can traverse the model
tree, figure out its extent and all of its parts.
And then for each of the nodes it wants to represent
visually, TreeView does something very similar
to what collection view does nowadays, which
is to load a nib file that contains a view,
and really, a view subtree that represents a node.
So here we have the NSControl class represented by a node
that actually has a container view
that draws the rounded rectangle shape.
There's an NSImageView in there, a couple of NSTextFields.
We've got a button in there and these buttons enable
us to expand or collapse portions of the subtree.
And as you may notice, that's all-- animation is built
into that so that was designed in from the beginning.
We can click around and we can select nodes, so
TreeView supports the notion of selected nodes.
So we can select nodes.
We can-- I'm using the arrow keys now to navigate around.
That's another thing you want to think about.
Oftentimes, your users will want to be able to
just leave the mouse aside or the trackpad aside
and can navigate very efficiently using keyboard
commands if you give them the ability to do that.
I can hit Spacebar to toggle, expansion
or collapse of nodes and so on.
And there's even a little bit of gesture support
in here if you have a multitouch trackpad.
You can use a pinch gesture to vary the layout spacing.
Here I have some controls where we
can do that explicitly with the mouse
so we can vary the parent-child spacing horizontally.
We can spread the tree out vertically if we want to, sort
of some basic appearance properties we can tune there
and we can set a different background
color for the TreeView.
Set a different connecting lines color.
So there are appearance properties that are customizable,
and we can choose a different connecting line stye
and vary the thickness of the connecting lines
if we want to, so the sort of things like that.
And another thing to notice is that
TreeView operates layer back too.
And when I click the switch, basically nothing happens.
But there is a lot of interesting stuff going on behind
the scenes to optimize this TreeView for layer back mode.
For one thing, the TreeView example is the first one, I
think, we've published that demonstrates how to do things
like background fill and drawing stroked outlines.
Using CALayers properties let the GPU do the stuff
problematically rather than allocating backing stores
for all of the layers that constitute these various views.
So that's kind of interesting.
We can click this sort of debug feature here to show
the subtree frames, and this shows the structure
of the TreeViews content which
I'll talk about in detail later.
But basically each subtree, meaning a node and all of
its descendants has a green outline drawn around it.
And those are the essentials of TreeView.
So let's look at some aspects of how this is done.
So, I want to have time to examine the code
in detail over the course of this talk,
but we will refer to various aspects of TreeView's
design decisions over the course of the talk.
And again, I encourage you to download the sample
code and study it in detail at your leisure.
We'll look at four major topic areas
for crafting custom Cocoa views today.
First, designing for animation, from the
beginning I mentioned the importance of doing that.
Next, we'll talk about drawing and layout
which is related to drawing of course.
Handling of state changes, things that may happen to your
view that you may want to respond to, how you can do that.
And lastly we'll look at handling interaction or user input.
So first let's look at Designing for Animation.
What are the sorts of things that you want to think
about from the get go when you're designing a view
and you might want to animate your content.
Probably the most important top level items to think
about factoring your content in ways that enable you
to minimize redraw and relayout activity and
computations when things are being animated.
And this is especially important for layer-backed mode.
And I think nowadays if you're designing custom
view, especially if you're designing it for sort
of a generalized use by others you really want to make sure
that it can operate well both in
layer-backed and window-backed mode.
For one thing you may not have a choice about that.
A view can always opt in to being layer-backed.
If your view does set 1's layer yes on itself
it makes itself and all of its subtree--
all of its descendant views layer-backed.
So, you have control over that but you may get opted in by
someone else if your view is used in somebody else's window
and they have 1's layer to yes
higher up in the tree, you know.
Then everything from there on down is going
to be layer-backed and you're going to have
to make sure that you can operate that way.
Now oftentimes for most things if
you're designing simple controls
and so on usually you don't have to worry about this.
Things just sort of-- the layer-backed
stuff does its magic and things just work.
But sometimes you're doing kind of fancy
stuff to take advantage of layer-backed mode.
Maybe you're adding your own custom sublayers
to the AppKit provided view-backing layer
or you're changing properties of layers.
If you're doing things, fancy stuff like that
you'll want to make sure that you are robust
to backing their tree construction and tear down.
AppKit automatically constructs the layer tree for you
when you need it and will tear down those backing layers
for example, when your view is removed for a window
or when we otherwise decide that we don't need them
because the whole idea of the model
is that we can recreate them at will.
So if you're doing stuff like that be robust to
backing layer tree construction and tear down.
Another thing to point out is the
layerContentsRedrawPolicy, sort of a-- maybe a confusingly--
I don't know, I wouldn't say it's confusing but it's
a method that's not necessarily self-explanatory.
This is a new property on NSView that
we added in Snow Leopard and enables you
to do something very powerful in layer-backed mode.
Normally, when you tell us view animator set frame size
to animate the frame resize of a view we have to assume
that at each incremental step along the way during that
animation we have to ask the view to redraw its content
in its entirety because we don't know better.
We don't know what's in your view and
we want to make sure most importantly
that the drawing looks correct at each step along the way.
But for animations often that's
overkill, and it's too much CPU load.
You don't need to redraw at every point along the way.
If you are doing a quick quarter second animation on the
view resize maybe it's sufficient to take the snap shot
of the view's content that you already have in it's
backing layer or maybe redraw it at it's new size,
usually you'll want to do that if
you're resizing to a larger size.
You'll have it redrawn once at the start of
the animation and then you give us permission
by setting the layerContentsRedrawPolicy
to just use that snap shot as an image
and stretch it over the course of the animation.
And you'll see places in TreeView's
example code where we do this.
So, this is I think the first code
sample that demonstrates using that.
Definitely something to look into, this can buy you a lot
of smoothness in animation when you're running layer-backed.
One more sort of general item, share and
reuse repeated content efficiently if you can.
If you have images and other resources
that are drawn over and over in your UI,
think about referencing the same image
rather than copying it of course.
And especially when you're dealing with your
own custom layers, you know if you're going
to set several layers contents property to point to the same
CG image that's something really useful as an optimization.
It saves a lot of space.
And then again plan for scalability.
Think about the maximum complexity of content
that you are realistically going to need to handle
and make sure that your architecture supports that.
So, thinking about scalability gives
a sort of a fundamental choice.
One of the first decisions you get to make is if your
designing something that has complex content like TreeView,
am I going to use views or non-view
objects to represent my content?
And what I mean by non view objects is just really
anything that's not in NSView, you can subclass NSObject
and define your own sorts of objects that have the
basic properties you need such as knowing it's rectangle
within the view and knowing what it needs to draw and so on.
It's a sort of fundamental decision you get to make upfront.
And there are different performance implications for this,
for layer-backed operation versus window-backed operations.
So you may want to consider whether you're
going to primarily be operating window-backed
or layer-backed or whether you want to support both.
Now veteran Cocoa developers will often tell you that
non-view objects can sometimes or often be more lightweight
than NSViews in terms of both memory usage, NSView
really is a very general purpose class rather
than having a very deep class hierarchy.
We have NSView at the root for all of our views
and it encapsulates a lot of functionality
and a lot of possibilities including arbitrary coordinate
transforms, ability to participate in responder chains,
queue loops, and a lot of stuff that, you know if
you were to design your own very specialized object
for representing say nodes in your TreeView or so
on, you might be able to design something that's--
because you know all the assumptions that go into it.
You can design something that's very small and
lightweight to represent your individual parts.
CPU usage also, although to a lesser extent, you know
again, because NSView is a very general purpose class
when we traverse the view tree to do various operations yes,
we do have to make a lot of decisions and branches based on,
is this particular view instance using this feature
so I take this code path if not take this other one.
So more in the sense of memory usage, that's
usually the more significant thing to people.
And so people will sometimes go and build all their
content out of non-view objects and that's fine.
It's a little more work but it's OK if
that's what you find you need to do.
However, I would caution you that factoring
things as views has a lot of benefits especially
for layer-backed mode that people tend to overlook.
And now that we have this new concept of
layer-backed mode in the system as of 10.5 it sort
of changes the game a bit in some important ways.
And one of the most important benefits that you get when
you're layer-backed by factoring your content as views is
that you get caching your content in separate parts.
Each view gets its own backing layer, each layer
gets its own backing store, and so each view--
for each view we have a snap shot
of what the view last drew.
And this makes it very efficient to do animations.
We can just slide things around.
It's very cheap to recomposite bitmaps
or top each rather than having to go back
to the Core's drawing commands
and redraw things from scratch.
And also you get animation versatility
and convenience really from this,
because you can use the view animator syntax to do
moving of views frame origins, frame sizes, and so on.
If you're not using view objects you kind of end up
having to implement more of the animation stuff yourself
so it's very convenient to be able to just say
view animators set frame origin fu and off you go.
Views also provide important culling, event handling,
and accessibility benefits by culling I mean sort
of a gross high level clipping that you
tend to do when you're figuring out, OK,
what parts of my content do I need to draw?
When you factor your content as views
AppKit takes care of all of that.
It's built in.
If you're using non-view objects you have to build
that in yourself have your drawRect do intersection
testing against all your subobjects and so on.
Likewise for event handling, you know there are a lot of
event handling benefits, things you just get for free,
behaviors you get for free with NSViews and accessibility.
Again it's much easier if you factor your content
as views and we'll talk about that again later.
So, by now I guess it's probably obvious which
direction I leaned in designing TreeView.
TreeView is composed as a set of Nested View Subtrees.
So what I mean by that is at the root we
have the TreeView itself a single instance
and that TreeView has a SubtreeView that-- is its
root SubtreeView that's sort of an invisible container
that contains that entire subtree, in
this case the subtree is the whole tree.
That SubtreeView has as a subview, the NodeView,
that represents the root node of the tree
and then we have descendant SubtreeViews
that have their own NodeViews
and those NodeViews have their own children and so on.
Now we also want to draw up connecting lines
between the nodes and it turns out that
for layer-backed mode it's very convenient to
encapsulate those in views and we group them
so that the connecting lines from a given parent node
to all of it's children are drawn by a single view
and that makes it very easy to just move those
around when we're doing animations in
layer-backed mode very efficiently.
So a few benefits that we get from this
design, it groups subtrees logically,
obviously sort of the view structure tends to
mirror the recursive nature of the tree structure
where you have this idea of subtrees
that contain subtrees and so on.
And it also makes it very easy to
sort of move subtrees around if I want
to move a subtree to make room for something else.
I can just move the subtree view's frame
origin and the whole subtree moves.
Whereas if we had chosen more of a flat
design here where maybe we could have made all
of the NodeViews direct subviews of the
TreeView and all sibling views of each other.
Well then if you want to move a subtree you've got
a whole lot of individual parts to move around.
So this grouping kind of helps us, helps make it
easier to do certain things that we want to do.
It simplifies relayout, it simplifies relayout
animation and it gives us the benefits
of content caching when the view is layer-backed.
What are some of the other things you can do?
Some kind of more basic stuff, if your view has custom
properties that you might find interesting to animate
such as colors, or metrics, that you want to
be able to interpolate from the previous value
to a new value rather than just jumping to the new value.
You can make those custom view's properties
first class animatable properties.
If you want, you can override defaultAnimationForKey on your
view subclass and you can do something sort of like this.
Let's say we have a view with a border
color and a border width property.
You look for your property name as the incoming key
string so we say OK if the key is equal to border color
or if it's equal to border width and either of those
cases we want to return a BasicAnimation app , OK,
that BasicAnimation is just saying interpolate from
A to B with some default curve and for any case
that you don't specifically handle always call up to super.
And as I said what this enables you to do is use
the animator syntax with your custom property.
So, it becomes really sort of a first class
animatable property in the system and you can do things
like view animator or setBorderColor to blue color and
we will smoothly interpolate the color from A to B.
Now an important thing that you need to do if you want
to make this work is make sure that your setter methods
or the properties you want to animate perform the necessary
invalidation by which I mean setNeedsDisplay activity.
Because what's going to happen, we'll get this
view animator setBorderColor and we will--
AppKit will incrementally call invoke setBorderColor on
your object with various interpolated values until it gets
to the final value for your border color.
So you're going to get a series of setBorderColor messages
and each time you get one of those you need to make sure
that the affected part of yourself gets redrawn.
So, you want to do setNeedsDisplay in
your appearance related setter methods
and that's all you need to make that work.
So those are sort of the basics for preparing for animation.
Now let's look at drawing and layout.
And one of the most basic decisions that you get
to make upfront is whether your view
is going to be flipped or unflipped.
Where this is a fundamental choice that you have
with NSViews and it affects a lot of stuff in terms
of the way you're going to write your code down
the line for doing your layout computations.
So it's worth giving some thought to it upfront.
isFlipped is the NSView method that determines
whether a view is flipped by default.
If return's NO you may want to override it to return YES.
And the most important thing this does is it determine
the origin of y-axis direction of your views bounds
or it's interior coordinate system, the one
in which it actually draws and handles events.
So if you have an unflipped view it's
origin or it's (0,0) point is going to be
at it's lower left corner positive y-axis pointed upward.
If you have a flipped view origin is at the top
left corner positive y-axis points downward.
Another effect of deciding whether you're
flipped or not is it determines the meaning
or the way the AppKit interprets
your subviews frame origin values.
If you put a subview in an unflip view the subviews frame
origin determines where the subviews lower left corner goes.
If you put a subview on a flip view it determines
where the subviews upper left corner goes.
So, if you think about it this sort of makes sense if you
position a subview at (0,0) you want it to be in the corner
of its parent view but that's something
that people sometimes find surprising.
So it really affects-- you know, you can see how this
will affect if you're doing layout computations to figure
out where your subviews go it matters
whether you're flipped or not.
And if you just change your flipness setting to
the opposite setting you may need to change the way
that your code is written that does your layout.
If you've worked with the CALayer API directly
you may have noticed the geometryFlipped property
which sounds really related but
it's actually distinct in meaning.
It has sort of a recursive meaning.
That's how you flip an entire layer subtree,
so it's not really a direct mapping
to the concept of flipness for views.
One of you declares it's flipped or not flipped that just
affects that immediate view and not any of its descendants.
They each have their own flipness setting.
So how do you decide whether to be flipped or not?
Well in general you just want to think about the natural
growth direction for your content layer, adding new content,
you know, is it like a text view
where you tend to add new stuff
down at the bottom or you tend to add new stuff on top.
And then choose according to that.
It's mostly a matter of convenience and as I alluded to you,
you just want to choose whichever
convention enables you to write simpler code.
If you find yourself writing a lot view,
handling view resize code where you're having
to move things numerically just to get them to
stay in the same place you might want to think
about whether you should use the other flipness convention.
Another minor side effect of this is that if your view is
going to be used as the document view of the scroll view
as in the TreeView demo case this affects what we call
the pinning of the document view when resize happens.
So, when the user resizes the window and resizes
the scroll view content area which portion
of the document view is going to
appear stationary to the user
and which part is going to expand to reveal new content?
Some quick points about drawing, you've
seen a lot of this stuff hopefully before.
Your most basic responsibility as a
custom view is to override drawRect.
You draw whatever content you want and
NSView draws nothing by default so you need
to tell us everything that you want us to draw.
When you're doing this it's good to be sure for
performance reasons that you draw only what you need to.
AppKit passes in an NSRect to the the
drawRect method that gives you bounding boxes
as this is all we're really asking you to draw.
Everything inside here you don't have to draw anything
outside here and in fact AppKit will clip it out.
If you're content is really complicated
and expensive and this happens only
in pretty rare cases, but this is useful to know.
If you have really complex content, a lot
of objects to potentially draw you may want
to use the needsToDrawRect method or
the getRectsBeingDrawn:count method,
because potentially AppKit is really asking
your view to draw a series of rectangles.
We keep track of complex up to date regions to try
to minimize the amount of redraw work that gets done.
The drawRect NSRect parameter is really a
bounding box for that more complex set of rects.
And it's a little bit of an over
simplification for something.
So if you want to be really precise about not
asking things to draw that don't need drawing,
look at the set of rects being asked to draw.
The flip side of that is invalidate only what you need to.
You know, when some state changes in
your viewer you get some new content.
You know, you can always throw up your hands and say
set needs display YES which basically means, "Oh,
I don't know I need to redraw all of myself for all I know."
Sometimes you know that's good enough, that's the
best you can do, but whenever you can determine
that just some part of your views content needs redraw.
Send setNeedsDisplayInRect in preference to setNeedsDisplay,
you know, even if you have to send several of those messages
because there are a few different rectangles you need to
redraw, try to tightly bound the area that you are asking
to have redrawn especially if that drawing
is going to be expensive for you to do.
And lastly, and this is sort of a subtle point that many
people miss when trying to get views to work correctly
in layer-backed mode is be very careful about
which views you're messaging to be invalidated.
This was something that you could, you could be sort of
sloppy about and get away with it in window-backed mode
where everything is sort of sandwiched together and all
that really matters at the end of the day is which part
of the window was asked to be redrawn, whatever part of
the window was marked as needing display we're going to go
through and ask every view that makes a
contribution to that part of the window
from back to front to redraw a part of itself.
But in layer-backed mode again, every view
gets its own content snapshotted separately.
So, you got to make sure that the view you invalidate is the
view that is actually drawing the content that needs redraw.
Sounds simple but it's something that's easily overlooked
and it's something you may need to debug if you are working
in window-backed mode and suddenly
you are going in layer-backed mode
and hey things aren't redrawing when my state changes.
For layout, I just want to point out a
convenience that people rarely take advantage of.
We have a viewWillDraw method now.
This message will get sent recursively
down your view tree before we recurs
to sent drawRect to all of the views that need drawing.
So every view that's going to get a drawRect message
in a given recursive drawing pass
will first get a viewWillDraw message.
And you could override this to do all kinds of stuff.
It's permitted to actually resize your
viewer, resize your subviews at this point,
to perform additional removal of subviews.
This is a great point to do what people have
often wanted to do which is sort of do some work,
just at the very last minute when you
know you're going to be asked to draw.
OK, now I do my layout.
This is very handy for things if you're doing something
whether you're fetching stuff over the network
and you don't want to actually do your layout work until
you have all of the data that you need or until you know
that you need to draw whatever you have at that point.
If you do use viewWillDraw to perform layout
in this way make sure that you mark the view
as needing display whenever layout work is needed.
If the view isn't marked as needing display we're
never going to send you a drawRect or a viewWillDraw.
And always call up to super viewWillDraw when you
override this because that is in fact the mechanism
for continuing the recursion down to your descendant views.
So you can invoke this before or after, or in
the middle of doing your work possibly depending
on whether your descendants will require
you to have done your work first.
So that's very handy for doing layout.
The lowest hanging fruit in the world
of view optimization is opaqueness.
This sense of whether a view is opaque or not.
This is the easiest and most worthwhile
optimization you can do for a lot of views.
By default a view reports itself as not opaque.
A view draws nothing, right, so it doesn't cover anything.
But if you know that your view is
going to cover its entire content area
with 100 percent opaque fill what you can
do is override-- isOpaque to return YES.
And this is very valuable to us
especially in window-backed mode.
It tells AppKit basically don't
bother drawing anything behind me.
Don't bother asking any views behind
me to draw in my rectangle
because I'm going to paint over all of that anyway.
So we can even get away with not drawing
the window background fill behind you
which can be a significant savings especially
if your view covers a large window area.
Now, if your view reports itself as opaque but it
has an overall alphaValue setting of less than 1.0,
less than fully opaque AppKit still does the right thing.
So you don't need to worry about taking into account
what your views alphaValue maybe that's the sort
of overall opacity dial in for how your view is
composited in, it matters mostly in layer-backed mode.
Just take into account your fill coverage and whether
you're filling with an opaque color and you'll see
that TreeView reports itself as opaque for example depending
on whether its background color is an opaque color.
For geometry calculations just some high level points,
always make sure you're using compatible units.
You can get into a lot of trouble if you're not.
Remember when you are using NSPoint values, NSSizes,
NSRects, these are all implicitly defined in terms
of some coordinate system in which coordinate system is, it
usually it's the coordinate system of some particular view
or some window that information isn't carried along
with those geometry values so you've got to be careful
to make sure that your code treats those values
appropriately so if you're writing a mathematical expression
where you're doing some layout
computation you have to make sure that all
of the units that you are using are compatible.
They are on the same views coordinate space, for example.
And in order to get compatible units, you want to
do the necessary conversions between view spaces
and these are the six canonical methods that we
provide on NSView for enabling you to do that,
you can convertPoint values, NSSize values, NSRect values
and you can convert them from the receiver of the message,
from a given view to the receiver
of the message or to a given view.
So, there is a little bit of duplication here.
You can use whatever syntax is more convenient for you.
You can tell A convert point from view
B or tell B convert point to view A.
So these are very useful for making
sure you have compatible units.
There is a special meaning to passing
nil as your view parameter here.
Nil denotes the windows coordinate space and
for window-backed rendering as you may know,
this is a very good space to do any pixel
rounding calculations you need to do.
If you want to wind things on exact pixel boundaries
which at times to produce crisper, sharper rendering,
you often want to do your pixel alignment in window
space but what about when you are going layer-backed?
When you're layer-backed, your backing
layer isn't necessarily aligned
in the same way as your windows pixel coordinate space.
So you want to perform, you're rounding in that
case in the layers interior pixel coordinate space.
So rather than how do you have to worry about this,
we provided a set of new methods for converting to
and from what we call a base space and base space
is implicitly sort of the appropriate space for you
to do pixel rounding calculations whether
your window-backed or layer-backed.
If you are window-backed, it is the same as converting
to and fromView nil, so you might take a point convert it
to base and then do some floor, or round, or ceil
arithmetic on it and then convert it back from base
to do whatever drawing or layout
you need to do in your view.
So these are very handy.
I encourage you to use these when you are doing
writing model pixel rounding code from scratch.
It saves you a lot of work and makes you sort
of window-backed versus layer-backed agnostic.
Your code can work both ways.
Lastly, a quick item about handling
printing or PDF output specially.
We sort of take for granted nowadays that we have this
unified imaging model where you write your drawing code once
and the same ports drawing code can be used to produce
output that goes to your view and its window and also output
to be saved to PDF file or to be sent to a printer.
For most cases, you want to use the exact same code to
do that, but occasionally, you'll want to customize some
of your drawing code for printing and the way to do
that is to look at your current graphics context.
Your graphics context will tell you
whether it is drawing to the screen.
If it says, no I'm not drawing
to the screen, you can assume OK,
I'm being drawn either for, to say
PDF output or I'm being printed.
And you can do things like for example, you
know, a web browser will give you the option,
usually when you print a page, do you want
me to print the web page background or not?
Usually, you want to leave that image
or color fill out 'cause why bother?
So, here is an example of doing something like that.
Only if we're drawing to screen in list view fill its
background, otherwise, the drawing code could be the same.
So, just a quick tip there.
So those are the essentials, sort of I think for drawing
and layout, now let us look at handling of state changes.
You know, handling things that can happen to your view that
you might want to react to but might not have initiated.
First, quickly entering and exiting layer-backed mode.
Again, in most cases, this is magic.
You do not need to worry about it.
If you are doing fancy staff like hanging your additional
layers of our own off of the AppKit provided backing layer,
setLayers is the override point for this because it's
invoked recursively when a view subtree becomes layer-backed
or ceases to be layer-backed every view in the tree will
get either assigned a new layer or assigned layer nil
if we're tearing down the backing layer tree.
Set 1's layer isn't a good place to do this because
only the top level view on the subtree will get it
and this was talked about in detail at the Leveraging
Cocoa's Layer-Backed Views talk back in WWC 2008,
if you can find this on ADC on iTunes, I encourage
you to look at it because it deals with a lot
of the important new ounces of writing
your code for a layer-backed mode.
More mundane kind of everyday stuff and the course of its
life cycle your view will be added to a superview sometimes
and removed from the superview and as part of that, it's
entering a new window or being removed from a window.
So let's say, we have here a text field that has actually
a subview, that X button there at the right hand is meant
to be seen as a subview of the text field.
And let's say, we add the text field to some
view-- superview in the window, what will happen?
The text field itself will get a viewWillMoveToSuperview
message notifying that you're about to be moved
to a new superview and this is a great override point if you
want to be able to do something special when that happens.
You'll get the new superview as a parameter.
You can look at self superview to find out which superview
we were in previously because this is a will notification.
This hasn't happened yet, it's telling
you that change is about to happen.
Now in addition, every view in that subtree is
going to get a viewWillMoveToWindow message,
because you're splicing a view into a new superview.
Now all of the views in that subtree are going to
be in a new window that they weren't in before,
maybe they were in window nil now,
they're moving to a new window.
Again, you get the new window as a
parameter or you can ask for self window
to find out which window you are moving from.
So okay, you move the view in, the changes happen.
Then viewDidMoveToWindow, gets done to every view on
the subtree but viewDidMoveToSuperview get sent only
to the top level view, the text field in this case.
So these can be very useful in particular for
subscribing for notifications related to the window,
you want to know when you go into a new window,
OK, now I want to subscribe to notifications
for certain things happening in this window and then when
you're pulled out of the window, you want to unsubscribe
so you don't get those notifications anymore.
That's a typical usage pattern.
Being hidden or unhidden, usually
not something you need to react too
but maybe some times you're doing
some processing that's expensive.
You are decoding some animation and if your view is hidden,
and it's not displaying anything, why bother eating up CPU
and resources so you might want to turn that stuff
off temporarily or pause it when you're hidden.
So when a view becomes hidden, really hiding handles, hiding
effects an entire view subtree, so if we say set hidden Yes
to the text field it and its button are going
to be hidden and both of those views are going
to get viewDidHide messages and then for unhiding
there is a corresponding viewDidUnhide message.
So again, you know, maybe not something you need to
respond to but if you need to, those are the hooks.
Becoming/Resigning firstResponder.
FirstResponder, for those familiar with other user interface
framework is sort of our concept of the focused view.
It is the view in a window that will get any key
stroke events that go to the window, so in AppKit,
we call that firstResponder and when your view
becomes a candidate to become firstResponder,
maybe the user clicks on it to put the input
focus there or tabs to it if it is the key loop,
you'll get an acceptsFirstResponder message.
AppKit is asking you, hey, can
you become the firstResponder?
If you answer Yes, you will becomeFirstResponder
message and a resignFirstResponder message.
You may also be interested in whether your window is Key
because usually, the combination of being firstResponder
and being in the Key window, being the
window in the application that's designated
to receive Key events is what you used
to determine whether you want to draw,
say a focused range so that you are
focused and actually receive input.
And there are WindowDidBecomeKey
and WindowDidResignKeyNotifications
that you want to look for, for that.
Being resized, very basic thing, it happens to all views,
setFrameSize is a perfectly fine
override point for finding out about that.
If you do override it, always call up to
super and then do whatever layout positioning
of your content or subviews, you need to do.
You can also override resizeWithOldSuperviewSize
and or resizeSubviewsWithOldSize.
However, if you do this, one of the things people get hung
up on sometimes it'll override these methods
and they find they don't get invoked.
What is very important is that you are view
instances have the autoresizesSubviews flag set
to Yes in order for this messages to be sent.
If autoresizesSubviews is off, since these are part
of the autoresizing mechanism these
messages will not get sent to you.
Again, it is always a good practice to call
up to super if you override these methods.
So both of these are fine ways of doing it, a lot of
people like to override setFrameSize because it's reliable,
you don't have to worry about the
autoresizesSubviews flag being set on instances.
Another good thing to do is make sure that
your view can be archived and unarchived
and one of the really exciting things that
this enables you to do is have the potential
to create an Interface Builder
plug-in and inspector for your view
and make it really a first class citizen
among the world of standard views.
And the technique for this is pretty much the same thing you
do for any ordinary object that you want to make archivable,
you override encodeWithCoder to write out your state after
calling up to super to have NSView and your ancestors write
out their state and then you override
initWithCoder to read the state back,
anything that you persisted, you read back in.
And when implementing initWithCoder, you always
want to make sure to access your iBars directly.
It's generally not good practice to invoke your setter
methods because then you may be sending messages
to an object that's not completely
formed and that will confuse your code.
So those are sort of the essentials for being prepared,
for handling stuff that can happen to your view,
our last section for today is handling interaction.
We're going talk about input for a bit and of course,
there are a variety of input sources
that you can receive events from.
Of course keyboard and mouse, the basics, a trackpad
acts for the most part like mouse that's what it is.
But then, if you have a multitouch trackpad on your machine,
it can also sense gestures and
even individual multitouch events.
So, you may want to take advantage of those capabilities.
Likewise, for a tablet, basically acts like mouse if
you want it to, but will also adds new capabilities
that you can take advantage of such
as variable pressure sensitivity,
the ability to sense whether the users are using
the writing tip or the erase tip and so on.
And last but not least, accessibility which
I again, I consider something very essential.
This is, as has been described in other sessions, another
way for the system and system components like VoiceOver,
anybody who's using the accessibility APIs to discover
the structure view user interface and be able to drive it
in various ways and because that is so important,
I want to talk about it first real quickly.
As we all know, enabling accessibility support in your views
and your applications enable the assistive device access
of course for users with visual
impairments and other such disabilities.
But another under appreciated side benefit is that it
provides for the kind of automated user interface testing
that a lot of us are wanting to do nowadays.
We've been doing unit testing on our low level
code for long time and now people are wanting
to automate their user interface testing to detect
regressions and just sort of performance test things.
That's something that you can do.
Once your interface is accessible, if you make your views
accessible, they can be driven not only by VoiceOver
but by anything that you want to use the accessibility
APIs with, any code that you want to write,
AppleScript, your user interface becomes scriptable.
So the basics in making a costume view
accessible, something like TreeView that's complex,
you want to expose both your view and its internal
substructure to accessibility and you'll see in the code
that we specify appropriate accessibility roles for the
views, you return appropriate accessibility attributes
for the roles that we have declared and you also need
to support setting attribute values
and actions for the appropriate role.
And the real take home point with a TreeView example is
again, because we've structured our content using views,
we get a lot of stuff for free and there is, if you
look at it, there's very little accessibility code
in this code sample and there would've been a
lot more work to do, a lot more of a headache
if you had factored things using-- if go off
on your own and use your own non-view objects
to structure things then those are completely
invisible to us and you really have to build up,
do a lot to build up the accessibility capabilities.
So views are your friends once again.
Handling keyboard input, I won't go into this in
great detail because there is a great session right
after this one, in this room at
11:30 about handling keyboard input
and also dealing with menus and menu customization.
But very briefly, if your view wants key events, lot of
people do not realize you have to ask to accept them,
you need to override the acceptsFirstResponder method that
I mentioned earlier to return YES, by default it returns NO.
And then once you've done that, you override
keyDown to receive key press notifications
and keyUp if you want to know when keys are released.
And the interesting event properties for key
events are the string of characters or the sting
of characters that's composed ignoring the modifier
key state, you can get the bit field that tells you
to stay the modifier keys, that being Shift,
Apple or Command, Control, and Option,
and whether the event is an auto repeat event
or whether this is a user initiated key
stroke that you're getting an event for.
Any key events that you do not handle,
you should always pass up to super,
you might also want to respond
to changes in modifier key state.
You are not-- people sometimes expect to get a keyDown
event when somebody presses the Shift or Command key.
It does not work that way.
Those modifier keys are treated specially but there
is a flagsChanged method that you can override
to get notifications of changes to the modifier key state
and again, you can look at the events modifier flags
to figure out which of those modifier
keys are currently pressed or released.
Lastly, I want encourage you to make the parts of your views
content keyboard navigable because a lot of users just want
to have hands on the keyboard all the time and that's
really nice when you can use a view and access all
of its functionality exclusively from the
keyboard when you feel like doing that.
As part of that, you may want to indicate when your view
is focused to receive keystrokes that help the user know
when I type, where is the typing going to go.
I showed earlier how you can tell when you are the
firstResponder view in a window and when your window is key
or not key, once you've determined that, you can use the
NSSetFocusRingStyle API and to clear the NSGraphics.h
to setup a special drawing style that will surround
any subsequent drawing you do with the FocusRing shape,
so might do to say in your drawRect method.
Here, we are looking at, OK.
Am I, my windows firstResponder?
And is my window, the current key window of the application?
And if so, I can-- I'll save graphic
state to isolate this state change
and then set my FocusRingStyle and then do some drawing.
Now when you do this, you want
to be careful about invalidation.
There is a special method that you should
use when your view is showing a FocusRing,
you should always use seKeyboardFocusRingNeedsDisplayInRect
instead of setNeedsDisplayInRect.
Anywhere you would send the a setNeedsDisplayInRect.
The reason for this is that FocusRing drawing
kind of breaks the conventional rules of drawing.
It is not clipped in the same way
that conventional drawing is.
This is what enables you to draw a FocusRing around
the perimeter of your view inside your drawRect
where we would normally clip any
drawing to your view's interior.
So what KeyboardFocusRingNeedsDisplayInRect does it
basically adds a little extra padding to make sure
that the FocusRing spill over, gets erased.
Now spot and events, when the user clicks the main mouse
button, you will get a mouseDown event followed by maybe one
or more mouseDragged events and
then a mouseUp message at the end.
What a lot of people like to do is override mouseDown
and then create what we call a modal event tracking loop
where you'll go into a while loop and you'll pull
events off the application cue looking for mouse events
and you'll eat them all up and handle them
until you see that mouseUp event come and then
and only then does mouseDown return back up to the caller.
We tend to discourage this practice
nowadays, I would strongly encourage you
to use these individual methods as override points.
The problem with creating your own modal tracking loop
is that you know, you are taking over the entire--
what you are doing is you are blocking event
processing that the run loop might otherwise do
and handling event loops sources and things.
So, by using these individual methods,
decomposing your mouse event handling,
you free the run loop to handle other
event sources and things like that.
So that is a lot better, so you might have animations
if you do modal tracking loop approach, you know,
you may have animations that are running on
timers, but oh your timers are not getting serviced
because we are not getting back
to the run loop to service them.
So that's a lot better approach nowadays.
And for handling right mouse button, there are corresponding
rightMouseDown, rightMouseDragged, rightMouseUp messages
and then for mice with more buttons than that, there
is otherMouseDown and otherMouseDragged, otherMouseUp.
The main event properties of interest for mouse messages
buttonNumber of course, which button was pressed.
This is especially important for otherMouseDown
since that's in for any other button.
ClickCount, you know, maybe I'll
be too if it was a double click.
The modifier flags, you also get the state of the
modifier keys at that time of the mouse event,
and then locationInWindow which is the location
of the mouse cursor at the time of the event.
And this is-- it's important to point out, this is provided
in window coordinates, as a lot of people do not realize,
you need to convert this to your views interior
coordinates usually to do something useful with it.
So here we have a mouseDown method.
And we want to get the point in the view, we get the events
locationInWindow and use the convertPoint fromView method
that I mentioned earlier to convert that
point from window space to view space.
Now, it's in view space, now we know what to do
with it because all of our layout calculations
and drawing calculations are presumably
done in our own interior coordinate space.
You can also ask to receive mouseMoved messages if
you're interested in every little motion of the mouse.
But because these are kind of expensive to
send out, we don't send them out by default.
So one of the pitfalls people sometimes run
into, they'll override mouseMoved and say, hey,
why aren't I getting mouseMoved messages.
I'm moving the mouse, because they're expensive
to send out, we don't send them out by default,
you need to send your window message, not the
view but the window saying setAcceptsMouseMoved:
YES and then you'll open the floodgates
and then get the mouseMoved messages.
However, if you can, if you can do what you need to
using one of these other facilities such as tool tips,
if you just want to pop up a little text message, you know,
pop up when the user mouse is over a certain rectangle
in your viewer, you want to change the cursor or actually
do any other kind of arbitrary thing, tracking rects--
tracking areas rather as a more modern form--
the most general form of this, use
these facilities whenever possible.
They're made much more lightweight by the fact that
a lot of the work is done in the windows service
and the app is only called on to do work when
something-- an interesting event actually happens.
So, if you have to, ask for mouseMoved events but if
you don't really need them, if you can get by with this,
these are much lighter weight facilities
for reacting the mouse movements.
Gestures and touch events.
You know, something obviously only users who have
multitouch trackpads are going to be able to use these.
You don't ever want to tie any of your views
functionality exclusively to gestures or touch events
but it provides a nice way to provide some extra polish and
another more natural way to interact with certain aspects
of your view for users who do have multi-touch track pads.
So gestures are the highest level form of this and the
easiest to implement, and gestures are sort of abstractions
that are implemented by the device
layer, they're interpreted for you.
You don't need to opt in the received gestures.
You just override one or more of magnifyWithEvent,
rotateWithEvent, or swipeWithEvent and this will notify you
when the user is making the sort of
familiar gestures that we've all learned now,
magnify being sort of the pinch gesture, rotate, you know,
gesture where you move your fingers
about a common center and swiping.
When you're using either a three-finger swipe on a
trackpad or actually even on a magic mouse nowadays,
you can do a two-finger swipe and
you will get swipeWithEvent.
So, in the TreeView case, if you have a multitouch
trackpad and or a magic mouse and you swipe,
you'll see that it collapses or expands the entire
tree in response to that, just a sort of a demo item.
You might also be interested in
beginGestureWithEvent which tells you when you're--
we're starting a series of gesture messages.
Basically the user has touched the trackpad with one or
more fingers and we're starting to interpret gestures.
So we get a beginGestureWithEvent at the beginning and
then you'll get one or more of these, magnifyWithEvent,
rotateWithEvent, swipeWithEvent
messages, and then at the end
when the user lets their fingers off the
trackpad, you will get an endGestureWithEvent.
So if there is any processing you need to do at the
beginning or end of a series, those are the hooks to do it.
If you want to get really fancy, you can
ask to receive individual touch events.
This is new in Snow Leopard, there's API for this.
You have to opt-in.
This is obviously more complex because
then it is up to you to figure out how
to interpret the touch events individually, but
it's arbitrarily powerful and that you basically get
to define your own gestures, however you want to.
You need to opt-in to receive these,
they are not sent by default.
You need to send setAcceptsTouchEvents to your view,
and if you want resting touches, setWantsRestingTouches.
And then once you've done one or both of those,
you need to override all of the following methods,
touchesBeganWithEvent, touchesMovedWithEvent,
touchesEndedWithEvent, and touchesCancelledWithEvent
and always, always in your implementations of these
call up to super to make everything work great.
Lastly, quick note about tablet input.
Some of your users may have tablets.
This is a bit more specialized in
that, you know, if you want to--
if your app or your view needs to use tablet
input, you probably know it already, you know,
you're implementing a view for
sketching or something like that.
But there are maybe cases where you want to do
clever stuff, we haven't thought of with this.
The basics for handling tablet input, the first high level
item to be aware of is we have an inking system on Mac OS X.
It's a handwriting recognition system, we call that inking.
By default, when someone touches
the pen down over your view,
the system will assume that the
user maybe wants to start inking.
They want to start doing some handwriting that
is to be interpreted and converted to text.
So if you want to handle pen events yourself, you need
to override, shouldBeTreatedAsInkEvent and return NO
when you want to suppress inking
and get the pen events yourself.
NSControl because usually when you got a tablet and you're
interacting with controls, you want to interact with them,
you do not want to start inking when you touch the pen over
a pop-up button say, so NSControl by default returns NO
but NSView if you're subclassing directly, returns YES.
So, you need to override it.
Tablets in addition to acting like mice
provide some special events for you.
There's a tabletProximity event that gets sent when the
pen or stylus comes within sensor range of the tablet
or leaves sensor range and there's also a tablet
point event that gets in as the user moves the pen
around but it isn't necessarily clicking.
So we got locationInWindow.
You can get the absolute position of the pen on
the tablet so that the position that's not mapped
into your screen space by just raw position.
The pressure as I mentioned, which is number from 0 to 1.
Mice only have one pressure for clicking which is 0 or 1.
You know, your clicks always have a pressure of 1.
But with the pen, you can get variable pressure.
You can sense with some devices the rotation or tilt of the
stylus, tangentialPressure on some devices, the buttoMask,
which buttons are pressed or released and whether the event
is a proximity event where the pen is coming into proximity.
And then there are a whole bunch of vendor.
Mostly the vendor defines things where it can
find out what type of device is being used.
And that's pretty much it for input.
So we looked at four major topic areas today, how to
design your views with animation in mind from the beginning
so that you can have the most versatility in order to move
stuff around the way you want to, how do you do drawing
and layout, handling of state changes, things that can
happen to your view that you might want to react to,
and lastly handling of interaction or user input.
The take home thoughts I want to leave you with, with
attention to detail and thought put into the design
of your custom views, you can craft
robust and polished customs views
that ideally will fit naturally
into the Aqua user interface.
And the user of your app won't necessary realize that, oh,
they're using something custom that's not just
something that Apple built right into the UI.
I encourage you to download and
refer to the TreeView code sample.
There's a lot of good stuff in there especially
the layer-backed mode optimization stuff, again,
the first time that we've illustrated some of these things,
and there's also the accompanying view implementor's
checklist, which I hope you'll find useful to go
down as you're trying to look for reminders
when implementing your own custom views.
There's a lot of good related documentation out
there for those who are implementing custom views.
The Cocoa View Programming Guide of course.
I encourage you to refer to the Cocoa Accessibility
Guide when making your views accessible.
Cocoa Drawing Guide, Cocoa Event-Handling Guide.
And again, right after this talk we've got a great
talk coming up on Key Event Handling and menus.
I encourage you to stick around for that.
Also, earlier this week, we had the Design Principles for
Accessibility talk, and also Cocoa Tips and Tricks talked
about both accessibility, and somewhat
related to what TreeView does,
it talked about how NSCollectionView
deals with loading views from nibs.
It's very similar model that TreeView tries to use.
Lastly, I hope you had the opportunity to attend the
API Design for Cocoa and Cocoa Touch talk yesterday.
That was a great talk that really distilled a lot
of the fundamental design philosophy that we used
when developing Cocoa APIs, especially if you're going to be
developing custom views for other people to potentially use.
This talk provides a lot of great guidelines.
So if you didn't get to go to it, I hope you
get a chance to review it on ADC for iTunes.
For more information, you can contact our evangelist.
We've also got developer forums where
you can ask questions and get answers.
Thank you very much.
I hope you enjoyed today's talk.
[ Applause ]