To-One Relationships

When you create a to-one relationship, you are saying that one object can contain a pointer to a single managed object of a specific entity. In your example, the Person entity has a single to-one relationship to the Address entity.

Once you’ve added a to-one relationship to an object, you can assign a managed object to the relationship using key-value coding (KVC). For example, you might set the Address entity of a Person managed object like so:

NSManagedObject *address = [NSEntityDescription insertNewObjectForEntityForName:@"Address"
                                        inManagedObjectContext:thePerson.managedObjectContext];
[thePerson setValue:address forKey:@"address"];

Retrieving the object can also be accomplished using KVC, just with attributes:

NSManagedObject *address = [thePerson valueForKey:@"address"];

When you create a custom subclass of NSManagedObject, as you did in the previous chapter, you can use Objective-C properties and dot notation to get and set those properties. The property that represents a to-one relationship is an instance of NSManagedObject or a subclass of NSManagedObject, so setting the address looks just like setting attributes:

NSManagedObject *address = [NSEntityDescription insertNewObjectForEntityForName:@"Address"
                                        inManagedObjectContext:thePerson.managedObjectContext];
thePerson.address = address;

And retrieving a to-one relationship becomes as follows:

NSManagedObject *address = thePerson.address;

In almost every respect, the way you deal with a to-one relationship in code is identical to the way you’ve been dealing with Core Data attributes. You use KVC to get and set the values using Objective-C objects. Instead of using Foundation classes that correspond to different attribute types, you use NSManagedObject or a subclass of NSManagedObject that represents the entity.

To-Many Relationships

To-many relationships allow you to use a relationship to associate multiple managed objects to a particular managed object. This is equivalent to using composition with a collection class such as NSMutableArray or NSMutableSet in Objective-C, as with the children instance variable in the Person class you looked at earlier. In that example, you used an NSMutableArray, which is an editable, ordered collection of objects. That array allows you to add and remove objects at will. If you want to indicate that the person represented by an instance of Person has children, you just add the instance of Person that represents that person’s children to the children array.

In Core Data, it works a little differently. To-many relationships are unordered. They are represented by instances of NSSet, which is an unordered, immutable collection that you can’t change, or by NSMutableSet, an unordered collection that you can change. Here’s how getting a to-many relationship and iterating over its contents might look with an NSSet:

NSSet *children = [thePerson valueForKey:@"children"];
for (NSManagedObject *oneChild in children) {
    // do something
}

On the other hand, if you wish to add or remove managed objects from a to-many relationship, you must ask Core Data to give you an instance of NSMutableSet by calling mutableSetValueForKey: instead of valueForKey:, like so:

NSManagedObject *child = [NSEntityDescription insertNewObjectForEntityForName:@"Person"
                                        inManagedObjectContext:thePerson.managedObjectContext];
NSMutableSet *children = [thePerson mutableSetValueForKey:@"children"];
[children addObject:child];
[children removeObject:child];

If you don’t need to change which objects a particular relationship contains, use valueForKey:, just as with to-one arrays. Don’t call mutableSetValueForKey:if you don’t need to change which objects make up the relationship, as it incurs slightly more overhead than just calling valueForKey:.

In addition to using valueForKey: and mutableSetValueForKey:, Core Data also provides special methods, created dynamically at runtime, that let you add and delete managed objects from a to-many relationship. There are four of these methods per relationship. Each method name incorporates the name of the relationship. The first allows you to add a single object to a relationship

- (void)addXXXObject:(NSManagedObject *)value;

where XXX is the capitalized name of the relationship and value is either an NSManagedObject or a specific subclass of NSManagedObject. In the Person example you’ve been working with, the method to add a child to the children relationship looks like this:

- (void)addChildrenObject:(Person *)value;

The method for deleting a single object follows a similar form.

- (void)removeXXXObject:(NSManagedObject *)value;

The dynamically generated method for adding multiple objects to a relationship takes the following form:

- (void)addXXX:(NSSet *)values;

The method takes an instance of NSSet containing the managed objects to be added. So, the dynamically created method for adding multiple children to your Person managed object is as follows:

- (void)addChildren:(NSSet *)values;

Finally, here’s the method used to remove multiple managed objects from a relationship:

- (void)removeXXX:(NSSet *)values;

Remember that these methods are generated for you when you declare a custom NSManagedObject subclass. When Xcode encounters your NSManagedObject subclass declaration, it creates a category on the subclass that declares the four dynamic methods using the relationship name to construct the method names. Since the methods are generated at runtime, you won’t find any source code in your project that implements the methods. If you never call the methods, you’ll never see the methods. As long as you’ve already created the to-many relationship in your model editor, you don’t need to do anything extra to access these methods. They are created for you and ready to be called.

There is absolutely no difference between using these four methods and using mutableSetValueForKey:. The dynamic methods are just a little more convenient and make your code easier to read.

Inverse Relationships

In Core Data, every relationship can have an inverse relationship. A relationship and its inverse are two sides of the same coin. In your Person object example, the inverse relationship for the children relationship might be a relationship called parent. A relationship does not need to be the same kind as its inverse. A to-one relationship, for example, can have an inverse relationship that is to-many. In fact, this is pretty common. If you think about it in real-world terms, a person can have many children. The inverse is that a child can have only one biological mother and one biological father, but the child can have multiple parents and guardians. So, depending on your needs and the way you modeled the relationship, you might choose to use either a to-one or a to-many relationship for the inverse.

If you add an object to a relationship, Core Data will automatically take care of adding the correct object to the inverse relationship. So, if you had a person named Steve and added a child to Steve, Core Data would automatically make the child’s parent Steve.

