iPhone in Action

NSSet, Part Two: Core Data Integration

In the first part of this article I discussed the basics of NSSet: why you'd want to use one and how you can simply access the contents of an NSSet.

As I wrote at the time, my greatest use of NSSet thus far has come when using Core Data. That's because you get an NSSet whenever you access a one-to-many relationship in Core Data. In this article, I'm going to talk about some of the many ways to use NSSets in that context.

All of my examples will center around the data model that I laid out way back in Core Data, Part Two: The Data Model. You might want to look at the graphics there for clarification, but the basic idea that I'll focus on here is that I have a "CardStack" entitity which includes a one-to-many relationship with a "Card" entity called "cards". In other words, it's an entity that represents a deck of cards.

The Simple Core Data Stuff

The simplest thing you can do with Core Data is directly grab an NSSet by looking up a one-to-many relationship. If you want, you can then turn it into an array with the allObjects method call that I mentioned in the last article:

NSArray *theseCards = [fromDeck.cards allObjects];

You can similarly set one-to-many relationships using NSSet, as I did when I set up my cards initially:

[card setImages:[NSSet setWithObject:

    [self setupCardPic:(CardPics *)myCardPic]]];

This example shows the creation of a one-to-many-relationship with a single element, but it's easy enough to use other NSSet messages such as setWithArray: and setWithObjects: to instead add multiple objects to your relationship.

Note that this methodology is also what I was highlighting in Core Data Part Six, There's More Than One Way to Do It. Accessing an NSSet often represents a cleaner, more intuitive way to get to your data. However, it's not just restricted to the simple NSSet lookups described here.

What follows are some more complex NSSet lookups that really highlight the power of the class--and its powerful integration with Core Data. Each of the examples that follows is part of a method directly built into my CardStack class. Thus you'll see references to things like "self.cards" which is just a way to access the cards relationships from inside a CardStack object.

Enumerating an NSSet

Thus far I've talked about how to access an NSSet mainly by turning it into a different sort of object (an NSArray). That's by no means necessary. You can walk through the contents of an NSSet with the help of an NSEnumerator:

-(NSNumber *)worthOfType:(NSString *)thisType {

    NSSet *theseCards = [self cardsOfType:thisType];

    NSEnumerator *thisEnum = [theseCards objectEnumerator];

    Card *thisCard; float totalWorth = 0;

    while (thisCard = [thisEnum nextObject]) {

        totalWorth += [thisCard.worth floatValue];

    }

    return [NSNumber numberWithFloat:totalWorth];

}

This examples figures out the total worth of the cards of a specific type. Once you create an NSEnumerator object with the ObjectEnumerator NSSet message, you can step through it by continuously sending the NSEnumerator a nextObject message. I'll offer one warning that's also noted in the Apple docs: don't change an NSMutableSet as you're enumerating it. I've accidentally done that more than once, and sure enough, it doesn't work.

Mind you, there's an alternative way to do this same thing with key paths, but stepping through an NSSet with an NSEnumerator will probably have many uses for you.

Predicates & NSSets

The cardsOfType: message call in the previous example shows another way that you can use an NSSet, by filtering it with an NSPredicate.

Here's a complete example, with cardsOfType: actually sending a more generic cardsWithKey:Value: message:

-(NSSet *)cardsOfType:(NSString *)type {

    return [self cardsWithKey:@"type" Value:type];

}

-(NSSet *)cardsWithKey:(NSString *)thisKey Value:(id)thisValue {

    NSSet *theseCards = self.cards;

    NSPredicate *predicate =

        [NSPredicate predicateWithFormat:@"%K=%@", thisKey,thisValue];

    NSSet *filteredCards = [theseCards filteredSetUsingPredicate:predicate];

    return filteredCards;

}

As you can see, a simple three-step process lets you reduce your NSSet to a subset based on a predicate.

First, you create an initial NSSet, here with self.cards.

Second, you create a predicate. This example uses the slightly more complex %K=%@ invocation, which allows me to set the key for my predicate dynamically. What I'm really doing in this example is 'type=%@,thisValue'.

Third, you use the NSSet's filteredSetUsingPredicate: message to turn your original NSSet and your NSPredicate in a smaller NSSet subset.

With this example in hand you can now see how it integrates with the previous example, which let me get the worth of just a subset of all my cards.

Key Paths & NSSets

iPhone in Action doesn't discuss key-value coding, but it's a handy way to quickly apply operators to an entire collection of objects. This means that for NSArrays and NSSets you can compute averages, sums, maxes, minimums, counts, and lots more. You should take a look at Apple's Key-Value Coding Guide for more information.

The earlier NSEnumerator example could have been done with key-value coding and a @sum operator (but I left it as was so that I could show off NSEnumerator). Here's a very similar example that instead uses a key-value path:

-(NSNumber *)selectedWorth {

    NSSet *filteredCards = [self cardsSelected];

    NSString *keyPath = [NSString stringWithFormat:@"@sum.worth"];

    NSNumber *worthSum = [filteredCards valueForKeyPath:keyPath];

    return worthSum;

}

