My name is Tony Parker, and I'm an engineer on the Cocoa Team at Apple, and this is Understanding Foundation. So first, let's go over what we're going to talk about today. We'll start by going over what the Foundation framework is, then we'll see how Foundation fits in with your application and the rest of the system, and then we're going to spend most of the time of the talk today going over the most important Foundation features.

We're going to see a high-level overview of many of the Foundation classes, talk about the most important features on those classes, and see examples of how to use them. So, just a couple of prereqs. I'm going to assume that you've worked on an app or you're working on an app for iPhone OS or Mac OS X and that you have familiarity with the basic Foundation concepts like retain and release.

So first, what is Foundation? Foundation provides building block classes. And these building block classes are the fundamental types that are used by all applications on the system. They can be assembled by higher-level software, other frameworks, and applications like yours. Foundation also introduces consisting conventions. One of those I just mentioned, that's retain and release, but there are others and we'll a few examples of that today.

And finally, Foundation is designed to raise lower-level concepts. It can wrap up complex OS level tasks so you can focus on your problem domain instead of nuts and bolts of how exactly to do things. So, where does Foundation fit in a system? If you look at the system as a stack with your application on top and the Core OS pieces on the bottom, then in the middle, we have our frameworks. And Foundation is one of these frameworks. Now, Foundation relies on lower-level frameworks itself, for example, the CFNetwork framework for networking support and Core Foundation.

And there are higher level frameworks that rely on the Foundation framework, on Mac OS X, there's the application kit, and iOS, there's the UI Kit. And generally, the dividing line between those frameworks and Foundation is how closely they relate to the user interface. OK, let's move on to the majority of our talk, and that's going over building blocks. So, first we'll talk about collections, then strings, dates, times, formatters and locales, persistence and archiving, files and URLs, bundles, and we'll wrap up by going over operation queues. So, first up is collections.

So, what's a collection? It's just a place to put your stuff. And there are many features you use on collections. What we're going to talk about today is iteration, sorting the contents of an array, and filtering the contents of a collection. Now, in the Foundation framework, we have three major collections. The first is NSArray.

NSArray's prime directive, if you will, is to preserve the order of the objects that you put into it. An example of where you might use one is if you're storing the results of a 50-meter dash. In that case, of course, it's very important to remember who came first, second, and third. The second major collection is NSDictionary. NSDictionary maps key objects to value objects. You can think of it as an association table.

An example of where you might use one is in a phone book where you map a person's name to their phone number. And the third major collection is NSSet. NSSet maintains unique, unordered objects. An example might be a suggestion box. There, perhaps, you don't care about how many copies of suggestion you get, and you also don't care about the order they are received in. All three of these collections have mutable variants.

And mutable means that it can be modified, so objects can be added or removed from the mutable versions of these collections. Now, the first topic is iterating over the contents of a collection. You've probably already used a for loop, but there are others like NSEnumerator and a while loop. Fast enumeration using the for-in syntax, and new in Snow Leopard and iOS 4 is the use of blocks.

So when you're using a for loop, of course, you're going to get the count first and then you iterate over every object in the array by incrementing that index and retrieving the object from the array at that index. And your code goes inside that loop. You can also use this technique with a dictionary or a set, you just first get the allObjects array and then follow the same technique. And this enumerator is a Foundation object that can keep track of your location and iteration for you.

Here, I'm going to get an object enumerator, that is an enumerator that iterates over the objects in an array or a set. Then I set up a while loop and while next object returns a non-nil value, I have another object to enumerate over. Now note, if you're using this technique with an NSArray, you'll need to keep track of the index separately, if you need it.

For a dictionary, you can enumerate over the keys using a key enumerator and then get the object that corresponds with that key using NSDictionary's objectForKey method. Or if you just need the objects, you can also use an object enumerator. If you're targeting Mac OS 10.5 Leopard or any version of iPhone OS or iOS, then you can use Fast enumeration. And I think it's fast for two reasons. The first is that it actually performs faster.

It uses some implementation details of how these collections are created to retrieve groups of objects and actually have better performance. But I think it's also fast because you have to write less code. So, here we're saying just for-in. Then we don't have to set up the enumerator ourselves. Here the object variable will be assigned to the next object in an array or set until we're finished. And again, there's no easy access to the index, so if you need it, you'll have to keep track of it yourself.

When you fast enumerate over a dictionary, the objects you're getting back are the keys. That means that if you need the objects, you should call objectForKey and get the value that you need in your loop. So, new in Snow Leopard and iOS 4, as I mentioned, is iteration using blocks. I'm not going to go into the details of the block syntax here. The key parts, remember, is that this method, enumerateObjectsUsingBlock, takes a block parameter.

