Question about handing classes in Objective-C

Question

Greetings -- I'm pretty new to Objective-C. I do have a few apps out in the app store, but they were simple one-form apps where I was able to dump everything into the main class and be happy with it.
This new project I'm working on, is huge in comparison. Over 25 views, accessible through TableView driven menus.
I was able to get all of the menus working, each launching a separate view NIB file (so far, just a label to show me that it's done, but I got that part working.)
Now what I'm trying to do, is add a "click" sound when a row is selected. But I'm wanting to do this in a separate class, so each .m file can instantiate it's own version of the logic instead of having the same code 29 times.
So, this is what I've done:
Click.h
#import <Foundation/Foundation.h>
#import <AudioToolbox/AudioToolbox.h>
@interface Click : NSObject
SystemSoundID soundID;
-(void) playClick;
@end
Click.m
#import "Click.h"
@implementation Click
-(id) init
self = [super init];
NSString *path = [[NSBundle mainBundle] pathForResource:@"click" ofType:@"wav"];
AudioServicesCreateSystemSoundID((CFURLRef)[NSURL fileURLWithPath:path], &soundID);
return self;
-(void) playClick
AudioServicesPlaySystemSound (soundID);
@end
RootViewController.h
#import <UIKit/UIKit.h>
#import "Click.h"
@interface RootViewController : UITableViewController <UITableViewDelegate, UITableViewDataSource>
NSArray *controllers;
Click *clicker;
@property (nonatomic, retain) NSArray *controllers;
@property (nonatomic, retain) Click *clicker;
@end
RootViewController.m
#import "RootViewController.h"
@implementation RootViewController
@synthesize controllers, clicker;
- (void)viewDidLoad
Click *newClicker = [[Click alloc] init];
clicker = newClicker;
[newClicker release];
self.title = @"Main Menu";
- (void)dealloc {
[controllers release];
[clicker release];
[super dealloc];
#pragma mark Table View Delegate Methods
-(void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath
[clicker playClick];
I cut out the code pieces regarding the TableView that I know works, and tried showing only the parts that I've added to make the sound.
What I've tried, is when the RootViewController is created, it has a SystemSoundID type variable defined with it named clicker. Then as part of "viewDidLoad", instantiate an instance of the class and have it automatically populate the variable "soundID". Then during "didSelectRowAtIndexPath", I want the "playClick" method of "clicker" to be run, but at this point the app seems to get caught in some sort of perma-loop, and I have to "STOP"/"Home" out of it.
I'm hoping the problem is my rookie-status at using Objective-C objects, and the solution jumps out at you veterans, and then whatever problem I am having won't be duplicated when I create additional classes that I'd want to merge into my ViewController logic.
Hope I've made everything clear. If anyone has questions, I'll be checking for replies
Thanks.

Answer 1

Dragon's Nest wrote:
Is it preferred to init a copy and assign it like you did above?
Yes, it's an accepted pattern which you'll see in most of the sample apps. Asnor's code works just as well in this case, and it might always work for you if you stick to that same pattern. However if you were working on a team and everyone else used the more common pattern it might cause a problem. For example, this code would cause a memory leak:
@property (nonatomic, retain) Click *clicker; // interface
self.clicker = [[Click alloc] init]; // implementation
The above is the flip side of your original code. In this case, because we're not releasing the newly alloced object, its retain count is +2 after the setter retains it.
There are other advantages to the accepted pattern. Suppose you weren't assigning the new object to an ivar but only using the object in that one block of code. Should you then release it? Yes. Will you remember? Well, if you're using the pattern, you'll always release it. If you always release the local pointer regardless of whether it gets retained elsewhere, you're much less likely to have a memory leak. How bout the case where you return the pointer (i.e. alloc an object and return it's address from that method)? In that case you just autorelease it. So whoever called the method needs to retain the returned object if it needs to be used after the current event cycle.
Either way, immediate release or autorelease, you're always releasing an alloced object in the same block of code.
Memory management can easily get out of control without following consistent patterns. Alloc->retainBySetter->release is the accepted pattern for Cocoa. Your original code meant to use the correct pattern, but you just forgot that clicker=object isn't the same as self.clicker=object because the latter retains the object. Once you've consistently used the correct pattern for awhile, you'll almost never make that mistake.
Also, is there any difference in calling it in the following two ways:
@property (nonatomic, retain) Click *clicker; // <-- must be considered to answer this question
@synthesize clicker;
[clicker playClick];
[self.clicker playClick];
In the above case there's no difference since the getter synthesized for that property declaration will simply return the value of the ivar (i.e. the address of the retained Clicker object). But in the general case, there certainly could be a difference. If the property was atomic, for example, the results could be different. Of course there will definitely be a difference if you wrote a custom getter that did something more than the default.
Is there a rule or convention re when to use the getter and when to use the ivar directly? Not that I know of. I think you just need to be aware of what the getter does when deciding whether to use the dot notation. This is a point you might want to research a little more, though. Maybe someone here with more experience in Obj-C or Cocoa will comment.
In fact a few of the experts in this forum advise against ever using dot notation. They feel it was invented to crash newbie programs. If you never use dot notation the difference between these two lines is much easier to see:
clicker = newClicker;
[self setClicker:newClicker];
But once again, if you stick to the same pattern all the time, it's much harder to make a mistake.
- Ray