views:

112

answers:

3

I've been studying the sample code Apple provides in their iPhoneCoreDataRecipes application and there are a couple of things they they're doing that I don't understand and I haven't been able to find a resource to help me with them.

Specifically, the block of code in question is:

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath {

NSInteger section = indexPath.section;
UIViewController *nextViewController = nil;  //Why this as opposed to alloc and init?

/*
 What to do on selection depends on what section the row is in.
 For Type, Instructions, and Ingredients, create and push a new view controller of the type appropriate for the next screen.
 */
switch (section) {
    case TYPE_SECTION:
        nextViewController = [[TypeSelectionViewController alloc] initWithStyle:UITableViewStyleGrouped];
        ((TypeSelectionViewController *)nextViewController).recipe = recipe;
        break; //Why this as opposed to nextViewController.recipe = recipe???

    case INSTRUCTIONS_SECTION:
        nextViewController = [[InstructionsViewController alloc] initWithNibName:@"InstructionsView" bundle:nil];
        ((InstructionsViewController *)nextViewController).recipe = recipe;
        break;

    case INGREDIENTS_SECTION:
        nextViewController = [[IngredientDetailViewController alloc] initWithStyle:UITableViewStyleGrouped];
        ((IngredientDetailViewController *)nextViewController).recipe = recipe;

        if (indexPath.row < [recipe.ingredients count]) {
            Ingredient *ingredient = [ingredients objectAtIndex:indexPath.row];
            ((IngredientDetailViewController *)nextViewController).ingredient = ingredient;
        }
        break;

    default:
        break;
}

// If we got a new view controller, push it .
if (nextViewController) {
    [self.navigationController pushViewController:nextViewController animated:YES];
    [nextViewController release];
}

}

I'm wondering if the ((name *)name).thing = aThing is different than name.thing = aThing? I'm sure it is, but I can't find any documentation to help me understand what they are doing here and why?

Also, why do they set the nextViewController equal to nil as opposed to just allocating and initializing it? Is there a reason that this was done here, while in other areas when creating a temporary view controller they used alloc and init?

Thanks in advance for your help!

A: 
 ((TypeSelectionViewController *)nextViewController).recipe 

nextViewController is a UIViewController* which doesn't have a recipe property. ((TypeSelectionViewController *)nextViewController) casts nextViewController to a TypeSelectionViewController*.

nextViewController is set to nil outside the switch block so that it is ready to go for each block within the switch. Notice how within each case block, it is the alloc and init are on a different type: TypeSelectionViewController vs InstructionsViewController etc.

rchern
+2  A: 

I'm going to answer your questions in the order they come up in the code rather than the order you asked them, because the order is important here.

The reason we don't create the view controller when we first declare the variable is because we don't know what we want to create yet. Think about it: You want to write alloc] init]. But what goes before the alloc? We don't really know yet. We know it's some subclass of UIViewController, but we don't know the actual class. That's what the next part of the code is for.

So now we get to the main logic of the method. We're assigning the view controller's recipe, but there's a problem here: We declared the variable as UIViewController*, and UIViewController doesn't have a recipe property. We know our subclass does, but we already told the compiler that this variable pointed to a UIViewController. So in order for the compiler to let us do this property assignment, we need to cast the variable to the right class.

Incidentally, we could also just have declared the variable as id nextViewController and then write [nextViewController setRecipe:recipe] and there wouldn't be any need to cast. The downside is that then the compiler wouldn't be able to typecheck our code — we could accidentally assign an NSString to nextViewController in some little-used branch of the code and we'd never know until we happened to hit that branch at runtime.

Chuck
You've described the casting going on here, but the one comment I would add here is the bigger picture: It's all simply done so you don't have to declare 3 separate object variables of different classes, even though you really only need one for the specific switch branch each time the method is called.
Joost Schuur
Thank you very much. This explanation was great!
Zigrivers
+1  A: 

It's due to inferred types and how the compiler handles dot-syntax.

The compiler considers nextViewController to be a UIViewController, since that's how it is declared. You can set it to be anything you want (although it should only really be set to UIViewController instances, UIViewController subclass instances or nil), but the compiler thinks of it as a UIViewController. When you use the Obj-C 2.0 dot-syntax:

myObject.recipe = recipe;

The compiler checks the type of myObject, and sees if it has a setRecipe: method declared. If it does, that statement is translated to the equivalent of:

[myObject setRecipe:recipe];

Then compiled. If there's no declaration of setRecipe:, it will attempt to treat the dot-syntax as a struct element, which will almost certainly throw a compiler warning. The type cast (TypeSelectionViewController *) tells the compiler to treat the variable as something of that type, so when you do:

((TypeSelectionViewController *)nextViewController).recipe = recipe;

The compiler looks to see if there's a setRecipe: method declared on the TypeSelectionViewController class, not on whatever nextViewController was declared as.

Nick Forge
I hate to nitpick, but that's a slight oversimplification. The dot-notation will work as long as there's a readwrite property called `recipe` — even if the corresponding setter is `heyWriteThisAwesomeIdeaDown:`.
Chuck
To nitpick/clarify even further, it will work if there is a readwrite `recipe` property declared OR there is a `setRecipe:` method declared (or both). You can use dot-notation for non-property getters and setters, Xcode just won't auto-complete it for you.
Nick Forge
Thank you for taking the time to respond. All of the responses have helped me understand what was going on.
Zigrivers