Few Quick Questions About iOS Programming in Xcode

Question

1) For the interface .h file, should I import classes (#import "Person.h") or should I use @class (@class Person)? And I should always use import in the .m, right?

2) Can I get rid of the following methods if I don't use autorotate?

- (void)didReceiveMemoryWarning
{
    [super didReceiveMemoryWarning];
}

- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation
{
    // Return YES for supported orientations
    return (interfaceOrientation == UIInterfaceOrientationPortrait);
}

3) Do I need to separate IVariables from properties when declaring them in the interface? I see both ways being done.

Edit:

What about these methods?

- (void)viewWillAppear:(BOOL)animated
{
    [super viewWillAppear:animated];
}

- (void)viewDidAppear:(BOOL)animated
{
    [super viewDidAppear:animated];
}

- (void)viewWillDisappear:(BOOL)animated
{
    [super viewWillDisappear:animated];
}

- (void)viewDidDisappear:(BOOL)animated
{
    [super viewDidDisappear:animated];
}

score 0 · Accepted Answer · edited May 23 '17 at 12:16

0

@class is usually enough in your header file. See this question.
All of those methods are performing their default behaviors, so you can remove them regardless of whether you use autorotation. You would want to keep them if you need to add additional behavior. (Using super means to call the superclass implementation — i.e., the implementation that would be used if you hadn't defined this method. So if you are only calling super and not doing anything else, there's no point.)
It's fine to leave them out, but I think this only works after iOS 4. See this question.

edited May 23 '17 at 12:16

Community

1
1

answered Aug 01 '11 at 07:06

jtbandes

115,675
35
233
266

@jtbandes: (3) I think this works since Objective-C 2.0, not since iOS4.0. (I've used this on iOS3.0 for example). to Jon: You don't need the iVar declarations if there's a property to go with them, but it's good to use iVars with no property and a "@private" declaration if your object needs to store some data but you don't want to expose it. An example I often come across is UITableViewController, which might hold an array to populate it's rows. – Ken Aug 01 '11 at 07:38
@SK9: Good points. However you can also choose not to declare an ivar, and simply use `@synthesize ivar = _ivar;` to explicitly declare an ivar name which you can use in code. Or, even better, you can use a class continuation and re-declare the property as non-`readonly` in your implementation file. – jtbandes Aug 01 '11 at 07:40
@jtbandes: Absolutely! Google does something similar -- http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml – Ken Aug 01 '11 at 07:44

Ken · Answer 2 · 2011-08-01T07:48:20.080

You can use @class for types, but if your class subclasses something you need to import the latter. Likewise for protocols. You will probably need to import the class, e.g. #import "Person.h", at the top of the implementation file. A good rule I can offer: If the compiler chokes here, import!
Yes. As jtbandes points out, the call goes through to super which has a default implementation.
You don't need the iVar declarations if there's a property to go with them, I do without because I don't want to clutter my interface. I think this works since Objective-C 2.0, not since iOS4.0. (I've used this on iOS3.0 for example). Also, omitting iVars helps prevent zombies and maintain the correct retain count - it encourages you to use the right setter. But some times it's good to use iVars with no property and a "@private" declaration if your object needs to store some data but you don't want to expose it. An example I often come across is UITableViewController, which might hold an array to populate it's rows.

Few Quick Questions About iOS Programming in Xcode

2 Answers2