You can tell because there's a caret in front there. And this block is a snippet of code. And that code has some parameters. Here, we're going to get the object, the index of that object, and we have the option to stop the iteration early with that third parameter. And your code goes inside.

For dictionaries, you get the keys and the objects together, so you don't need an extra step to retrieve the object. And for sets, you get the objects. Now, these are the short versions of these methods. One of the benefits of using the block-based iteration is that there is another method, another version which lets you specify things like enumerating reverse or enumerating concurrently. So, how do you choose which of these iteration methods to use? I recommend that you choose based on two things.

The first is what version of the operating system you're targeting. And the second is understanding what data you need. For example, do you need the index in an array or do you need the objects in a dictionary? So, for any version of Mac OS X or iOS, you can use a for loop or an NSEnumerator. If you're targeting Leopard or any version of iOS, then you can use a for loop or Fast enumeration. And on Snow Leopard, or iOS 4 and later, then use Fast enumeration or try our new block-based enumeration methods.

Next is sorting an array. So there are several ways that you can tell NSArray how to determine its sort order. You can use a C function, you can use an objective C method, you can use an NSSort descriptor. This is a class that lets you specify which properties on an array or an object in an array that you want to sort on. And on iOS 4 or Snow Leopard or later, you can use a block-based method.

Now, when you're sorting an immutable or immutable array, there's a sort method that returns a new object, a new collection object. For mutable arrays only, there's a different method you can call, which will sort it in place. So, let's see an example of sorting in place using blocks.

Here, I have an array of names and I want to sort these names by the length of the string, their strings. I want to sort these names by their length. So, I'm going to use this block-based method, NSArray's sortUsingComparator. And you see the parameters of block, and that block has a left and right object. NSArray will call this block as many times as necessary with the appropriate objects to determine what the correct sort order of the contents of your collection are.

Our job is to return an NSComparison results. To determine what the answer is, I'm going to get the length of the left and right strings and then do my comparison. If the left is less than the right, I'm going to return OrderedAscending . If it's the opposite, it's OrderedDescending. And if the lengths are equal, NSOrderedSame.

Now note that this does not mean that the objects are equal, just that they have the same length and they should be sorted equally. And when this method returns, the NSArray will be sorted in place. So, next is filtering. One thing that trips up people sometimes when they're new to Foundation is that they attempt to mutate a collection while they're enumerating it using a block-based method or NSEnumerator or Fast enumeration. And that causes an exception. So, the proper way to filter a collection is to mutate a copy of the collection or to gather the changes on the side and then apply them later.

Let's see an example of the latter. Here, I have another immutable array of strings. This one contains strings with file names in them. And I want to filter out every file name that starts with a dot, perhaps because I'm going to display it to a user. So, I'm going to create another collection. This is an NSIndexSet, which is like an NSSet, but for indexes instead of objects.

And it's called To Remove. The contents of this index set will the items in that array that I want to filter out. And I create it by using one of our new block-based methods, files, indexes of objects passing test, and then, inside this block is where I put my test.

If that string starts with a dot, return Yes. That means put this index in that index set, otherwise return No. And when it's finished, I call remove objects to indexes with that index set and my array will be filtered. There are many more features on collections. You can search collections. You can apply a selector to each item. That's another way of getting the same code run on every object. And this array has slicing and concatenation features. And NSSet has intersection, union and set subtraction features.

So next up is strings. So, strings, and Foundation's string object is called NSString. NSString is the object container for almost all the tests you see on the system, on iOS or Mac OS X. And conceptually, strings are actually very simple. They're just an array of Unicode characters. However, there are many complexities in dealing with strings at the Unicode character level.

So, what we really recommend is that you treat strings as opaque containers. And to help you do that, NSString has a ton of methods on it that let you manipulate strings and do other kinds of string operations. Some of the most common are comparing strings, searching strings and converting the encoding of strings. So, first up is comparing.

There's a simple way to do that, this method called Compare. The parameter is the string that you're comparing the receiver to and the result is another NSComparison result, the same type as we saw a minute ago. If you're comparing strings in a manner that will eventually be displayed to the user, you need to sort them in a -- compare them in a localized manner. And this method is for that, localizedCompare. You see, it takes a string parameter and returns an NSComparison result s well. And furthermore, in Snow Leopard and iOS 4, we added this method, localized Standard Compare.

This encapsulates what we think are the best practices for the options to compare strings with if you're going to display them in a manner to the user. This will take into account the user's current locale, all of their preferences and so on. And finally, if you need to specify more options, there's compare:options:range:locale. An option you might specify is a case insensitive compare. Or you may want to specify only a subset of the string to compare.

