Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm writing an experimental iPhone app to learn about the MVC paradigm. I instantiate my Model class in the ViewController class. Is this stupid? I'm asking because storing the id of the Model class, and using it works where it's initialized, but referring to it later (in response to an interface action) crashes.

Seemingly, the pointer address of my Model class instance changes, but how can that be?

The code in question:

@interface Soundcheck_Tone_GeneratorViewController : UIViewController {

    IBOutlet UIPickerView * frequencyWheel;
@public
    Sinewave_Generation * sineGenerator;
}

@property(nonatomic,retain) Sinewave_Generation * sineGenerator;

@end

@implementation Soundcheck_Tone_GeneratorViewController

@synthesize sineGenerator;

- (void)viewDidLoad {
    [super viewDidLoad];
    [self setSineGenerator:[[Sinewave_Generation alloc] initWithFrequency:20.0]]; // using reference -> fine
}

// pickerView handling is omitted here...

- (void)pickerView:(UIPickerView *)thePickerView didSelectRow:(NSInteger)row inComponent:(NSInteger)component { 
    [[self sineGenerator] setFrequency:20.0]; // using reference -> crash
}

@end


// the Sinewave_Generation class... only to be thorough. Works fine so far.

@interface Sinewave_Generation : NSObject {

        AudioComponentInstance toneUnit;
    @public
        double frequency,theta;

}

@property double frequency;

- (Sinewave_Generation *) initWithFrequency: (int) f;

@end


@implementation Sinewave_Generation

@synthesize frequency;

- (Sinewave_Generation *) initWithFrequency: (int) f 
{
    self = [super init];

    if ( self ) {
        [self setFrequency: f];
    }

    return self;
}

@end
share|improve this question
    
Followup: The original question persists, however, I managed to solve the specific problem in my code by storing reference to the other class in the AppDelegate, and explicitly finding the AppDelegate and asking about the other class by saying something like [[(DummyAppName_AppDelegate*)[[UIApplication sharedApplication] delegate] sinus] setFrequency:20.0]; where sinus is the name of an instace variable of type Sinewave_Generation*. –  user19410 Mar 6 '11 at 12:41
add comment

2 Answers

No, it should be instantiated somewhere outside the controller.

Not having written iPhone apps, but being experienced with the paradigm (and agreeing with Matthew Read), the main reason is because the view and controller should be completely replaceable just like CSS.

One way to handle the instantiation of model instances in MVC is to use dependency injection and an inversion of control (IOC) framework such as Castle Windsor. In this case, you declare the Model as a dependency of your controller's constructor and at runtime Castle would automatically figure out how to create an instance of your model object (including resolving that object's dependencies).

You could get away without bothering with IOC, but you'll still need to inject the Model as a dependency of the model's constructor.

share|improve this answer
add comment

Always access your model classes via a standalone wrapper (like sharedInstance:). This will help you keep your model layer separate from views and also it will be very easy to access your data where ever you need.

I've seen people using AppDelegate as standalone. It should be okay, if your app is not data oriented. Otherwise, it's always a good practice to have one standalone class above your model layer...

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.