Chapter 1 - Implementing Methods


Hi There,

With regards to the section of code for - (id) init we create two NSMutableArray’s using:
questions = [[NSMutableArray alloc] init];
answers = [[NSMutableArray alloc] init];

should we not create these array’s using:
NSMutableArray *questions = [[NSMutableArray alloc] init];
NSMutableArray *answers = [[NSMutableArray alloc] init];

as it is done this way in Chapter 2, or is it because it is inside the - (id) init method?



I’m new to iOS and Objective-C myself, but I think (and someone can certainly correct me if I am wrong) that either way works. If you go back to your header file, you’ve already created the pointers to those objects:

[code]@interface QuizAppDelegate : NSObject
int currentQuestionIndex;

// The model objects
NSMutableArray *questions;
NSMutableArray *answers;

// The view objects
IBOutlet UILabel *questionField;
IBOutlet UILabel *answerField;


You create the instance variables (in this case questions, answers, questionField, and answerField) in your header file, and then you can make reference to it in the implementation file. You can’t declare it in the header and then try to recreate it in the implementation. i.e. the following would not work:

NSMutableArray *questions; NSMutableArray *answers;

NSMutableArray *questions = [[NSMutableArray alloc] init]; NSMutableArray *answers = [[NSMutableArray alloc] init]

This is because you’ve already created pointers named questions and answers in your header file, thus you can’t create the same pointer with the same name again in the implementation file.

So, as for why it’s in the header file at all and not just in the implementation file…I believe that has something to do with Objective-C and how it creates public/private/protected variables. Creating a variable in just the .m file and not the .h file gives it a different level of access I think. Hope this helps!


QuizAppDelegate declares instance variables: questions and answers. These belong to the QuizAppDelegate object.

In the scope of the init method, you are assigning values to these instance variables. As an instance variable, the QuizAppDelegate can use these variables in ALL of its methods.

On the other hand, creating a variable in a method makes it a local variable. A local variable only exists as long as the method it was declared in is running. Thus, at the end of the method, you won’t be able to access a local variable; the QuizAppDelegate couldn’t use these variables in another method.


Thanks for the explanation Joe, that makes sense now.




I read the previous e-mails, and I can be wrong, but I think the header file just ‘describes’ that questions and answers is of type 'pointer to NSMutableArray. It doesn’t ‘instantiate’ or ‘create’ them in the header files - if I’m correct of course…

The header file ‘describes’ for other programmers, and for the compiler of what type variables are, how methods need to be called and what values they return, … it’s like a ‘prototype’, but not an actual instantiation.

Only at the moment where you ‘alloc’ some memory, and ‘init’ the memory, you respectively ‘create’ and ‘initialize’ the pointer, and let it ‘point’ to something (a piece of memory of type NSMutableArray in this case)

or am I wrong?


That’s pretty much it, but it goes a little further.

Declaring “NSMutableArray * questions” in the header not only does everything you said, including setting the scope (as Joe noted), but it also sets aside a little memory. questions is a pointer, but that doesn’t mean it lives in the ether — it has real memory as well, enough to hold an address. (After all, that’s what a pointer is.)

So the pointer itself has already been created before alloc/init are hit. Those create and initialize the block of memory to which questions will point (as you noted), but questions itself already exists.