Quick example. Here I have two strings, A and B. And when I compare them, the result will be NSOrderAscending. String A comes before string B. I mentioned earlier that you can sort an array based on an objective C method. Here's an example of that. I have an array with Larry, Curley, and Moe in it. And I want to sort this in a localized manner for my user. So, what I do is called the NSArray method, sortedArrayUsingSelector.

I pass in selectorLocalizeCompare. That localize compare message will be sent to every object in that array, and NSArray will use it to determine the sort order. The result will be Curley, Larry, and Moe. For searching strings, there's a similar easy method. It's called rangeOfString. The parameters of the string you're looking for in the receiver. And the result is an NSRange structure.

There's a long form of this, too. It's called rangeOfString:options:range:locale. And you could specify some of the same options like case insensitive. Now, some people ask, why do we return a range? If I passed in the string I'm looking for, I already know the length of it. So why do I need the location and length of the found string as well? Let me show you an example of why that's important.

Here, I have a string that contains San Jose. San Jose is a city about 40 miles south of here, where I live. And I'm going to search this string for the second part, Jose, an easy range of string. And the result will be in NSRange, as I mentioned, with the location of 4 pointing to the capital J at the start and the length of 4 to cover the 4 characters in that string. Now somebody might come along and say, you know that San Jose, the E has an accent over it, like this.

And I'd say, you're completely right. I'm sorry I made that mistake. And instead, I'll change my search string to look for an E with an accent over it. And when I search for it, the result is a range with a location of 4 and a length of 4.

Same as before, right? Well, there's another completely valid way for this string to be stored in memory, and that's like this, with the E and the accent separated as two separate characters. My search string hasn't changed. But when I look for it, the location is 4 and the length is 5. So this is why it's always important to honor the length part of the returned NSRange. This is called a decomposed character, by the way.

A couple other notes about searching strings. If you're looking for something that's not there, you'll get a length of 0. And new in iPhone OS 3.2, we added NSRegularExpressionSearch, a long-requested feature. Here, I'm searching for the word go, with lowercase g. And I'm going to find the first going for this search expression. In iOS 4, we added a lot more regex support. And if you missed it, you should check out this talk on video, Advanced Text Handling for iPhone OS, where we talked about all the different regex options you have available to you now. Next is string encodings.

So, sometimes when people are looking at the string creation methods, they see this encoding parameter and they're a little confused about what it means. But, encodings are not that complicated. It's just a map of numbers to characters. One that you might know already is ASCII. In ASCII, which Foundation represents with NSASCIIStringEncoding, you might have values like 65, 97, and so forth. And those map to the characters of capital A, lowercase a, and you see special characters like tilde also have a mapping.

So, when you create a string from data, it's always important to know what encoding that data is stored in. Here, I have some data from a file or a network or wherever. I'm going to create a string out of that using initWithData encoding. I know in advance that the encoding is UTF8StringEncoding. If you guess about the encoding of your data, it's important to provide your users with a way to override your guess, because if you guess wrong, the result can be characters that look like complete gibberish.

You can also create data in a specified encoding. Here, I've got a string that's going to go to Windows, where UTF16 is a lot more prevalent. So, I call data used in encoding, and I pass an NSUTF16StringEncoding on that-- as a parameter to that method. And my data will be created in the correct form.

One final note about encodings, if in the course of your development you find that you need a char star to pass through a system call, like Open, you should use this NSString convenience method: fileSystemRepresentation. This will get you a character pointer that points to the data in the correct encoding for the system.

And one thing to note about this is that the data that's pointed to by that char star is autoreleased. NSString has many more features, as well. It's got printf-style formatting, enumeration of substrings, lines and paragraphs. And it can do this in a language-independent way, which is a really powerful feature that's hidden behind some very simple API in NSString.

You can do replacement of substrings, path completion, and there's a whole mutable class-- a mutable subclass called NSMutableString, that you can use when you need mutability. Next is dates and times. So, Foundation's date and time classes encapsulate the complexity of date and time calculations. And I'm going to show you an example of where that happens in a second.

They automatically handle user preferences. That means their locale, their language, their settings and so on. Most commonly, you're going to use these classes if you need to represent a date in a calendar, if you need to find the amount of time between two dates, and we have formatter classes that let you format a date or a number correctly for a user no matter where they live.

So, why use these classes? You can do it yourself, right? No problem. Let's do an example. I've got an app which tells somebody how long they need to bake their cake for. And I've got a really huge cake that takes 12 hours to bake. So, we're just going to display the time 12 hours from now to let them know when to go get their cake.

