What code is correct and why ?
- (void)viewDidLoad
{
/*my code
*/
[super viewDidLoad];
}
or
- (void)viewDidLoad
{
[super viewDidLoad];
/*my code
*/
}
It doesn't really matter that much. It's more about the way you'd like it. Would you want the super to respond first or the self? If it doesn't really matter that hard, do what you like.
It depends on whether you want your subclasses code to execute before or after the superclasses code for that method. I would say it's more common to do your own custom code after the call to super so that your subclasses code follows the superclasses code. Again, it depends on exactly what your trying to do.
I'd say the latter. You want your superclass's code to run first before you run your own.
Or, if you're completely replacing the function, you'd just comment out the call to the superclass's implementation.
Related
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];
}
#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.
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.
Can anybody tell me why we need the super in every method for e.g.:
-(void)viewDidLoad
{
[super viewDidLoad];
}
I am confused about the super keyword....
[super ...] calls the implementation of the method in your class's superclass. It is important to use if the inheriting class wants to extend the method implementation (i.e., add something to it but also do what the superclass did) as opposed to replacing the method implementation.
As such, you do not call super in every method you override but only where it is appropriate. If you should, must or must not call super in a specific method should be mentioned in the documentation of that method.
To call the method of the parent class.
This is the rule when you override the method of the superclass, so that you can make sure that code in the superclass get executed and behave correctly.
Note: Sometimes, you call super in the beginning of the method, some other times, in the end of the method
What is the recommended way of doing this. Should I call super dealloc first or last or doesn't it matter?
- (void)dealloc
{
[super dealloc];
[orderNumber release];
[orderDate release];
}
Also when it comes to overriding methods like didViewLoad - should I call super first or last?
Always call [super dealloc] last or you might easily come into trouble because you're working on a stale object.
With didViewLoad you normally call it before your own code as you want the standard initialization stuff executed before. I've seen examples in Apple's code that don't call the super implementation at all, though, so maybe there's not much going on anyway.
In this case call the super after you have released all your properties/iVars. For viewDidLoad/willAppear/etc. I usually call the super first. The order matters when your custom class is relying on an object that is created by the super. For the default viewDidLoad this is not the case so it is preference(I believe).
There is no general rule - you chose to override the method, what does it do? Do you want it to happen before or after your custom implementation?
didViewLoad doesn't appear to be a real method.
We know that [super dealloc] destroys the current object completely, so any code that comes after it is wrong. So, in this case, call [super dealloc] last.
The pointers orderNumber and orderDate are held inside your object.
[super dealloc] deallocates your object (aka self).
Once you deallocate your object you must not rely on the things inside it (e.g. orderNumber) having the values they did before you deallocated it.
Therefore, deallocate the members before deallocating the self object.
The opposite holds true for init functions - you can't initialise the pointers until after your object is constructed, so [super init] comes before you initialise the members.
Regarding viewDidLoad (et al), you do whatever works. If you have stuff you want to happen before the superclass does its thing, then you do it before you call the superclass method, and likewise for stuff you want to happen afterwards.
If you don't know whether your code should run before or after, then it probably doesn't matter.
-(void)viewWillAppear:(BOOL)animated{
//something here
[super viewWillAppear];
}
Is [super viewWillAppear]; always required? If not when and why do you use it?
First of all, the correct boiler plate should be:
-(void)viewWillAppear:(BOOL)animated{
[super viewWillAppear:animated];
//something here
}
In other words, call super first, then do your own thing. And you have to pass the animated parameter to super.
You usually want to call the super class' implementation first in any method. In many languages it's required. In Objective-C it's not, but you can easily run into trouble if you don't put it at the top of your method. (That said, I sometimes break this pattern.)
Is calling super's implementation required? In the case of this particular method you could get unexpected behavior if you don't call it (especially if you have subclassed a UINavigationController for example). So the answer is no not in a technical sense, but you should probably always do it.
However, in many other methods there may be good reasons for not calling super.
Calling super method provide possibility to execute code in parent class.
Regarding your question according to Apple doc
So, yes, this method required.
In my experience, calling [super viewWillAppear] in the first line, when calling reloadData after that, makes it impossible to retrieve the previously selected row when coming back from a detail view. When [super viewWillAppear] is the last sentence, you can get the selected row and show the previously selected row hint. This happens only when using [tableView reloadData] inside viewWillAppear.
Lets say you have 2 class, a Parent and a Child. Child inherits from Parent. They have a method called greet which returns a string.
Here is what the parent method looks like:
Code:
-(NSString *)greet {
return #"Hello";
}
We want the child to learn from his parents. So we use super to say greet how Mommy would greet, but with our own little additions too.
Code:
// Inherits from Parent
-(NSString *)greet {
NSString *parentGreeting = [super greet];
return [parentGreeting stringByAppendingString:#", Mommy"]
}
So now Parent greets "Hello", and the Child greets "Hello, Mommy". Later on, if we change the parent's greet to return just "Hi", then both classes will be affected and you will have "Hi" and "Hi, Mommy".
super is used to call a method as defined by a superclass. It is used to access methods that have been overriden by subclasses so that the class can wrap its own code around a method that it's parent class implements. It's very handy if you are doing any sort of inheritance at all.
It is possible to call one method from inside another. I've implemented this function
- (void)pickAndDecodeFromSource:(UIImagePickerControllerSourceType) sourceType
I want to call following method inside the above one.
- (void) viewDidAppear:(BOOL)animated
I think I understand what you're asking... the question is.. well not there. Nonetheless:
What I think you're asking: "How do I call viewDidAppear from within another method...?"
- (void)pickAndDecodeFromSource:(UIImagePickerControllerSourceType)sourceType
{
...
[myController viewDidAppear:YES]; //Simply call it on whatever instance of a controller you have
...
}
If the question was actually "How do I override viewDidAppear?" then this is it:
- (void)viewDidAppear:(BOOL)animated
{
[super viewDidAppear:animated];
//YOUR STUFF
//GOES HERE
}
You can always call the delegate methods directly:
[self viewDidAppear:YES]
Called from inside your method should work.
I'm not sure exactly what you mean, but from the nature of your question I am guessing you are new to Obj-C so I strongly suggest reading Introduction to The Objective-C Programming Language if you have not already. If you have, great! What you are looking for is most likely under Objects Classes and Messaging - Object Messaging - Message Syntax