WWDC2001 Session 138

Transcript

Kind: captions
Language: en
I'm mark Turner on the carbon technology
manager in worldwide developer relations
corefoundation as the name implies
provides a fundamental set of system
services that are widely used throughout
Mac OS 10 and they're available for your
use as well through both carbon and
cocoa and any other application running
on Mac OS 10 and a subset of these
services are also available to Carbon
apps on Mac OS 8 and 9 through carbon
lib so this morning we're going to get a
great overview of some of the services
that you might like to take advantage of
in corefoundation and to begin with I'd
like to introduce Chris Kane from the
core foundation team to start off our
overview welcome Chris well welcome this
session will be an overview of the core
foundation framework it's going to
explain what it is describe some of the
functionality it contains and review
some of the general concepts of usage of
core foundation I'll begin with an
overview
corefoundation is a low-level framework
within Mac os10 it's used to implement
Mac OS 10 and contains functionality
that you can also use in your frameworks
and applications as Mark said both of
the higher-level frameworks cocoa and
carbon used core foundation quite quite
a bit part of core foundation as Mark
said is also available on Mac OS 9 and 8
via carbon Lib this was done to ease
porting of carbonized apps to Mac OS 10
and to bring some of the features of
core foundation to the libraries and
applications on 8 & 9 for similar
reasons part of core foundation is also
available from Darwin or within Darwin
the core foundation API SRC api's on Mac
OS 10 through carbon lib they are also
available in the language is supported
by Carbon lib
there are also C++ wrappers for core
foundation in Apple's C++ frameworks for
Mac OS 10 finally I'll briefly note that
core foundation is often simply just
called CF and I'll probably slip up
during my talk and use that abbreviation
myself so it's good for you to know
right off the bat now why did I call
core foundation a low-level framework
well partly that is due to where it sits
in the overall organizational structure
of Mac OS 10 here we see the usual
simplified diagram of the structure of
the system frameworks on Mac OS 10 core
foundation slips in as part of the core
services umbrella frameworks framework
but I also called core foundation a
low-level framework because it deals
with some of the most basic building
blocks of your applications and your
frameworks these are the data structures
that you use to store information in
your application core foundation
provides several basic opaque data
structures that you can use rather than
having to write your own and core
foundation also provides several
higher-level application services
which are built upon the basic datatypes
and again Apple system applications and
system frameworks within Mac OS 10 use
these facilities quite extensively one
of the key aspects of core foundation is
that it does not provide any graphics or
media related features in the
architecture of Mac OS 10 graphics and
fonts and sounds and those sorts of
things are introduced in higher-level
frameworks frameworks at a higher level
than core foundation within that
architectural diagram so let's begin by
looking at some of those basic data
types we start with CF string a data
type representing strings of characters
strings tend to be one of the most
common data structures in an application
and in Mac OS 10 CF strings are
certainly the most common core
foundation data type in use conceptually
a CF string is an array of unicode
characters however because the
implementation is hidden behind the
opaque CF string type and its functions
a CF string can be smart about how it
stores those characters and use 8-bit
encodings if possible or do other tricks
for performance this takes strings
beyond the traditional domain of say a
an array of 255 characters as in Pascal
in some encoding that is currently in
use in the system or in the application
by packaging up the characters the
length and a fixed encoding in one type
use of strings in an application is
simplified and this makes things like
internationalization easier plus by
making the structure and nature of a
string more predictable passing and
sharing strings among different parts of
an application
and frameworks is made much simpler CF
string has become the way to pass string
data between library api's framework
api's and applications in Mac OS 10 and
it is primarily a primary way in which
strings are just simply stored within an
application as well and as new api's are
introduced they are going to use CF
strings as their parameters and return
values as well
now CF string is an abstract data
structure so in addition to the opaque
data type there are of course a bunch of
functions a bunch of operations on CF
strings first of all there are many ways
to create a CF string you can create
them from a pascal string from a c
string you can create them from an array
of bytes and an encoding you can also
create them from other data if you will
like int sand and what have you using
formatting functionality similar similar
to the c languages printf function there
are also several ways to extract the
characters of a string and do encoding
conversions for example on byte data and
converting them to and from strings this
is very handy when you're getting
information off the internet for example
and need to convert that win latin one
HTML page into something you can more
directly use there are also many other
common and useful operations I give two
examples here of a pending and
concatenation and finding type
operations
in addition to see a string
corefoundation provides a number of
other basic datatype abstractions and
here are some of them not all of them
these are sometimes just simple wrapper
objects for simple data types for
example CF boolean represents either
true or false and that's very
straightforward but in most but most of
the time these data structures also
provide other useful operations as an
example there are a few types to
represent dates and times provided by
core foundation and there are also some
operations to work with the Gregorian
calendar representation of dates you
know years months days hours etc these
functions can do things like figure out
what day of the week it is or what day
what the date will be say 90 days from
now and those are just just
representative examples of some of the
functionalities
now some of these types may seem to be
really too simple to be useful API but
they sometimes come in handy when
dealing with collections and as we'll
see in a bit many of these are central
pieces of the property list mechanism
core foundation but for now I'm going to
talk about the collection data
structures in C F core Foundation a
collection is something that groups
together other objects and it generally
does not matter what the type of those
other objects is in the case of the core
foundation collections it is most
convenient to store other core
foundation objects however the
operations of the collections with
respect to the type of data that they
can hold can be configured with callback
functions to hold any pointer size
values for example you can configure a
collection to hold integers the callback
functions determine what happens when
custom values are added and removed and
how they are compared
when comparison type operations are
applied to a collection
the usefulness of these collections is
that they can manage the memory for you
and I'm going to begin by talking about
to the collections CF array and CF
dictionary first we have the CF array
like an array in the C language the
values are kept in order and are
retrieved out of the CF array using a
zero-based integer index the diagram on
the right is showing this mapping from
indices to values like unlike a CF array
though the values are kept compact in
that if you remove an element from the
middle of an array the values with
higher indices are shifted down one in
order to keep the what you might call
the index space the indices that you
would use to access elements keep those
contiguous in addition to using a CF
array like an array it is quite common
to use them as stacks and queues the
other collection I'm going to review
today is CF dictionary with a CF array
the pointer size values were indexed by
integer in a CF dictionary the values
are indexed by keys and you can see this
in the diagram which are themselves
often see other
corefoundation objects but can be any
pointer sized values in the diagram the
strings are being used as the keys if I
asked for the value with the name key
for example at the top there the
dictionary would return me value 1 a CF
dictionary is somewhat like a struct in
C although you don't want to go and
change all your structures in your C
code to use CF dictionaries there's a
time and a place for CF dictionaries and
for Struck's also unlike a CF array the
values in the dictionary
in any particular order and this is
because CF dictionary is based on
hashing for fast access performance to
the elements
and again to reiterate one of the
principal values of these collections is
that they take care of the memory
storage and algorithms for you
çf dictionary and CFR rate are both
heavily used in the frameworks and
applications of Mac OS 10 and though it
might surprise you see if dictionary
actually tends to be more popular than
CF array dictionary just turns out to be
a very convenient way to structure data
inside of an application one of the ways
in which core foundation uses these
basic data types and collections
together is in property lists a property
list is a group of CF objects of these
types CF string CF data CF number CF
boolean CF date CF array and CF
dictionary and only objects of those
seven types an additional restriction is
that keys of a dictionary in a property
list must be CF strings that any
dictionary within a property lists so
any object or group of objects which
satisfies these constraints is a
property list for example a single CF
string is a property list a single CF
number is a property list but more often
a property list is a collection or
collection of collections for example
you might have an array with
dictionaries in it and the dictionaries
may have dictionaries inside them and
they have keys and values which are
numbers and boolean's and so on the
special thing about property lists this
group of objects special type of group
is that there is a persistent sometimes
called flattened representation which is
an xml-based representation so if you
have a property list in memory you can
easily flatten it oh and write it to a
file for example or send it to another
application
later you can for example if you've
written it to a file read the file back
in and reproduce the original object
graph by using corefoundation to decode
the xml representation back into the
original objects a file which contains a
flattened property list is itself often
referred to as a property list and so
the term is used for both on disk
representations of property list and the
in-memory representation the actual
objects in use property lists are used
extensively in Mac OS 10 as
configuration files and for storage of
preferences and similar things for
example applications in Mac OS 10 are
bundles which are represented by CF
bundle and inside of a bundle is a
property list which is the configuration
information for that CF bundle for that
application will be discussing CF bundle
later in this talk I'm not going to go
into it more right now populus are also
often simply a useful way of modeling
information in an application for
example a property list could describe
print job and a print server might keep
a CF array as a queue of print jobs that
need to be serviced here we have just a
few of the property lists of a
fictitious print job this is not taken
from any actual use on Mac OS 10 note
that all of the keys in the dictionary
are strings the keys are on the left but
the values over on the right are a
mixture strings and dates and boolean
zand numbers the dictionary could also
contain values which are arrays or other
dictionaries but for space reasons we
haven't shown that in this diagram okay
let me get that
now that you've seen some examples of
what core foundation contains let's talk
about some of the overriding
philosophies concepts and conventions
used in core foundation these are the
keys to understanding core foundation
really because once you understand these
you understand the basic operation of
all core foundation api's often
higher-level api's which are based upon
core foundation have also adopted these
conventions and picking up a new bit of
core foundation api's or those
higher-level api's which use the same
conventions is thus much simpler and you
only have to really concentrate on what
those specific api's do what their
specific behaviors are and not have to
worry about figuring out what the memory
management conventions are for example
for those api's in particular it is
important to understand the memory
management strategy and conventions of
core foundation because without that
understanding you really cannot make
proper use of core foundation the
general philosophy behind core
foundation was to create a
high-performance general utility API
that could be used as a substrate that
is an underlying layer beneath both
carbon and cocoa we took many concepts
that were already in cocoa and recast
them down into a C API which could have
wider utility more people could make use
of it and at the same time we extended
them with some additional features the
most important aspect to the design was
that the core foundation API should be
consistent an API with a high degree of
consistency feels like a more unified
and cohesive API than one without
consistency and it is much simpler to
use cohesive API much much more natural
again to pick up new API bits of the API
when the API is going
we also decided to design a peer API
around object-oriented models this gave
us a way to logically structure the API
and means to more easily separate
interface from implementation for
example nearly all data types and core
foundation are opaque and you don't know
how they are implemented this also
allows ample to make improvements in the
implementation over time without being
constrained by open data structures
however it also means that all core
foundation a objects are essentially
going to be allocated off the heap in
part to achieve the goal of
high-performance
API we decided to limit the types of
validation and checking that the API
does limit those to runtime errors thus
there's very little checking of
programming errors like passing in wrong
parameters in the production version of
the library which is the one normally
that users are running it against we
don't have a lot of these any
programming error type checks we put
these instead in the debug version of
the library which uses assertions and
other checks to you look for these sorts
of programming errors like passing in
bad type of object or what have you
one of the ways to run against the debug
version of the library is explained in
the core foundation release notes on the
system
to ensure consistency we adopted several
naming and argument conventions a few of
them are listed here not all of them
certainly the abstract data types and
most higher-level functionality is
grouped into classes or modules like in
many object-oriented or modular
languages we've seen several examples
already like CF string and CF number the
type of an instance of such a class is
named with the class name plus the term
ref and that is an opaque reference to
an object of that class the operations
on that type are functions then that
begin with the class name just as the
type does and then name the operation so
in this example on the slide we have CF
string which is the name of the class
append format which is the name of the
operation another example would be CF
array get count which would return the
number of elements number of values in
the CF array at the time you called that
function also in this object-oriented
way the first argument to these
operations is always the object which is
to be operated upon so for example in CF
string append format you know that the
first argument is going to be a CF
string the exception of course is
functions which create new objects we
call these create functions obviously
there's no in that case there's no
object for them to operate upon they're
creating a new object
to other object jointed concepts we
adopted in corefoundation to limited
extents because of course we're
operating in the C language which is not
naturally object-oriented our
polymorphism and introspection a
polymorphic function is one which can
operate on many different types of
values in corefoundation we have eight
functions which can accept references to
any type any type of CF object as their
parameters and of course in some cases
they also return CF types which are CF
objects these are used to provide
general functionality across all of the
core foundation types let's see as an
example to find out what type an object
is you would use the function CF get
type ID the introspection function there
in the middle C if get type ID and pass
it as an argument a CF object or what
you believe to be a CF object and you
would compare its return value it
returns a code type code you'd compare
that return value with the type codes
published by every core foundation type
in its API so as I said earlier one of
the most important things to understand
about core foundation is its memory
management strategy reference counting
is used on all core foundation objects
for those of you who don't know what
that means
in short reference counting is means
that each object keeps track of the
number of owners that it has that's one
way to think about it at least when the
number of owners of an object is zero
the object can be destroyed an object
may have many different logical owners
in different parts of an application and
generally they don't know about one
another so reference counting is
way to make sure that an object does not
get destroyed before while it is still
in use before it is no longer useful
so CF retain which is one of the
polymorphic functions is used to what we
call take a reference or increment the
reference count of a CF object this is
sometimes called having a retain on the
object as well because it's CF retain is
used to increment the reference count
the function CF release is used to give
up your part ownership in an object core
foundations objects automatically
destroy themselves when their reference
count drops to zero you don't need to do
that but you do need to get rid of any
references that you do have and I'll be
talking about that if you have a
variable which is referencing a core
foundation object but no retain on the
object it could be destroyed out from
under you at any time and there is
really no way to find out that this has
happened there is a date that's called a
dangling reference and dangling
references just as in you know Mac OS 9
or any other system can cause app
misbehavior or a crash sometimes an
retain is automatically given to you see
if retain is used to explicitly take a
reference but sometimes a retain is
automatically given to you when you get
an object say as a return value these
automatic retains in addition to the
ones you explicitly do with CF retain
must be released later when you no
longer need the object if you don't do
that the memory is not going to be freed
and you're gonna have a leak which will
cause your app to use more memory than
it needs to so you have to know when you
need to explicitly make yourself an
owner of a
object and know when you have been given
an ownership in an object and this is a
fundamental question that arises for a
developer how to do I own this
particular object to answer that
question we develop conventions for core
foundation as our example we're going to
look at the naming convention for
functions which return core foundation
objects as that is by far the most
significant convention by convention in
core foundation if a function returns an
object of a core foundation type it uses
the verb get if it is returning the
object to you but not giving a retain on
that object to you as well
that is it is not automatically
returning a part ownership in that
object to you for example CF Dictionary
get value would return the value out of
a CF dictionary but would not give you a
retain increment the reference count
automatically on that object and you
should not release values which are
returned from get functions or you will
create a dangling reference functions
which automatically do retain a returned
object for you use either the verbs copy
or create depending on what the function
is doing functions which create new
instances use create for example the
objects you receive by calling a create
or copy function must have that retain
released by you when you are done with
that object or you're going to have a
leak this is so important it really
deserves repeating get functions never
automatically increment the reference
count create functions and copy
functions always increment the reference
count of objects that they are returning
so these conventions are for the
programmers benefit they're easy to
remember and they're you know ways for
you to know automatically when you see
an API what is happening with respect to
the memory management of that returned
object but the use of the copy and
create as verbs should not be taken to
mean that objects are always being
copied or created a copy or a new object
would not be created when it's not
appropriate for example sometimes it's
done for efficiency another example
would be a type which kept a cache of
all the objects for example that hit it
had created because it was unique in
them in some way create function might
return an object out of the cache rather
than making a new one but the reference
count on that returned object is always
incremented whether it's a cached object
or a new one well and by the way such a
cache will probably be implemented often
be implemented by using a CF dictionary
as I discussed earlier okay there's one
final general facility that I'm going to
discuss before we move on to talking
about some of the higher-level
application services in corefoundation
that's what we call toll-free bridging
this is mostly a benefit for cocoa
applications and frameworks but it also
helps a lot in a mixed cocoa and carbon
environment some of the basic data types
and core foundation are bridged to their
cocoa counterparts such that the core
foundation type and the cocoa type are
interchangeable as the example at the
bottom shows a simple cast is all that's
needed to convert the cocoa and a string
to a core foundation CF string ref and
vice-versa to convert a CF string
a cocoa NS string this allows these core
foundation and cocoa objects to be
easily shared and passed around the
different layers in the Mac os10
architecture the list of core foundation
bridge types is in the foundation
release notes on the system
I haven't listed them here okay now I'd
like to introduce Doug Davidson who will
take us through some of the application
services available from core foundation
Doug
thanks Chris so first I'm going to talk
briefly about some basic application
services available on both Mac OS 9 and
Mac OS 10 that probably most
applications are going to want to use
and then I'm going to go into a little
more depth on some advanced application
services that core foundation provides
on Mac OS 10 so let's start with the
basic application services yep bundle C
up plugins yep preferences so what is a
bundle a bundle is a way of collecting
all the resources associated with an
executable into a single object what can
you put in a bundle you can put in
executables obviously multiple
executables perhaps you can have
different versions of your executables
for Mac OS 9 and 4 and for Mac OS 10 you
can have resources of various types you
can have resource files both localized
and non localized you can have resource
manager style resources again both
localized and non localized and in any
number of localizations you can have you
have a property list the info dictionary
for the bundle which can contain
essentially arbitrary metadata about
that bundle you can have libraries you
can have plugins you can put in
essentially any kind of file of folders
you want into the bundle and CF bundle
is the programmatic interface for
dealing with bundles it has functions
that allow you to locate any of these
objects within the bundle C a bundle is
the heart of our localization strategy
this is what allows us to ship back os10
simultaneously in many different
languages because what C a bundle will
do is automatically provide you with the
correctly localized version of any
particular resource based on the user's
preferences
see a bundle also has some basic code
loading facilities that is it can load
code and allow you to look up symbols
within it and in particular it can do
this transparently whether the code
you're loading or whether the code that
is doing the loading is mokou or CFM on
Mac OS 10 some of you have probably
already use this facility for example to
allow CFM executables on Mac OS 10 to
use functionalities from Mach o
frameworks now the functionality to see
a bundle provides is enough for basic
loading of plugins that is you can load
it and you can look up entry points
within it but what it doesn't do is
manage the interface between the host
and the plug-in for you for that we have
a specialized kind of see a bundle
called
CF plug-in now it's possible you may
already have an interface between host
and plugin that you use and in that case
you might not be interested in see a
plug-in but if you're looking for such a
thing you might want to consider CF
plugin I'm not gonna explain in detail
how it works now it works the the host
looks up interfaces by you you IDs where
the interfaces are C++ or com style
tables of function pointers those get
passed back the best place to learn
about this is through some examples that
we have both in the core foundation
documentation on Mac OS 10 and in the
carbon Lib SDK you'll also find that
there are a few places on the system
where we use CF plug-in as our interface
for plugins for example for plugins for
the printing subsystem on Mac OS 10
and finally CF preferences this is our
general facility for small flexible
application preference storage and these
preferences are usually both per user
and per application although there are
other possibilities and the way this
works is that any particular preference
is referred to by a name which is just a
CF string key and the value of the
preference can be any property list type
so it's very flexible all you do to
store a preference is just set that
preference for the name key the name and
you just look it up by name when you
want it and see a preference this takes
care of everything else handles all the
storage for you currently they're stored
using the flattened XML representation
for property lists there are a couple of
caveats this is not intended for huge
caches or large chunks of binary data or
anything like that also you need to be
sure that anything your application
absolutely relies on is not stored here
these are stored external to the
application and it's possible that users
could erase their preferences you should
be prepared for the possibility that
preferences are missing or corrupt it
for some reason but it is a very
valuable general facility we use it all
over the place
many of our system preferences are
stored in this play for example the
users language preferences that I
mentioned in the case of CF bundle are
stored using CF preferences okay next I
want to go on to some advanced
application services in Mac OS 10
starting with CF run loop which is the
basis for the rest of these and then
I'll discuss some things that our name
will bias the front loop another run
loop what is a run loop
Carbon event-based applications and
cocoa applications have something in
common that is they're both
fundamentally event-driven the way they
work is events come in and pass to the
application to be handled the controls
return you wait for something else to
happen again the fundamental mechanism
that underlies this in both cases is the
run loop now we call it a run loop
because we say that it runs and that of
loops but mainly what it does is it
waits it waits for something interesting
to happen tells you about it you handle
it then it goes back and waits again and
the thing it waits for can be any of a
wide variety of things it might be the
arrival of a mock message might be
perhaps the arrival of a network packet
it might be just the arrival of some
specific time but the important thing
about the run loop is that it can wait
for all these things a wide variety of
things simultaneously efficiently easily
without pulling without using the
processor resources this turns out to be
a very powerful concept now
each thread has exactly one run loop
object now there may be many interfaces
to it corefoundation through carbon
through cocoa they're all dealing with
the same underlying object you can use
any or all of them typically you would
want to use the highest level interfaces
suit your purposes often you will be
using it through carbon or cocoa but if
you happen to be using a core foundation
level source something that the core
foundation level does the run that can
wait for then you would want to use the
core foundation interface to it which is
CF run Luke now one thing about run ups
is that you may not want to wait for any
possible type of event source at any
given time for example you might not
want a certain timer to fire while you
are tracking Mouse moves or something
like so run loops have something called
modes at any given time the run up is
running in a specific mode and any
particular source is registered with a
run loop for only a certain set of modes
so for example in cocoa there are a
couple of specific defined modes that
cocoa use this one the modalpanel run
loop mode is used when it there are
modal panels up and it's waiting on that
there's another one that's used when
typically when the mouse is being
tracked but normally the run won't be
used and run in the default mode and
when you register a source with the run
loop you can register it with a specific
mode or set of modes or you can choose
to register what this will call common
modes which is a set of modes determined
by your application environment in cocoa
would be the default mode plus the modal
panel and event tracking modes now the
run loop by itself is not terribly
interesting what's interesting are the
things that it enables the things you
can do with it primarily the things that
can wait for so at the core foundation
level some of the things that could wait
for are
well first of all you can use it to wait
for raw mock messages or raw network
packets now if you want to do that you
can we have a CF mock port for waiting
for raw mock messages or CF Saka
for waiting for events on a socket
that's useful for example if you have if
you are in a carbon or cocoa application
and you want to wait for these things
you don't have to spawn a separate
thread to do that you can simply be
notified you can get a function callback
within your main event loop and I'm
going to go into some other Co front
loop sources in just a moment you can
create your own it is a little tricky to
do so so another thing I said is you
could wait for it's just the arrival in
a specific time and you can wait for a
single time or repeating sequence of
times with a CF remove timer what you do
is you create the timer tell it what
time or times to wait for and you tell
it what function will be called back on
that time arise if then you attach it to
run loop in a given mode or set of modes
and when the run loop is waiting in one
of those modes it checks to see if your
time has arrived and if your time has
arrived then you get a callback now if
you're waiting for a single time then
the timer is automatically and validated
after that time has arrived and the
timer is fired if you're waiting for a
repeating sequence of times then you
would have to invalidate the timer
yourself when you're done with it now I
talked about romic messages they have a
lot of advantages there the the
fundamental low level local IPC
mechanism and Mac OS 10 but and that
they're very powerful in high
performance and they have a lot of
flexibility but they can be difficult
and tricky to use so we also have a
slightly just one higher level one level
up mechanism built
top of them in core foundation called CF
message port which is a high-performance
low overhead local IPC mechanism and you
can use it either asynchronously sending
messages one-way or synchronously
sending a message in getting a reply the
way you use CF message port is that you
create a local message port on one end
and that these pill ports can be
advertised to other processes on the
system with a name which again is just a
CF string and you create a remote
message port looked up by name to
represent the other end the end what
you're sending does the message that you
send is just a CF data that is a
collection of bytes plus optionally a
message ID manager and the reply if you
want to get a reply back is a CF data so
what the intended receiver of the
message will do is to publish as API the
protocol for this message that is how to
interpret the data or the message ID of
both and whether they'll be apply and
how that should be interpreted the
sender would create a remote message
port to represent the port the
destination of the message and call CF
message ports and requests with a
message to be sent then the receiver
will be notified within its run loop
getting a callback and then if there's a
reply the receiver would return there
apply and then the sender would get
their reply and the message port send
would return
now there's also another mechanism that
we have built on top of these which is
perhaps lesser known but very useful and
this is a broadcast local IPC mechanism
CF notification center and what this
allows you to do is to post happenings
of any sort to an arbitrary possibly
unknown set of receivers these
notifications are identified by their
name and optionally also by another
string that the name again is just a CF
string optionally also by another string
representing the object that sends them
and they can carry with them
essentially arbitrary data again a
property list in this case the sender
would specify what sort of notifications
it's going to send out what their names
would be and what sort of information
they would carry with them and when the
sender wants to send one of these
notifications
it simply posts it and goes on its way
it may choose whether the notifications
are going to be delivered immediately or
not the receivers if anyone anyone on
the system who wants to receive such a
notification simply registers to receive
it senator doesn't have to know anything
about them you register based on the
name optionally also the string
representing the sender and you can
choose whether you want to receive these
notifications immediately or whether you
want them to be delayed because
typically it's not necessary for all the
receivers to get the notification at
once and it's rather expensive to wake
them all up wake up all these processes
at once to deliver the notification
often it's enough if you will simply get
this notification the next time you
become active and if you a notification
might be send multiple times you can
choose to have those coalesced if you
like
so this is very useful mechanism it's
not intended for large amounts of data
or very high volume of frequency but
it's useful in a variety of
circumstances especially for example in
combination with other channels of
information for example if you had a
suite of applications on the system that
all shared a set of preferences and one
application was going to change those
preferences it could send out a
notification to let all the other
applications in the suite know the
preferences have changed and then at
their convenience they can look up the
change value or if you had some area on
the file system that you were working
with you changed it you could send out a
notification to let any interested party
know that it had changed and that they
should go and look it up and see what
had happened all right so now let's
discuss where you can go for more
information about corefoundation there
is documentation on your system and
online there are a number of examples
both with your Mac os10 developer CD and
then the carbon Live SDKs and you should
not forget to look at the release notes
which describe anything new or anything
that has changed in corefoundation and
there are some specialized release notes
that are more like discussions of topics
and depth one on C a bundle and C a
plug-in with some detailed examples C a
plug in one describing the info
dictionary and a bundle in detail and
one on localization and now I'd like to
bring mark Turner back
to wrap things up and star a QA Oh we'll
take a quick look at well I was gonna
say what the roadmap is but let's talk
about this so yeah as I said I'm the
carbon technology manager although a
core foundation is obviously not a
carbon specific technology I'll be happy
to take your questions or comments about
core foundation you can email me at mark
at apple.com
there is the email address here which is
read by the engineering team so that's
another great place to send your
feedback and these two mailing lists I
encourage you to to get on if you're not
already it's a great place to get your
questions answered and share your
knowledge about carbon cocoa and
corefoundation these lists are available
if you haven't been there before there's
a webpage at lists Apple comm where you
could sign up for a great many Apple
mailing lists and now so here we are 10
o'clock Friday morning
most of these sessions have gone by
already but I'd like you to I'd like to
highlight them for you so that you can
look at them on a DC TV or on the DVDs
when you get them first being the cocoa
overview that's a great session just for
those of you who haven't gotten started
yet with cocoa the carbon event manager
is another overview session for carbon
developers we really encourage you to
look into the carbon event manager it
simplifies your code and gets you much
better performance on Mac os10
and then the advanced cocoa topics
session which we had yesterday for more
information about the run loop and other
things that Doug mentioned and if you're
here this afternoon the cocoa feedback
forum would be a great place to
bring your questions about cocoa and of
course corefoundation because many of
the same people will be there
you