So, as I make my app, I test it. And the date will be November 5, 2006 at 10:00 p.m. I'm going to bake my cake over night. So I expect the answer to be 12 hours from now, to be November 6, 2006 at 10:00 a.m. And the correct answer is the 6th at 10:00 a.m. So, no difference. It worked.

Chip it, right? Except that a year later, a user comes back to you says, you know, I put my cake in on November 4, 2007 at 10:00 p.m. to bake over night, but it came out burnt. It should have been November 5, 2007 at 9:00 a.m. And the reason is because Daylight Savings Time ended. And you say, no problem. I can encode those rules in my app. And actually, the laws about Daylight Savings Time changed between 2006 and 2007. But no problem.

I can put that in my app, and the next time that this happens, I'm going to expect 9:00 a.m. as a result. And then the user comes and says, it didn't work. The correct answer should have been November 5 at 10 a.m. And you might ask why. It's because that the user lives in Phoenix, where Daylight Savings Time isn't used.

So these are just a couple examples of the hundreds or thousands of rules that make up the complexities of handling dates and times. And in Foundation, we have a few classes that can do this for you. So, let's see what those are. The first is NSDate. NSDate represents an invariant point in time. This is really important. Dates are calendar and time zone independent. You can't present an NSDate to a user without knowing a calendar and time zone.

Dates measure their time in seconds, so it's a reference point. The value is a double, so you can represent fractional seconds. The next class is NSCalendar. NSCalendar is what defines the beginning, length, divisions and end of a year. One that you're familiar with is the Gregorian calendar, June 10, 2010, for example. There are others, like the Hebrew calendar. And finally, NSDateComponents. NSDateComponents is basically a simple object structure. It holds storage for years, months, days, minutes and so on.

Again, the exact meaning of these properties depends on the calendar. And in fact, the values in this day components object can be relative or absolute, depending on how you use them. So let's see another example. I'm going to calculate the number of shopping days between the U.S. Thanksgiving holiday and Christmas. Christmas, of course, is on the same date every year, December 25. In the United States, Thanksgiving falls on the fourth Thursday in November. And I'm going to define the shopping season as starting on the day after Thanksgiving, also known as Black Friday, and ending on Christmas Eve.

So, first let's find Christmas. I create a calendar. Remember, we need a calendar. This one is a Gregorian calendar, which is what's used in the United States and we're talking about U.S. Thanksgiving, so it's appropriate. Now, I create one of those date components objects. I'm going to fill it out with some values. I set the year to this year, the month to 12 for December and the day to 25. Then, I call NSCalendars method, dateFromComponents. I pass in my date components object and I get an NSDate result in the current time zone.

I could find Thanksgiving in a similar way. I create another date components object. I set the year, the month to 11 for November, the weekday to 5, because 5 means Thursday in the NS Gregorian calendar, and the weekday ordinal to 4. That means find the fourth Thursday in November of 2010.

I use the same method, dateFromComponents, to get a date representing Thanksgiving in the current time zone. Now, I need to find Black Friday. And I can do that by adding a date component object. Here, you see I'm going to create another one and set its day value to 1. So here, it's a relative value, not an absolute value as we saw on some of the previous slides.

Then I use the NSCalendar method, dateByAddingComponents: toDate: options. I pass in Thanksgiving, and the date components we're adding, the plus 1 day. And the result is a date representing Black Friday. And finally, I can get the answer I was looking for, which is the amount of time between two dates. The result, here, is an NSDate components object. And I call NSCalendarsComponents:fromDate:toDate:options. The components parameter is not a date components object, but a set of flags, which tells NSCalendar which values in the date components we want filled out. I'm interested in days.

You can also specify years, minutes, seconds or any combination of those. The from date is Black Friday, the to date is Christmas, midnight on Christmas will be the end time. And no options. The result, in this case, is 29 days. There are many more features on dates and time classes. You can find the day of the week for a date. Your homework is to find the day of the week that Christmas falls on this year.

There are time zone calculation APIs and methods to convert between calendars. Next is NSFormatter. Foundation has a class called NSFormatter that is for converting values to and from strings. And there are two main NSFormatter subclasses that I want to talk about today. The first is NSDateFormatter that converts dates to or from strings. And the second is NSNumberFormatter, which converts numbers to or from strings.

Both of these have a set of predefined styles, or you can use your own. But I recommend that you stick with the predefined styles, and here's why. Here in the Language and Text Preferences on Mac OS X, you can see I'm in the Formats tab. And my region is set to United States.

These are the standard date formats in that region. There's a full, long, medium and short style. And those correspondents and constants you can use with NSDateFormatter. Let's focus on the short style. In the United States, we put the month first, then the day, and then a two-digit year. And if we look a little bit further down on here, we see a number as well. In the United States, a comma is used as a thousand separator and there's a decimal point.