Although relationships are not required to have an inverse, Apple generally recommends that you always create and specify the inverse, even if you won’t need to use the inverse relationship in your application. In fact, the compiler will actually warn you if you fail to provide an inverse. There are some exceptions to this general rule, specifically when the inverse relationship will contain an extremely large number of objects, since removing the object from a relationship triggers its removal from the inverse relationship. Removing the inverse will require iterating over the set that represents the inverse, and if that’s a very large set, there could be performance implications. But unless you have a specific reason not to do so, you should model the inverse, as it helps Core Data ensure data integrity. If you have performance issues as a result, it’s relatively easy to remove the inverse relationship later.

Fetched Properties

Relationships allow you to associate managed objects with specific other managed objects. In a way, relationships are sort of like iTunes playlists where you can put specific songs into a list and then play them later. If you’re an iTunes user, you know that there are things called Smart Playlists, which allow you to create playlists based on criteria rather than a list of specific songs. You can create a Smart Playlist, for example, that includes all the songs by a specific artist. Later on, when you buy new songs from that artist, they are added to that Smart Playlist automatically because the playlist is based on criteria and the new songs meet those criteria.

Core Data has something similar. There’s another type of attribute you can add to an entity that will associate a managed object with other managed objects based on criteria, rather than associating specific objects. Instead of adding and removing objects, fetched properties work by creating a predicate that defines which objects should be returned. Predicates, as you may recall, are objects that represent selection criteria. They are primarily used to sort collections and fetch results.

Fetched properties are always immutable. You can’t change their contents at runtime. The criteria are usually specified in the data model (a process that you’ll look at shortly), and then you access the objects that meet that criteria using properties or KVC.

Unlike to-many relationships, fetched properties are ordered collections and can have a specified sort order. Oddly enough, the data model editor doesn’t allow you to specify how fetched properties are sorted. If you care about the order of the objects in a fetched property, you must actually write code to do that, which you’ll look at later in this chapter.

Once you’ve created a fetched property, working with it is pretty straightforward. You just use valueForKey: to retrieve the objects that meet the fetched property’s criteria in an instance of NSArray.

NSArray *olderPeople = [person valueForKey:@"olderPeople"];

If you use a custom NSManagedObject subclass and define a property for the fetched property, you can also use dot notation to retrieve objects that meet the fetched property’s criteria in an NSArray instance, like so:

NSArray *olderPeople = person.olderPeople;

Creating Relationships and Fetched Properties in the Data Model Editor

The first step in using relationships or fetched properties is to add them to your data model. Let’s add the relationship and fetched properties you’ll need in your SuperDB application now. If you look back at Figure 7-1, you can probably guess that you’re going to need a new entity to represent the heroes’ powers, as well as a relationship from your existing Hero entity to the new Power entity you’re going to create. You’ll also need four fetched properties to represent the four different reports.

Delete Rules

Every relationship, regardless of its type, has something called a delete rule, which specifies what happens when one object in the relationship is deleted. There are four possible delete rules:

• Nullify:This is the default delete rule. With this delete rule, when one object is deleted, the inverse relationship is just updated so that it doesn’t point to anything. If the inverse relationship is a to-one relationship, it is set to nil. If the inverse relationship is a to-many relationship, the deleted object will be removed from the inverse relationship. This option ensures that there are no references to the object being deleted, but does nothing more.
• No Action:If you specify a delete rule of No Action, when you delete one object from a relationship, nothing happens to the other object. Instances where you would use this particular rule are extremely rare and are generally limited to one-way relationships with no inverse. This action is rarely used because the other object’s inverse relationship would end up pointing to an object that no longer exists.
• Cascade:If you set the delete rule to Cascade, when you delete a managed object, all the objects in the relationship are also removed. This is a more dangerous option than Nullify, in that deleting one object can result in the deletion of other objects. You would typically choose Cascade when a relationship’s inverse relationship is to-one and the related object is not used in any other relationships. If the object or objects in the relationship are used only for this relationship and not for any other reason, then you probably do want a Cascade rule, so that you don’t leave orphaned objects sitting in the persistent store taking up space.
• Deny:This delete rule option will actually prevent an object from being deleted if there are any objects in this association, making it the safest option in terms of data integrity. The Deny option is not used frequently, but if you have situations where an object shouldn’t be deleted as long as it has any objects in a specific relationship, this is the one you would choose.

What is a Predicate?

A predicate is a statement that returns a Boolean value. Think of them as like a conditional statement within an if or while. They are intended to be used against a set of objects, whether Cocoa or Core Data. Predicates are not dependent on the specific data being searched, but rather provide an abstract way of defining a query to filter data. At its simplest, a predicate compares two values using an operator. An example operator would be ‘==’ to test if two values are equal. There are more sophisticated operators that allow for string comparison (using LIKE or CONTAINS). Predicates can be joined to format a compound predicated. Typically, predicates are joined with an AND or an OR operator.

There are two special variables you can use in the predicate of a fetched property: $FETCH_SOURCE and $FETCHED_PROPERTY. $FETCH_SOURCE refers to the specific instance of a managed object. $FETCHED_PROPERTY is a description of the entity property being fetched.