As you can see, you create a key path as an NSString. It must have an operator, which begins with an @ symbol, followed by the property that the operator is working on. Thus, here, we're summing the value of the worth property. You then can apply that to an NSSet with a valueForKeyPath: message. That's surely easier than digging through the entire NSSet as I did the first time through.

This example also shows how you can stack up these different NSSet methods, as my original 'filteredSet' was created with an NSPredicate operation (in the cardsSelected method, not shown).

A more complex keyPath might look something like this:

cards.@sum.worth

This shows a different way to invoke a key path. You're putting a property name before the @operator, to dig down through a hierarchy of properties. In this example, the key path wll be operating directly on the self object (the CardStack). It digs down to the cards property, and that's the set that it actually operates on. There it again looks for the @sum of the worth (thus showing a third way to calculate worth using NSSets).

Conclusion

You can do pretty powerful things with NSSets without turning them into NSArrays. This article showed three primary ways to do things: by enumerating an NSSet, by filtering it through an NSPredicate, and by operating upon it with a key value. There's considerable more that you can do with NSPredicates and key values, and you should take a look at Apple's documents on them if you want to know more, but this should get you started.

NSSet, Part One: The Basics

Thus far in approaching the "SDK Missing Classes" that we didn't cover in iPhone in Action, I've talked about UI class objects, since they're uniquely iPhone classes that you're unlikely to have encountered elsewhere. In this article and the next, however, I'm going to take a step back and instead talk about an NS class.

There are many NS classes like NSArray and NSDictionary which we used throughout iPhone in Action, but which required little extra explanation because they matched up with standard variable types--such as arrays and associative arrays--that you've probably used in other programming languages. The NS class that we're going to talk about here, NSSet, is slightly more unique however, and thus I've decided to give it some coverage all of its own.

Why NSSet?

In NSArray and NSDictionary you've already got two perfectly acceptable data storage classes. So, why do you need another? The answer is efficiency. If you always use the right class for the right job, then it's more likely that your programs will run cleanly and quickly.

NSSet is specifically designed for the storage of unique, unordered data. However where you actually get efficiency gains is when you do arbitrary lookups from your data storage. Where you'd have to program an O(n^2) lookup by hand for your NSArray, an NSSet can automatically deliver you an O(n) lookup.

Cocoa with Love has an interesting article on the topic which runs some benchmarks that show, not surprisingly, that NSArray is better at iterating contents and NSSet is better at testing for inclusion. Matt Gallagher goes further than that, however, saying that NSSet is so much more efficient that if you need to both iterate data storage and test it for inclusion, you should use an NSSet.

So, that's why NSSet. How does it work?

Simple Solutions: Any and All

In your iPhone programming, you've probably already used NSSets when working with UITouch objects. Our event reporter program in iPhone in Action showed an example of how to iterate through an NSSet using a for ... loop (see pg. 248). You can also send the messages 'anyObject' or 'allObjects' to an NSSet for easy lookup.

anyObject just returns a random object from the NSSet. I find it particularly helpful when I'm expecting there to be only a single object in an NSSet:

UITouch *thisTouch = [touches anyObject];

allObjects essentially turns your NSSet into an array, which you can then use via your normal array methods:

NSArray *touchesArray = [touches allObjects];

Though these methods are certainly convenient, neither one really speaks to NSSet's greatest strength: inclusion testing.

Needles in NSSet Haystacks

The best method in NSSet is probably containsObject:, which returns a Boolean response if an object is in a set. The following example shows it in simple use. It looks at whether a specific deck of cards is listed in the activeDecks NSSet of cards:

-(BOOL)isActiveDeck:(CardStack *)thisDeck {
    return [activeDecks containsObject:thisDeck];
}

There are numerous more complex NSSet methods which you can use for set comparison, among them isSubsetofSet:, insertsectsSet:, and isEqualToSet:. You should look them up in the NSSet Class Reference is one of them applies to your specific work. Generally, this proliferation of set-related classes outlines how much NSSet is the preferred class when you're doing this type of work.

Creating NSSets

I haven't talked about the creation of NSSets thus far because I figure that in many cases you'll be getting an NSSet of UITouch objects (as noted in this article) or an NSSet from Core Data (as noted in the next article).

However, if you create your own NSSet, you can easily do so with initWithArray:, initWithSet:, or initWithObjects:, all of which work like you'd expect. You may also find a NSMutableSet quite useful for dynamic use, and you can create that with the normal initWithCapacity: used by all the NSMutable classes.

Conclusion

The main purpose of this article was to get you familiar with NSSet as an alternate form of data storage and with the specific advantages that it offers. The actual method calls described in this article are  pretty rudimentary--but they were enough for my own purposes until the last couple of months.

It's only been since I've been using Core Data (as described in my Core Data articles) that I've had to do more complex things with NSSet. I'm going to be describing those more in-depth, with examples from the card program that I'm just finishing up, next week in NSSet, Part Two: Core Data Integration.