Now, if instead, your user lives in, say, South Africa, in South Africa, the formats are completely different. The short style, the year, is 2010, there. It's four digits instead of two. The month is zero padded and then the day comes last. And in the numbers section, you see that there's a space for the thousand separator instead of a comma, and a comma instead of a decimal point.

So when you use the predefined styles for date formatters and number formatters, your dates and numbers will look correct for a user no matter where they live. And using them is actually really easy. Here, I'm going to create a date formatter object. I'm going to format the Thanksgiving date that we found earlier. So, I don't care about the time because Thanksgiving lasts all day. And I want to use the long style for the date part.

Then I call stringFromDate, pass in Thanksgiving and the result will be November 25, 2010. Now, here I used the current system time zone and calendar, because I haven't specified them to the formatter. If instead, you're parsing a date, you can use a formatter for that as well. I'm going to create the day formatter, set its date format string. And the contents of this string describe to the date formatter what values I'm looking for in my string that I'm going to pass in, in a second.

Here, it's important, especially if you're parsing a file, to use your own time zone. If you don't set it, it will use the system -- the current system time zone and calendar, which may not be what you're expecting. I know in advance that this is -- these dates I'm parsing are from Los Angeles's time zone. And the calendar will be the Gregorian calendar that we created earlier. Then I pass in a string.

I pass in about now and I will have an NSDate result. I want to point out that the format string uses this Unicode standard, TR35-6. Before you use a string in this method, make sure that you know exactly what the characters in there mean. There are many subtle variations of strings that mean completely different things. So, as a quick summary of dates and formatters, I think this is very important to remember. NSDate and NSCalendar go together when you're using time calculations.

And remember to always use formatters when you're displaying a date or any numbers to your user. That way, it will look correct no matter where they live. Next is persistence and archiving. Persistence is all about storing stuff on disk, and presumable reading it back at a later time.

In Foundation, we have many methods to help you with persistence. The first is property lists. We also have user preferences. Those are kind of persisted data. Keyed archiving. And I also want to touch on large, complex data structures as well. So first, property lists. In Foundation, the NSPropertyListSerialization is the class you're going to use to interact with property lists. Property lists, or plists, for short, store a small amount of structured data, the operative word there being small.

Property lists have the benefit of being cross-platform and human readable when you use the XML format. Plists also have a binary format that is better performing. So you can choose which format to use depending on what your requirements are. There's a very strict set of types that are allowed in a plist. For collections, you may use an NSArray or an NSDictionary.

Strings, dates, numbers, in integer floating point and Boolean forms and NSData. Now, the presence of NSData means that you can stop anything in a data and put it in a plist. But again, I want to emphasize that plists are designed for small amounts of data, so don't put huge files using NSData in property lists.

Let's see a quick example. This morning, I decided I was going to learn Spanish. And so I've made some progress on mapping Spanish color names to English color names. And I want to save that. So, I am going to serialize it to an NSData in XML format. I use NSPropertyListSerialization method, dataWithPropertyList:format:options: error. You see my first parameter is the colors dictionary that I'm saving. The second parameter is the format I want this plist in, XML in this case.

Now, this method, this exact form of this method, is new in Snow Leopard and iOS 4. There are other versions of this method which are very similar that go back to the start of Mac OS X. I chose this one because I want to highlight a pattern that you see across all of Foundation and Cocoa and Cocoa Touch, and that is the use of the error parameter. You see, I passed in the address of an error object, an address of an address of an error object. And I want to know if this method worked.

The correct answer when dealing with error parameters is always to check the return value of the method first, like this. If plist is nil, then the error parameter has been filled out. And I can present it to the user like I do here. NSErrors are designed to be presented to the user. If plist is not nil, the error parameter that you pass in will be completely untouched. Foundation will not modify it in any way. So don't assume that it will be set to nil if there's no error.

The proper way to do this is check the result and then use the error. Now, to read that data out, I'm going to read it from a file, perhaps, using data with contents of URL on NSData. And we'll, of course, talk about URLs later. But now I have my data and I'll pass it to propertyListWithData: options: format: error. I pass in my read data, and the result is the dictionary that we had persisted earlier. And again, make sure that you do the right thing with the error parameter. So next is user defaults.

User defaults are also for small values, but small values that represent user preferences. We organize user defaults by what we call domains. A domain is just a group of defaults. When you read a default, we search domains in a specific order. First is the arguments to the executable. This is what we all a volatile domain. Volatile means that the contents of this domain are not persisted to disk.