You can read more detail in Apple’s Predicate Programming Guide (https://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/Predicates/predicates.html ).

So you need to define a predicate that finds all the heroes who are older (i.e. have an earlier birthdate) than the Hero in the detail view. You need to compare your Hero’s birthdate against all the other Hero entities. If $FETCH_SOURCE is your Hero entity, your predicate will be

$FETCH_SOURCE.birthdate > birthdate

Enter this formula into the Predicate field in the attribute inspector. Remember, a date is really just an integer; the later the date, the greater the value.

Rethinking Configuration

Before you go further, take a step back and think about your detail configuration property list. You just added a new section to represent the Powers section. You added a header item to contain the Section Header string. Now you need to add the rows item, right?

Probably not.

Remember that the rows item is an array that tells you how to configure each cell in the section plus what label, cell class, and property key to use. The number of cells is determined by the number of array items. The situation with the Powers section is almost the opposite. You don’t know how many rows you need; that’s coming from the Powers relationship of the Hero entity. And the configuration of each cell should be identical.

There are a couple of approaches you can take. Let’s discuss two ideas.

For the Powers section, you’ll make the rows item a dictionary. The dictionary will contain three String items. The keys will be key, class, and label. These are the same keys you are using for each item when rows is an Array. You can infer that when the rows item is a dictionary, the section is data-driven; but when the rows item is an Array, the section is configuration-driven.

Here’s another approach. For each section, along with the header item, you define an item titled dynamic which will be a Boolean type, If YES, then the section is data-driven; if NO, the section is configuration-driven. For all cases, rows will be an array, but for dynamic sections, it will contain only one entry. If there is no dynamic item, it is the same as dynamic being set to NO.

Either approach will work. There are probably many more ideas we could toss around, but that’s not where we’re heading with this. Regardless of the approach you take, it’s going to require adding a lot of code to handle this logic—code that, so far, you’ve put inside the HeroDetailController class. Adding this parsing logic may belong inside the HeroDetailController, but as it gets more complicated, will only muddy your code. You’re going to refactor your application to pull the property list handling code out of HeroDetailController into a new class, HeroDetailConfiguration. Then you’ll choose which approach to take to handle the data-driven Powers section.

Create a new Objective-C class. Make it a subclass of NSObject and name it HeroDetailConfiguration.

Looking at HeroDetailController, you see that you put the sections array inside a private category. You’ll do the same for HeroDetailConfiguration. Open HeroDetailConfiguration.m and add the following above the @implmentation:

@interface HeroDetailConfiguration ()
@property (strong, nonatomic) NSArray *sections;
@end

Next you need to create your initializer. You want it to open the property list and parse the contents into the sections array.

- (id)init
{
    self = [super init];
    if (self) {
        // Initialization Code
        NSURL *plistURL = [[NSBundle mainBundle] URLForResource:@"HeroDetailConfiguration"                                                   withExtension:@"plist"];
        NSDictionary *plist = [NSDictionary dictionaryWithContentsOfURL:plistURL];
        self.sections = [plist valueForKey:@"sections"];
    }
    return self;
}

Now let’s go back to HeroDetailController.m and see where to use the sections array. The following methods access the HeroDetailController sections array:

numberOfSectionsInTableView:
tableView:numberOfRowsInSection:
tableView:titleForHeaderInSection:
tableView:cellForRowAtIndexPath:

You can use this to design your methods for HeroDetailConfiguration. Right off the bat, you can see the three methods needed:

numberOfSections
numberOfRowsInSection:
headerInSection:

Define the methods in HeroDetailConfiguration.h.

- (NSInteger)numberOfSections;
- (NSInteger)numberOfRowsInSection:(NSInteger)section;
- (NSString *)headerInSection:(NSInteger)section;

Now let’s implement them in HeroDetailConfiguration.m. It should be pretty straightforward.

- (NSInteger)numberOfSections
{
    return self.sections.count;
}
 
- (NSInteger)numberOfRowsInSection:(NSInteger)section
{
    NSDictionary *sectionDict = [self.sections objectAtIndex:section];
    NSArray *rows = [sectionDict objectForKey:@"rows"];
    return rows.count;
}
 
- (NSString *)headerInSection:(NSInteger)section
{
    NSDictionary *sectionDict = [self.sections objectAtIndex:section];
    return [sectionDict objectForKey:@"header"];
}

The implementations are should be pretty much the same as what you implemented before in the HeroDetailController.

Now you need to look at what you’re doing in HeroDetailController tableView:cellForRowAtIndexPath:. The heart of the what’s needed is at the beginning of the method.

    NSUInteger sectionIndex = [indexPath section];
    NSUInteger rowIndex = [indexPath row];
    NSDictionary *section = [self.sections objectAtIndex:sectionIndex];
    NSArray *rows = [section objectForKey:@"rows"];
    NSDictionary *row = [rows objectAtIndex:rowIndex];

Essentially, you get the row dictionary for a specific index path. And that’s what you need your HeroDetailConfiguration object to do for you: give you a row dictionary for an index path. So the method you want would be something like

- (NSDictionary *)rowForIndexPath:(NSIndexPath *)indexPath;

Let’s add it to HeroDetailConfiguration.h. And let’s stub the body in HeroDetailConfiguration.m.

Before you worry about handling the issue of implementing the Powers section, just replicate the functionality you already have in place. In this case, you just add that the five lines of code from the beginning of HeroDetailController tableView:cellForRowAtIndexPath: and put it in your new method.

- (NSDictionary *)rowForIndexPath:(NSIndexPath *)indexPath
{
    NSUInteger sectionIndex = [indexPath section];
    NSUInteger rowIndex = [indexPath row];
    NSDictionary *section = [self.sections objectAtIndex:sectionIndex];
    NSArray *rows = [section objectForKey:@"rows"];
    NSDictionary *row = [rows objectAtIndex:rowIndex];
    return row;
}

Now let’s edit HeroDetailController.m to use your new HeroDetailConfiguration class. First, add the #import at the top (right below the SuperDBEditCell #import).

#import "HeroDetailConfiguration.h"

Replace the sections Property declaration with one for HeroDetailConfiguration.

@property (strong, nonatomic) NSArray *sections;
@property (strong, nonatomic) HeroDetailConfiguration *config;

Replace the sections initialization code in viewDidLoad with config initialization.

    NSURL *plistURL = [[NSBundle mainBundle] URLForResource:@"HeroDetailController" withExtension:@"plist"];
    NSDictionary *plist = [NSDictionary dictionaryWithContentsOfURL:plistURL];
    self.sections = [plist valueForKey:@"sections"];
    self.config = [[HeroDetailConfiguration alloc] init];

Replace the code in numberOfSectionsInTableView.

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView
{
    return self.sections.count;
    return [self.config numberOfSections];
}

Replace the code in tableView:numberOfRowsInSection:.

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
{
    NSDictionary *sectionDict = [self.sections objectAtIndex:section];
    NSArray *rows = [sectionDict objectForKey:@"rows"];
    return row.count;
        return [self.config numberOfRowsInSection:section];
}

Replace the code in tableView:titleForHeaderInSection:.

- (NSString *)tableView:(UITableView *)tableView titleForHeaderInSection:(NSInteger)section
{
    NSDictionary *sectionDict = [self.sections objectAtIndex:section];
    return [sectionDict objectForKey:@"header"];
    return [self.config headerInSection:section];
}

Finally, replace the code in tableView:cellForRowAtIndexPath:.

    NSUInteger sectionIndex = [indexPath section];
    NSUInteger rowIndex = [indexPath row];
    NSDictionary *section = [self.sections objectAtIndex:sectionIndex];
    NSArray *rows = [section objectForKey:@"rows"];
    NSDictionary *row = [rows objectAtIndex:rowIndex];
    NSDictionary *row = [self.config rowForIndexPath:indexPath];

At this point, your app should behave just like it did before you started this refactoring.

Encapsulation and Information Hiding

Before you move on to handling the Power section (you’ll get there soon, promise!), let’s look at HeroDetailController tableView:cellForRowAtIndexPath: once more. Your HeroDetailConfiguration is returning a row dictionary. In turn, you are using that information throughout the remainder of the method.

    NSDictionary *row = [self.config rowForIndexPath:indexPath];
    NSString *cellClassname = [row objectForKey:@"class"];
        ...
    NSArray *values = [row valueForKey:@"values"];
        ...
    cell.key = [row objectForKey:@"key"];
    cell.value = [self.hero valueForKey:[row objectForKey:@"key"]];
    cell.label.text = [row objectForKey:@"label"];

While it’s probably fine to keep things this way, you probably want replace these calls with a method in HeroDetailConfiguration. Why? In short, because of two concepts: encapsulation and information hiding. Information hiding is the idea of hiding the implementation details. Imagine that you change how you store your configuration information. In that case, you’d have to change the way you populate your table view cell. By putting the specific access calls inside HeroDetailConfiguration, you don’t have to worry if your configuration storage mechanism changes. You can freely change the internal implementation without having to worry about your table view cell code. Encapsulation is the idea that you placed all the configuration access code into a single object, HeroDetailConfiguration, rather peppering the access code all over your view controllers.

Looking at the calls to objectForKey: on the row dictionary, you probably want methods like

- (NSString *)cellClassnameForIndexPath:(NSIndexPath *)indexPath;
- (NSArray *)valuesForIndexPath:(NSIndexPath *)indexPath;
- (NSString *)attributeKeyForIndexPath:(NSIndexPath *)indexPath;
- (NSString *)labelForIndexPath:(NSIndexPath *)indexPath;

Add them to HeroDetailConfiguration.h and then add their implementations to HeroDetailConfiguration.m.

- (NSString *)cellClassnameForIndexPath:(NSIndexPath *)indexPath
{
    NSDictionary *row = [self rowForIndexPath:indexPath];
    return [row objectForKey:@"class"];
}
 
- (NSArray *)valuesForIndexPath:(NSIndexPath *)indexPath
{
    NSDictionary *row = [self rowForIndexPath:indexPath];
    return [row objectForKey:@"values"];
}
 
- (NSString *)attributeKeyForIndexPath:(NSIndexPath *)indexPath
{
    NSDictionary *row = [self rowForIndexPath:indexPath];
    return [row objectForKey:@"key"];
}
 
- (NSString *)labelForIndexPath:(NSIndexPath *)indexPath
{
    NSDictionary *row = [self rowForIndexPath:indexPath];
    return [row objectForKey:@"label"];
}

Finally, replace the code in HeroDetailController tableView:cellForRowAtIndexPath: with the new methods.

    NSDictionary *row = [self.config rowForIndexPath:indexPath];
    NSString *cellClassname = [row objectForKey:@"class"];
    NSString *cellClassname = [self.config cellClassnameForIndexPath:indexPath];
        ...
    NSArray *values = [row valueForKey:@"values"];
    NSArray *values = [self.config valuesForIndexPath:indexPath];
        ...
    cell.key = [row objectForKey:@"key"];
    cell.value = [self.hero valueForKey:[row objectForKey:@"key"]];
    cell.label.text = [row objectForKey:@"label"];
    cell.key = [self.config attributeKeyForIndexPath:indexPath];
    cell.value = [self.hero valueForKey:[self.config attributeKeyForIndexPath:indexPath]];
    cell.label.text = [self.config labelForIndexPath:indexPath];

If you wanted to, you could keep refactoring your code, but this is a good point to move on.

Data-Driven Configuration

Okay, now you’re ready to tackle the whole point of this refactoring. It’s time to set up the property list to handle the data-driven Powers section. We detailed two possible approaches earlier. You’re going to take the approach that has you add a dynamic Boolean item and keeps the row item as an array. For items where dynamic is YES, the row item array will have only one element. If there are more, you’re going to ignore them.

Open HeroDetailConfiguration.plist, and navigate to Root sections Item 2. If the disclosure triangle is closed, open it. Select the item named header, and add an two items after it. Name the first item dynamic, set its type to Boolean, and give it a value of YES. Name the second item rows, and set its type to Array. Add a dictionary to the rows Array and give the dictionary three items. Give the three Dictionary items the names of key, class, and label. Leave the type of all three items as String. Set the key value to powers; class to SuperDBCell. Leave the label value blank.

Your property list editor should look something like Figure 7-13.

Now you need the HeroDetailConfiguration to use this new dynamic item.

First, you need to define a method to check if the section you are looking at is dynamic or not. Let’s add that method declaration to HeroDetailConfiguration.h.

- (BOOL)isDynamicSection:(NSInteger)section;

Let’s add the implementation to HeroDetailConfiguration.m.

- (BOOL)isDynamicSection:(NSInteger)section
{
    BOOL dynamic = NO;
 
    NSDictionary *sectionDict = [self.sections objectAtIndex:section];
    NSNumber *dynamicNumber = [sectionDict objectForKey:@"dynamic"];
    if (dynamicNumber != nil)
        dynamic = [dynamicNumber boolValue];
 
    return dynamic;
}

By default, you’ll assume that a section is not dynamic if there’s no dynamic entry in the configuration property list section.

Now, you need to update the rowForIndexPath: method to handle dynamic sections. You just need to change one line.

    NSUInteger rowIndex = [indexPath row];
    NSUInteger rowIndex = ([self isDynamicSection:sectionIndex]) ? 0 : [indexPath row];

While you’re here, add the following method declaration to HeroDetailConfiguration.h:

- (NSString *)dynamicAttributeKeyForSection:(NSInteger)section;

(You’re cheating a little here because you know that this method will make your life easier in a little bit.) The implementation in HeroDetailConfiguration.m will look like this:

- (NSString *)dynamicAttributeKeyForSection:(NSInteger)section
{
    if (![self isDynamicSection:section])
        return nil;
     
    NSIndexPath *indexPath = [NSIndexPath indexPathForRow:0 inSection:section];
    return [self attributeKeyForIndexPath:indexPath];
}

If the section is not dynamic, you’ll return nil. Otherwise, you create an index path and use the existing functionality.

Adding Powers

Now you can move on to updating the HeroDetailController to use this new configuration setup. In HeroDetailController.m, edit tableView:numberOfRowsInSection: like so:

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
{
    NSInteger rowCount = [self.config numberOfRowsInSection:section];
    if ([self.config isDynamicSection:section]) {
        NSString *key = [self.config dynamicAttributeKeyForSection:section];
        NSSet *attributeSet = [self.hero mutableSetValueForKey:key];
        rowCount = attributeSet.count;
    }
         
    return rowCount;
}

You ask the HeroDetailConfiguration to tell you the number of rows in the section. If the section is dynamic, you read the row configuration to determine what property to use from your Hero entity. That property will be a Set, so you need to convert it to an Array to get its size.

Well, you still don’t have any powers in your Hero entity. So you need a way to add new powers to your Hero. Clearly, you should do that when you’re editing the Hero’s details. If you run the app, navigate to the detail view and tap the Edit button, the Powers section is still blank. Go back to the Address Book application: when you need a new address, a cell appears with a green (+) button to add a new address (Figure 7-14). You need to mimic that behavior.

Open HeroDetailController.m and find the tableView:numberOfRowsInSection: method you just modified. Change this line

rowCount = attributeSet.count;

to this

rowCount = (self.editing) ? attributeSet.count+1 : attributeSet.count;

However, this is not enough. You need to have the table view refresh when you enter Edit mode. In setEditing:animated:, add this line

 [self.tableView reloadData];

after the call to super.

If you run the app now and edit your Hero’s details (Figure 7-15), there are two issues. First, the new cell in the Powers section has a strange value. Second, if you watch closely while entering and exiting Edit mode, the transition no longer seems smooth. The cells seem to jump. Everything works but it isn’t a good user experience.

Let’s take a look at fetched results controller delegate methods in the HeroListController. When the updates begin, you call the beginUpdates method on the table view. Then you insert or delete rows with insertRowsAtIndexPath:withRowAnimation: and deleteRowsAtIndexPath:withRowAnimation:. Finally, when the updates are complete, you call endUpdates on the table view. You need to do something similar with the Powers section when entering and leaving Edit mode.

In the private category at the top of HeroDetailController.m, add the new method declaration

- (void)updateDynamicSections:(BOOL)editing;

and call it from setEditing:animated:.

- (void)setEditing:(BOOL)editing animated:(BOOL)animated
{
    [self.tableView beginUpdates];
    [self updateDynamicSections:editing];
    [super setEditing:editing animated:animated];
    [self.tableView endUpdates];
 
    self.navigationItem.rightBarButtonItem = (editing) ? self.saveButton : self.editButtonItem;
    self.navigationItem.leftBarButtonItem = (editing) ? self.cancelButton : self.backButton;
}

Here’s the implementation:

- (void)updateDynamicSections:(BOOL)editing
{
    for (NSInteger section = 0; section < [self.config numberOfSections]; section++) {
        if ([self.config isDynamicSection:section]) {
            NSIndexPath *indexPath;
            NSInteger row = [self tableView:self.tableView numberOfRowsInSection:section];
            if (editing) {
                indexPath = [NSIndexPath indexPathForRow:row inSection:section];
                [self.tableView insertRowsAtIndexPaths:@[indexPath]                                       withRowAnimation:UITableViewRowAnimationAutomatic];
            }
            else {
                indexPath = [NSIndexPath indexPathForRow:row-1 inSection:section];
                [self.tableView deleteRowsAtIndexPaths:@[indexPath]                                       withRowAnimation:UITableViewRowAnimationAutomatic];
            }
        }
    }
}

Now the addition and removal of a cell to Powers section when entering and exiting Edit mode looks much smoother.

Way back in Chapter 4 when you first wrote the HeroDetailController, you implemented the table view delegate method of tableView:editingStyleForRowAtIndexPath:.

- (UITableViewCellEditingStyle)tableView:(UITableView *)tableView            editingStyleForRowAtIndexPath:(NSIndexPath *)indexPath
{
        return UITableViewCellEditingStyleNone;
}

If you recall, this turns off the appearance of the Delete button next to table view cell when the detail view enters Edit mode. Now you want it to show the appropriate button next to the Power section cells.

- (UITableViewCellEditingStyle)tableView:(UITableView *)tableView            editingStyleForRowAtIndexPath:(NSIndexPath *)indexPath
{
    UITableViewCellEditingStyle editStyle = UITableViewCellEditingStyleNone;
    NSInteger section = [indexPath section];
    if ([self.config isDynamicSection:section]) {
        NSInteger rowCount = [self tableView:self.tableView numberOfRowsInSection:section];
        if ([indexPath row] == rowCount-1)
            editStyle = UITableViewCellEditingStyleInsert;
        else
            editStyle = UITableViewCellEditingStyleDelete;
    }
    return editStyle;
}

For the Insert button to work, you need to implement the table view data source method tableView:commitEditingStyle:forRowAtIndexPath: method. This method already exists in HeroDetailController.m, but is commented it out. You can find it in the table view data source section of the jump bar. Uncomment it, and modify it so it looks like this:

- (void)tableView:(UITableView *)tableView         commitEditingStyle:(UITableViewCellEditingStyle)editingStyle         forRowAtIndexPath:(NSIndexPath *)indexPath
{
    NSString *key = [self.config attributeKeyForIndexPath:indexPath];
    NSMutableSet *relationshipSet = [self.hero mutableSetValueForKey:key];
    NSManagedObjectContext *managedObjectContext = [self.hero managedObjectContext];
     
    if (editingStyle == UITableViewCellEditingStyleDelete) {
        // Delete the row from the data source
        NSManagedObject *relationshipObject =             [[relationshipSet allObjects] objectAtIndex:[indexPath row]];
        [relationshipSet removeObject:relationshipObject];
    }
    else if (editingStyle == UITableViewCellEditingStyleInsert) {
        NSEntityDescription *entity = [self.hero entity];
        NSDictionary *relationships = [entity relationshipsByName];
        NSRelationshipDescription *destRelationship = [relationships objectForKey:key];
        NSEntityDescription *destEntity = [destRelationship destinationEntity];
         
        NSManagedObject *relationshipObject =             [NSEntityDescription insertNewObjectForEntityForName:[destEntity name]                                           inManagedObjectContext:managedObjectContext];
        [relationshipSet addObject:relationshipObject];
    }
     
    NSError *error = nil;
    if (![managedObjectContext save:&error]) {
        // need to make HeroDetailController a UIAlertViewDelegate
        UIAlertView *alert =             [[UIAlertView alloc] initWithTitle:NSLocalizedString(@"Error saving entity",                                                                  @"Error saving entity")
                        message:[NSString stringWithFormat:NSLocalizedString(@"Error was: %@, quitting.",                                                                                   @"Error was: %@, quitting."),                                                            [error localizedDescription]]
                       delegate:self
              cancelButtonTitle:NSLocalizedString(@"Aw, Nuts", @"Aw, Nuts")
              otherButtonTitles:nil];
        [alert show];
    }
 
    if (editingStyle == UITableViewCellEditingStyleDelete) {
        // Delete the row from the data source
        [tableView deleteRowsAtIndexPaths:@[indexPath]                          withRowAnimation:UITableViewRowAnimationFade];
    }
    else if (editingStyle == UITableViewCellEditingStyleInsert) {
        // Create a new instance of the appropriate class, insert it into the array,         // and add a new row to the table view
         [tableView insertRowsAtIndexPaths:@[indexPath]                           withRowAnimation:UITableViewRowAnimationAutomatic];
    }
}

Every time you get a new Powers cell, it displays some strange String, Relationship 'powers'... That’s because it’s displaying the results of a valueForKey: call on the Hero entity, with a key of powers. You need to update your tableView:cellForRowAtIndexPath: to handle dynamic sections. Replace

        cell.value = [self.hero valueForKey:[self.config attributeKeyForIndexPath:indexPath]];

with

    if ([self.config isDynamicSection:[indexPath section]]) {
        NSString *key = [self.config attributeKeyForIndexPath:indexPath];
        NSMutableSet *relationshipSet = [self.hero mutableSetValueForKey:key];
        NSArray *relationshipArray = [relationshipSet allObjects];
        if ([indexPath row] != [relationshipArray count]) {
            NSManagedObject *relationshipObject = [relationshipArray objectAtIndex:[indexPath row]];
            cell.value = [relationshipObject valueForKey:@"name"];
            cell.accessoryType = UITableViewCellAccessoryDetailDisclosureButton;
            cell.editingAccessoryType = UITableViewCellAccessoryDetailDisclosureButton;
        }
        else {
            cell.label.text = nil;
            cell.textField.text = @"Add New Power...";
        }
    }
    else {
        cell.value = [self.hero valueForKey:[self.config attributeKeyForIndexPath:indexPath]];
    }

Notice that for a dynamic cell, you set the accessoryType and editingAccessoryType. This is the blue arrow button on the cell’s right edge. Also, you handle the case for when you add an additional cell in Edit mode.

Now you need to add a power view so that you can edit the name and source of your Hero’s new powers.

Renaming the Configuration Class

The HeroDetailConfiguration class name worked because it was used by the HeroDetailController. Now that you’re renaming the Controller class, you should rename the configuration class. Open HeroDetailConfiguration.h, and highlight the class name in the Editor. Select the Edit Refactor Rename menu, and rename the class to ManagedObjectConfiguration (Figure 7-16). Click Preview and review the changes Xcode made. It should change the interface and implementation files, as well as the references in HeroDetailController. When you’re ready, click Save.

There’s a code change you need to make. In the ManagedObjectConfiguration init method, the configuration property list is loaded like this:

NSURL *plistURL = [[NSBundle mainBundle] URLForResource:@"ManagedObjectConfiguration"                                           withExtension:@"plist"];

Remember, you’re keeping the current configuration property list name as HeroDetailController.plist. If you hardcode that name, you won’t have really done anything useful. You need to change the initializer from a simple init method to something like

- (id)initWithResource:(NSString *)resource;

Add that declaration to the ManagedObjectController.h file, inside the @interface. Then you can change the init method to

- (id)init
- (id)initWithResource:(NSString *)resource
{
    self = [super init];
    if (self) {
        // Initialization Code
        NSURL *plistURL = [[NSBundle mainBundle] URLForResource:@"ManagedObjectConfiguration"
                                                   withExtension:@"plist"];
        NSURL *plistURL = [[NSBundle mainBundle] URLForResource:resource withExtension:@"plist"];
        NSDictionary *plist = [NSDictionary dictionaryWithContentsOfURL:plistURL];
        self.sections = [plist valueForKey:@"sections"];
    }
    return self;
}

Now you need to change this line in the HeroDetailController viewDidLoad method

self.config = [[ManagedObjectConfiguration alloc] init];

to

self.config = [[ManagedObjectConfiguration alloc] initWithResource:@"HeroDetailConfiguration"];

At this point your app should still be working, but you’ve only made a very minor change. The big one is coming up next.

Refactoring the Detail Controller

You could just create a new class named ManagedObjectContro ller and move most of the code from HeroDetailController to your new class. But this is adding a layer of complexity (moving code), that could lead to a mistake being made. It’s easier to rename the HeroDetailController, clean up the code to be more generic, and then implement a new HeroDetailController class.

Open HeroDetailController.h and rename the class to ManagedObjectController, using Edit Refactor Rename. Review the proposed changes by Xcode. You’ll notice that Xcode is changing SuperDB.storyboard, which is just an XML file internally. You’ll just have to have faith that Xcode knows what it’s doing. Click Save. You may want to build and run the app, just to check it’s still working.

Refactoring the Hero Instance Variable

In your ManagedObjectEditor class, you have an instance variable called hero. That variable name is no longer representative of what that variable holds, so let’s refactor it as well. Open ManagedObjectEditor.h, and rename the hero property to managedObject. Now you must make the changes in the rest of the app.

Open ManagedObjectEditor.m, and find all occurrences of

self.hero

and change them to

self.managedObject

Lastly, edit HeroListContoller.m, and change this line in prepareForSegue:sender

detailController.hero = sender;

to

detailController.managedObject = sender;

Save your work, and check the app.

A Little More Abstraction

While you’re working on ManagedObjectController, take this opportunity to add some discrete functionality. Specifically, when you add or remove powers, you put the code to do this in tableView:commitEditingStyle:forRowAtIndexPath:. Let’s split this code into specific methods to add and remove Relationship objects. Add the following method declarations to ManagedObjectController.h:

- (NSManagedObject *)addRelationshipObjectForSection:(NSInteger)section;
- (void)removeRelationshipObjectInIndexPath:(NSIndexPath *)indexPath;

Before you implement these methods, add a new private method. Find the private category in ManagedObjectController.m, and add this line:

- (void)saveManagedObjectContext;

Then, add the implementation:

- (void)saveManagedObjectContext
{
    NSError *error;
    if (![self.managedObject.managedObjectContext save:&error]) {
        // need to make HeroDetailController a UIAlertViewDelegate
        UIAlertView *alert =             [[UIAlertView alloc] initWithTitle:NSLocalizedString(@"Error saving entity",                                                                  @"Error saving entity")
                       message:[NSString stringWithFormat:NSLocalizedString(@"Error was: %@, quitting.",                                                                          @"Error was: %@, quitting."),                                                               [error localizedDescription]]
                       delegate:self
             cancelButtonTitle:NSLocalizedString(@"Aw, Nuts", @"Aw, Nuts")
             otherButtonTitles:nil];
        [alert show];
    }
}

Does this look familiar? It should; it’s essentially the code in the save method. So update the following lines in the save method from

    NSError *error;
    if (![self.managedObject.managedObjectContext save:&error])
        NSLog(@"Error saving: %@", [error localizedDescription]);

into

    [self saveManagedObjectContext];

Now you can add the new method implementations (we added them just for the @end in ManagedObjectController.m).

#pragma mark - Instance Methods
 
- (NSManagedObject *)addRelationshipObjectForSection:(NSInteger)section
{
    NSString *key = [self.config dynamicAttributeKeyForSection:section];
    NSMutableSet *relationshipSet = [self.managedObject mutableSetValueForKey:key];
     
    NSEntityDescription *entity = [self.managedObject entity];
    NSDictionary *relationships = [entity relationshipsByName];
    NSRelationshipDescription *destRelationship = [relationships objectForKey:key];
    NSEntityDescription *destEntity = [destRelationship destinationEntity];
     
    NSManagedObject *relationshipObject =         [NSEntityDescription insertNewObjectForEntityForName:[destEntity name]                                        inManagedObjectContext:self.managedObject.managedObjectContext];
    [relationshipSet addObject:relationshipObject];
    [self saveManagedObjectContext];
    return relationshipObject;
}
 
- (void)removeRelationshipObjectInIndexPath:(NSIndexPath *)indexPath
{
    NSString *key = [self.config dynamicAttributeKeyForSection:[indexPath section]];
    NSMutableSet *relationshipSet = [self.managedObject mutableSetValueForKey:key];
    NSManagedObject *relationshipObject =         [[relationshipSet allObjects] objectAtIndex:[indexPath row]];
    [relationshipSet removeObject:relationshipObject];
    [self saveManagedObjectContext];
}

Finally, change tableView:commitEditingStyle:forRowAtIndexPath:.

- (void)tableView:(UITableView *)tableView         commitEditingStyle:(UITableViewCellEditingStyle)editingStyle         forRowAtIndexPath:(NSIndexPath *)indexPath
{
    if (editingStyle == UITableViewCellEditingStyleDelete) {
        // Delete the row from the data source
        [tableView deleteRowsAtIndexPaths:@[indexPath] withRowAnimation:UITableViewRowAnimationFade];
    }
    else if (editingStyle == UITableViewCellEditingStyleInsert) {
        // Create a new instance of the appropriate class, insert it into the array,         // and add a new row to the table view
        [tableView insertRowsAtIndexPaths:@[indexPath]                          withRowAnimation:UITableViewRowAnimationAutomatic];
    }
}

You’re not adding or removing the Relationship object anymore. All you’re doing is adding or removing table view cells. You’ll see why soon.

A New HeroDetailController

Now you want to create a new HeroDetailController to replace the one you renamed to the ManagedObjectController. Create a new Objective-C class, name it HeroDetailController, and make it a subclass of ManagedObjectController. Before you modify the HeroDetailController, you need to make some changes to the ManagedObjectController. You need to move the property that holds the configuration information from the private category to the @interface declaration. Edit ManagedObjectController.h, and declare the configuration property (you also need to declare the ManagedObjectConfiguration).

#import <UIKit/UIKit.h>
 
@class ManagedObjectConfiguration;
 
@interface ManagedObjectController : UITableViewController
 
@property (strong, nonatomic) ManagedObjectConfiguration *config;
@property (strong, nonatomic) NSManagedObject *managedObject;
 
- (NSManagedObject *)addRelationshipObjectForSection:(NSInteger)section;
- (void)removeRelationshipObjectInIndexPath:(NSIndexPath *)indexPath;
 
@end

Since you moved the configuration, you need to delete the declaration in ManagedObjectController.m.

@interface ManagedObjectController ()
@property (strong, nonatomic) ManagedObjectConfiguration *config;
@property (nonatomic, strong) UIBarButtonItem *saveButton;

You also need to delete the assignment in viewDidLoad.

- (void)viewDidLoad
{
    [super viewDidLoad];
        ...
    self.config = [[ManagedObjectConfiguration alloc] initWithResource:@"HeroDetailConfiguration"];
}

Now you can update HeroDetailController. All you need to do is load your configuration property list. Your HeroDetailController.m should look like this:

#import "HeroDetailController.h"
#import "ManagedObjectConfiguration.h"
 
@implementation HeroDetailController
 
- (void)viewDidLoad
{
    [super viewDidLoad];
    // Do any additional setup after loading the view.
    self.config = [[ManagedObjectConfiguration alloc] initWithResource:@"HeroDetailConfiguration"];
}
 
@end

Now you need to tell your storyboard to use this HeroDetailController. Open SuperDB.storyboard, and select the ManagedObjectController scene. Set the zoom level so that you see the View Controller icon in the scene’s label. Select the View Controller icon and open the identity inspector. Change the class from ManagedObjectController to HeroDetailController.

And that should do it. You’re ready to create a power view.

Navigating to the PowerViewController

Your PowerViewController is defined and configured. You’ve defined the segue to transition from the HeroDetailController to PowerViewController. Now you need to execute the PowerViewSegue when the user adds a new power or selects a power in Edit mode. Open HeroDetailController.m, and add the following table view data source method:

#pragma mark - Table view data source
 
- (void)tableView:(UITableView *)tableView         commitEditingStyle:(UITableViewCellEditingStyle)editingStyle         forRowAtIndexPath:(NSIndexPath *)indexPath
{
    if (editingStyle == UITableViewCellEditingStyleDelete)
        [self removeRelationshipObjectInIndexPath:indexPath];
    else if (editingStyle == UITableViewCellEditingStyleInsert) {
        NSManagedObject *newObject = [self addRelationshipObjectForSection:[indexPath section]];
        [self performSegueWithIdentifier:@"PowerViewSegue" sender:newObject];
    }
 
    [super tableView:tableView commitEditingStyle:editingStyle forRowAtIndexPath:indexPath];
}

Since you added this method, you added the logic to remove a power as well. Remember when you changed this method in ManagedObjectController? You only added and removed the table view cells. We said you were going to handle adding and removing powers to the Hero entity later. Well, here it is. Pretty simple, right? Finally, you call the super method (which is in the ManagedObjectController).

One last thing you need to do is handle when you want to view an existing power. Below the HeroDetailController tableView:commitEditingStyle:forRowAtIndexPath:, add this table view delegate method:

#pragma mark - Table view delegate
 
- (void)tableView:(UITableView *)tableView         accessoryButtonTappedForRowWithIndexPath:(NSIndexPath *)indexPath
{
    NSString *key = [self.config attributeKeyForIndexPath:indexPath];
    NSMutableSet *relationshipSet = [self.managedObject mutableSetValueForKey:key];
    NSManagedObject *relationshipObject =         [[relationshipSet allObjects] objectAtIndex:[indexPath row]];
    [self performSegueWithIdentifier:@"PowerViewSegue" sender:relationshipObject];
}

When the user taps the blue disclosure button in the Power cell, it will push the PowerViewController onto the NavigationController stack. In order to pass the power managed object to the PowerViewController, you need to implement the prepareForSegue:sender: method in HeroDetailController.m.

- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender
{
    if ([segue.identifier isEqualToString:@"PowerViewSegue"])
{
        if ([sender isKindOfClass:[NSManagedObject class]]) {
            ManagedObjectController *detailController = segue.destinationViewController;
            detailController.managedObject = sender;
    }
    else {
        UIAlertView *alert = [[UIAlertView alloc] initWithTitle:NSLocalizedString(@"Power Error",
                                                                                  @"Power Error")
                                     message:NSLocalizedString(@"Error trying to show Power detail",
                                                               @"Error trying to show Power detail")
                                    delegate:self
                          cancelButtonTitle:NSLocalizedString(@"Aw, Nuts", @"Aw, Nuts")
                          otherButtonTitles:nil];
        [alert show];
    }
}

That’s it. The Power section and view are all set. Now let’s look into displaying fetched properties.