views:

2747

answers:

2

Hi i've got the following code in a ViewController.h:

#import <UIKit/UIKit.h>

@interface CalcViewController : UIViewController {
    NSNumber* result;
    NSString* input;
    //NSString* input = @"";

    IBOutlet UITextField* display;
}

@property (retain) NSNumber* result;
@property (retain) NSString* input;
@property (nonatomic, retain) UITextField* display;

@end

The problem is that I want to append a string to input but this is not possible when its still null. Thats why I want to set the default value of input to be @"". But where do I put this code.

I'm aware of one possible solution where you put it in a default constructor. But I've got no idea in what file to put this. And where I should call it from.

I unfortunately only got a limited understanding of C and realise that perhaps a .h file is not the right place.

The project type is a View-Based-Application if you should need this.

Hope you can help.

+6  A: 

You may find it useful to read some documentation on Objective-C or Cocoa. You probably can find some good suggestions on reading material if you perform a search here in StackOverflow or on Google.

To answer your question, you should have a @implementation of CalcViewController. One would most often place this @implementation inside of the *.m file. If your *.h file is named "ViewController.h" then the implementation would go in "ViewController.m".

You would then create a copy of the UIViewController's initialization function and place it there (I don't know what the default init function is).

For example:

@implementation CalcViewController

@synthesize result;
@synthesize input;

- (id)initWithNibName:(NSString*)aNibName bundle:(NSBundle*)aBundle
{
    self = [super initWithNibName:aNibName bundle:aBundle]; // The UIViewController's version of init
    if (self) {
        input = [[NSString alloc] initWithString:@""]; // You should create a new string as you'll want to release this in your dealloc
    }
    return self;
}

- (void)dealloc
{
    [input release];
    [super dealloc];
}
@end // end of the @implementation of CalcViewController

NOTES:

  • You may want to rename the file to CalcViewController. I believe it is easier for Xcode's refactoring engine to deal with.
  • You do not need to declare the @property for the display instance variable as you connect that with Interface Builder. Unless you want clients of the CalcViewController to change it often

EDIT: April 28, 2009: 10:20 AM EST: I suggest actually allocating a NSString as you should technically release it in the dealloc.

EDIT: April 28, 2009: 11:11 AM EST: I updated the @implementation to use the UIViewController's version of init.

Lyndsey Ferguson
Answer to note its a CalcViewController file I just met that its a ViewController. And yes the display needs to change often. Thanks
MrHus
Just to be clear, when I wrote about the display instance variable changing often, I mean the actual *instance* of the variable. Not the actual data in the display object. So if you can imagine that you'll be destroying and re-creating the display instance variable, then this would make sense.
Lyndsey Ferguson
Ok I'll figure how change the display without a variable. But -(id)init doesn't get called. Any reason why?
MrHus
The actual call is "– initWithNibName:bundle:" and your code should either be creating the CalcViewController directly as in: CalcViewController* vc = [[CalcViewController alloc] initWithNibName:@"MyCalcView" bundle:nil];Or by hooking it up directly in Interface Builder. So, as I tried to allude in the text, I didn't think "init" was the correct initializer. Again, read documentation to get a basic idea of how Cocoa works. Good luck!
Lyndsey Ferguson
+1  A: 

Another option is to write your own getter for your input property, and return @"" if the instance variable is nil. This would work even if you accidentally or intentionally assigned nil to input, whereas using init to set a default value would break.

Marc Charbonneau
A good solution, but not common practice. Other readers of your code will likely look to the designated initializer for the default value.
Barry Wark
I wouldn't say that, returning an empty object instead of nil is pretty common throughout Cocoa. That's not to say setting it in init is a bad or anything, it's more a matter of preference.
Marc Charbonneau