Next is the one that you'll probably see most frequently, that's the application domain. These are stored in the user home directory. There's also a global domain, a language domain for locale-specific preferences, and finally, a registration domain. The registration domain is for the factory settings of your application. And let's see an example of how to use that first. So, we recommend that you set up those factory settings early in the start up of your app. Here, in the plus initialize method of a class which uses user defaults, I am going to create some default values.

Here, I'm going to create a dictionary. My first value is a Boolean, FrogBlastVentCore. And next I have a string and also an integer value. Now, to interact with our user default system, you call the NSUser defaults method, standardUserDefaults, to get the user default singleton object. Then, call the registerDefaults method on that object. Pass in your dictionary with your default values and you're good to go.

So, sometime later, we're going to read that value. Here, I'm going to use the NSUser defaults convenience method, boolForKey. I pass in FrogBlastVentCore and the result will be YES, because we searched through our domains and we ended up in the registration domain. And we read the value that we had just set up.

I want to show you how the argument domain works, because it's a really useful debugging tip. Here, I pass in ConferencName and WWDC. I can get that value by just calling the user defaults method stringForKey. And it will check the first domain, which is the argument domain, and get the value out of there, WWDC in this case. Setting user defaults is also very simple.

Here, I'm going to change FrogBlastVentCore to a value of NO by using setBool forKey. And then, sometime later, presumably after my application has quit and restarted, or not, you can call boolForKey, pass in FrogBlastVentCore and the result will be NO, because we found that default in the application domain where it was persisted.

Keyed archiving is next. Keyed archiving is for storing an arbitrary graph of objects. Keyed archiving's primary design purpose is to enable easy backward and forward compatibility. That's because in a keyed archive, the way it works is you associated keys with your object values. That means that you can add a key in a future version of your app, and the past versions of your app don't have to read that key, and vice versa.

Keyed archiving also allows for substitutions during encoding and decoding of objects, and it has the benefit that the objects you store in a keyed archive don't need to be one of those set of property lists types. The way that the keyed archiver knows how to encode and decode your objects is by the NSCoding protocol that your objects implement. So, let's see an example of how you do that. Here, I have a robot object, which implements NSCoding, as you can see. And my robot has several properties, a name, which is an NSString object, another robot, which is this robot's nemesis, and a model number.

Now, to implement NSCoding, I need to fill out just two methods. The first is encodeWithCoder. The parameter to this method will be the keyed archiver. To encode our object, we need to tell the keyed archiver how to store the data that we have as our properties. We do that using methods like these: encodeObject: forKey, encodeInteger: forKey, and so forth. You see them giving every object value in my class a name, like name and nemesis and model. The other method you need to implement initWithCoder. In initWithCoder, the parameter will be the keyed unarchiver.

To init ourselves first, this is an init method, so we need to call Super and return Self at the end. And one caveat here, if you're Super class implements NSCoding, you should call nitiWithCoder and also, in encodeWithCoder, call your Super class as well. Here, my Super class is NSObjects, so this is fine.

And I need to ask the keyed unarchiver for the data that we had given it earlier, using methods like these: decodeObject:forKey, and decodeInteger:forKey. Now, remember that for the objects, you're going to need to copy or retain them as appropriate. Integers, of course, don't need to be copied or retained.

As a quick sample to see that this works, I've got two robot objects. I'm going to set some values on those robot objects. And you notice that R1 and R2 are each other's nemesis. So there's a cycle there. But keyed archiver can handle that. I call ArchivedDataWithRootObject, pass in R2 and the result is an NSData that holds all of the data in that object graph.

To unarchive it, call unarchiveObjectWithData, pass in our data, and the result will be our new robot R3 object. And to verify that it worked, I'm going to check with R3's nemesis' name is and it is Bender, as we set up on our previous slide. I mentioned larger, more complex data structures. I want to point you towards the Core Data framework. Core Data is its own framework. We have support for it in Foundation as well. Core Data has many features. It supports keyed value coding and keyed value observing directly.

You can validate the values that your user inputs and maintain consistency of the relationships between objects. It supports change tracking and undo, sophisticated queries, and unlike the previous forms of persistence that we've seen, incremental editing. There was a session yesterday on Core Data, called Mastering Core Data, that you could check out. And I believe they have another lab this week, as well. If not, check out the documentation online. Core Data is a really powerful framework.

So, I showed you many methods of persistence. Again, how do you pick which one to use? So, if you're storing user preferences, use NSUserDefaults. If you have small files, and you want to cross platform file format, you can consider NSPropertyListSerialization with XML format. If you have an object graph with cycles and non-property lists types, you can consider using the NSKeyedArchiver.

