Few Quick Questions About iOS Programming in Xcode

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)i开发者_如何转开发nterfaceOrientation
{
    // 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];
}

---

1. @class is usually enough in your header file. See this question.
2. 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.)
3. It's fine to leave them out, but I think this only works after iOS 4. See this question.

---

1. 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!

2. Yes. As jtbandes points out, the call goes through to super which has a default implementation.

3. 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.