And a real-world example of where the keyed archiver is used is nib files. All of your nib files are keyed archives. And if you have a large data set, or you need database-like features, check out the Core Data framework. And there's one more option which I don't want to neglect.

If you have a very complicated set of data, or a very specific set of data, and you don't need the features that are provided by our Foundation classes, you can use your own custom data format. You probably would be looking at the NSData class to help you out with that. Next is Files and URLs. So, NSURL is our preferred way to reference files and resources. And especially starting in Snow Leopard and iOS 4, you'll see a lot more URL taking methods.

If you're working with a file URL, then you will use our NSFileManager class. If you're working with a network URL, you will use our URL loading classes. So, let's look at some NSURL examples, and then we'll see the others. Here, I'm creating a file URL with a path to a file in my home directory.

NSURL has many methods to manipulate URLs, so you don't need to poke with the characters yourself. This one will delete the last path component and give me a URL that points to my home directory only. I can append a path component and get another file in my home directory. And for network URLs, you can create them like this: URLWithString, I pass in Apple.com, accessed over HTTP.

The NSURL class itself has other features as well. There's a concept of file reference URLs. The primary purpose of these is to maintain your tracking of a file independent of its location on disk. That is, you want a reference to a file and the user moves it. File reference URLs can help in that scenario. On Mac OS X, we have a rich system of file system resource properties. You use them like this: getResourceValue:forKey:error.

Here, I'm passing in the URL effective icon key and the result will be an NSImage that has the icon of that file. There are many more keys you can specify to get localized name, file size, creation, access and modification dates, and label color and many more. You should see the NSURL header on Mac OS X for a full list of all the properties that we support. NSFileManager lets you copy, move, link or delete files.

You use it like this: Create your file manager object, then call methods like: copyItemAtURL: toURL:error, and so forth. NSFileManager also has the capability to enumerate directory contents. This method, contentsOfDirectoryAtURL: includingPropertiesForKeys:options:error, does a shallow enumeration. That is, it won't descend into subdirectories. Now, here you see the second parameter is an array of properties. This is a really efficient way to get a set of properties for a bunch of files in a directory, like all of the icons, all of the modification dates, all of the file sizes and so forth.

NSFileManager also has another method, which lets you enumerate directories in a recursive subfashion, that is, descending into subdirectories. That method returns an NSEnumerator subclass, which you should remember from our first section, is pretty easy to use as well. It also supports finding system directories, application directory of the Desktop and so forth. It has delegate methods for detail control. So you can set up a file manager to call your delegate methods when you're moving files any time an error occurs on any file and scenarios like that.

And you can get and set permissions and other attributes on files. So, if you have a network URL, you're going to check out our URL loading system. The primary class there is NSURLConnection. This class performs the loading of a URL. And there are two modes of operation. The first is asynchronous, using run loops and delegate callbacks. And the second method is synchronous for background threads. Never block your user interface, your main thread, on network access. The other two classes are NSURLRequest and NSURLResponse. These are classes used to store data used when you're loading.

As an example, we are going to load the Apple Home Page with the Apple URL that we created earlier. I create my URL request, and then I create my URL connection object. I call initWithRequest:delegate:startImmediately. I pass in the request and I set ourselves as a delegate. And we'll see those methods in a second. And I tell it to start immediately. But this won't do anything until you run the run loop. So, if this is on your main thread, run the main run loop. And this is also how you avoid blocking your user interface.

These delegate methods will be called when something interesting happens. Before any data is received, you will receive the connection:didReceiveResponse method. Here, I'm going to set up some data to hold the received data that we have -- we're going to receive on our connection. Next is the connection:didReceiveData. This is called one or more times with the actual data that's been received. I'm just going to append it to our received data object.

If something goes wrong, this method will be called, connection:didFailWithError. You should do whatever error handling is appropriate for your app here. And finally, if everything worked great, we're going to get: connection:didFinishLoading. And there, you should use the received data. These classes support other features as well: cache management, authentication, cookies and support for protocols other than HTTP. Next up is bundles.

Bundles are for grouping code and resources. They allow you to include code for different platforms and architectures. For example, on Mac OS X, you can have an app which supports Power PC, Intel 32-bit and Intel 64 bit. Also bundles simplify the loading of localized resources. Let's see an example of that. So, here is an example bundle layout on Mac OS X.

You see, it's for my application, which is a directory. And in the contents, I have an info plist. This is a property list which describes the attributes of my application. Here is the actual executable code. And in the resources subdirectory are non-localized resources. This is the icon for my application.

There are also directories for all of the languages that my application supports. I support English and French. And inside those directories, we have localized resources. Here is a localized image, a main menu, the entire nim file is localized, and localized strings. Now, to load a localized resource, I'm going to first get the application bundle. And I can do that with the NSBundles main bundle method.

Then I call URL for resource with extension, pass in my localized image name and extension, and if my user's running on an English system, they'll get this wonderful image of a stop sign. If instead, they're running on a French system, they will get this wonderful image of a stop sign, which is the same, but in French. And you notice that we didn't have to change our code at all. This behavior is entirely driven by NSBundleCode and the resources that you have in your application bundle.

Now, sometimes it's easy to confuse what the difference between a bundle and a package. Bundles, as we've mentioned, the primary class is NSBundle. Use it for code and resources. An example of a bundle is a framework, like Foundation framework. If you open up System/Library/Frameworks/Foundation.framework, it's a directory. You double-click on it in the finder, you'll see the Foundation executable parts, the headers the resources and so forth. A file package, on the other hand, the primary class is NSFileWrapper.

NSFileWrapper is in Foundation on iOS 4 and the application kit on Mac OS X. File packages are used for user documents. An example might be a rich text document with an image attachment. In that case, the example extension is rftd. The point here is to treat that directory that contains all the appropriate resources and attachments to the text and so forth, as one document in the finder. So the user can't lose associated pieces of their documents. When they double-click on that rich text document, it will open in the default editor.

There are also things which are both bundles and file packages. The most common example of this your application. As you see in its directory, you're still going to use NSBundle, and it stores your application code and resources. But, if the user double-clicks on it in the finder, it opens up the application. It doesn't open up like a directory. Bundle also supports the ability to load other bundles.

This would be a plug in system. You can locate the various components of a bundle, list all the resources of a type. Like I want all the sound files in this specific subdirectory. And, of course, bundle is where you're going to find support for all of your localized strings.

Next up is operations and operation queues. These classes are an object-oriented way to describe work. We put them in there to simplify the design of concurrent applications. There are two main classes. The first is NSOperation. This is a class which encapsulates your work unit. And you use it by subclassing and overriding the main method to define what your work is.

Or use one of our Foundation-provided subclasses. There's NSInvocationOperation, which lets you specify a target and selector. And there's NSBlockOperation, which is new in Snow Leopard and iOS 4, that lets you specify your work as a block. The other main class is NSOperationQueue. This class maintains the list of operations that need to be performed.

And you can think of it as the engine which runs your operations concurrently or serially. As an example, I have an operation queue here with a maximum concurrent operation count of 2. I've put five operations in this queue, and you can see the first two are already running.

Now, as those operations finish executing, the other operations in this queue will begin. And operations can be added to this queue at any time. Those operations will run as well, when there is space available. Let's see how you subclass NSOperation. This is the simplest possible. Class called MyOp and I override main and put my work there. Now, you may want to put initMethods or GettersandSetters or other methods that you can do something more meaningful here. But this will also work. Then later, create your operation queue, create your operation object and add it to the operation queue.

And your operation will start running. So, you might wonder why to bother using all of these complicated, is seems, classes. I can create threads, I can use run loops, but operation queues let you take advantage of a lot of power by adding very minimal complexity. To demonstrate why, I made a sample app that loops through all images, in this case, which is 20 images, and performs some image processing on each of them. Now, when I ran this on my MacBook Pro with two cores, this one will run in a single-threaded fashion. And it took 2.22 seconds to run.

To see if using operationQueue will provide me with a benefit, I added a grand total of four lines of code, create the operation queue, add the middle part as a block operation to my operation queue, close the block and, to simulate the single-threaded case, wait until all those operations are finished. And the result was dramatic, 1.25 seconds. Almost a full second faster.

And all I did was add four lines of code. So, not all problems are as easy to make concurrent as this one is, of course. But, it's worth taking a look at your application, seeing where you might be able to take advantage of the hardware that is in these kinds of computers and add very minimal complexity to your code.

Operation has a few more features. You can set up dependencies between operations even if those operations are in different queues. You can set up priorities of operations within a queue. It has KVO-compatible properties, so you can find out when it's running, when it's finished and so forth. There's new in iOS 4 and Snow Leopard, a completion block, so you can have a block run when you're operation is finished. So, we looked at a lot of classes today. So I want to do a quick summary. We talked about collections and how they are a place to store your stuff.

We talked about iteration, filtering and sorting. Then we talked about strings and the methods that NSString has to let you treat those strings as opaque containers. We talked about dates and times and the classes you can use to avoid burning your users' cakes. Then we talked about persistence and archiving, how you store things on disk and get them back. We went over the files and URLs that let you efficiently perform file system operations. We looked at bundles and how they simplify cross-platform development and localization. And we talked about operation queues that let you take advantage of multi-core computers with minimal complexity.