In viewDidLoad do you put [super viewDidLoad] before or after your code? Is it the same for all other methods?
Before. You want the super initialization to happen before yours, so that your code could rely on the super state.
As for the other methods - it depends whether you want your code to touch the parameters before calling the super method or it needs to process the result of it.
Related
The standard NSView initializer initWithFrame:(NSRect)frame; is not getting called in my custom view. I've tried simple init, but so far, nothing is called. Also, the drawRect: method is not called. So how is one to intercept the initialization of the AVPlayerView?
I found the answer to this (using Objective-C) - it is:
(instancetype) initWithCoder:(NSCoder *)coder;
-(void)viewwillAppear
{
[super viewwillAppear:animated];
}
What does mean of calling [super viewwillAppear:animated] and what happen if we not call it?
By using super you are calling the base class version of the method. You will see similar call in init, dealloc, viewDidLoad etc. methods. The reason is in base class's implementation something important may be carried out without which the derived class will not work properly. When you have overridden the method in derived class, you will need to make a call to the base version by using super.
The only situation you will not call base class's method by using super is when you know that you don't need the tasks carried out by base class, in other words you are overriding completely. This is not the situation with viewWillAppear:animated or viewDidLoad etc. So we always call super in these cases.
Apple's documentation for viewWillAppear: just says:
If you override this method, you must call super at some point in your implementation.
It will probably lead to some unexpected behavior if you don't call it. Note that 'at some point' means you don't have to call it first.
The reference clearly states
This method is called before the
receiver’s view is about to be
displayed onscreen and before any
animations are configured for showing
the view. You can override this method
to perform custom tasks associated
with presenting the view. For example,
you might use this method to change
the orientation or style of the status
bar to coordinate with the orientation
or style of the view being presented.
If you override this method, you must
call super at some point in your
implementation.
I'm still very new to Objective C, and I was wondering something regarding viewDidDisappear.
I have an app that plays a sound (using AVAudioPlayer), and I want to stop the sound when the view is switched.
If I do this in my view controller implementation:
- (void)viewDidDisappear:(BOOL)animated {
[self.audioPlayer stop];
}
it works fine. But the small programmer in my brain is saying that I'm not using this correctly.
I'm pretty sure you are supposed to CALL viewDidDisappear with a boolean argument, rather than just specify (BOOL)animated; besides, it would be nice to have some animation in my view switching... then again, that might be a whole different discussion!
So, what am I doing wrong, and how would I correctly use this? Do I have to link the call a button action? Where is the correct play to actually declare the function itself?
Thanks.
I implement viewDidDisappear:(BOOL)animated EXTENSIVELY, along with viewWillAppear, viewWillDisappear and viewWillDisappear The main reason to implement this method is to make your view controller to do something at the event, such as viewDidDisappear You don't call this method, but your app will call your view controller to do what's implemented there. Since this is inherited method, as long as you make sure all the inherited implementation from the super class can be done, it's great to implement viewDidDisappear. So, I suggest you to change your code to be like this:
- (void)viewDidDisappear:(BOOL)animated {
[super viewDidDisappear:(BOOL)animated]; // Call the super class implementation.
// Usually calling super class implementation is done before self class implementation, but it's up to your application.
[self.audioPlayer stop];
}
- (void)viewDidDisappear:(BOOL)animated is a method declaration, not a call of any sort. The method itself is called by UIKit as view controllers are manipulated; you don't need to call it yourself unless you're writing your own code that makes view controllers appear and disappear by directly manipulating the views they control (e.g. if you were rewriting UINavigationController for some reason).
You are doing something wrong, though: you must call [super viewDidDisappear:animated] somewhere in your implementation, or things may break.
The "small programmer" voice in your mind is probably more used to procedural coding, where you call the OS and tell it what to do. Cocoa Touch instead uses an event driven paradigm, where your program has routines (methods) that the OS(framework)calls when it is good and ready. viewDidDisappear is one of those routines. Just sit tight, and wait for the OS to call it (assuming you've set everything up properly.)
viewDidDisappear: is an optional method that your view can utilize to execute custom code when the view does indeed disappear. You aren't required to have this in your view, and your code should (almost?) never need to call it.
When creating a UIViewController derived class in objective-C, what goes into the init method, what should go into loadView and what into viewDidLoad - and more importantly why, and what benefit (performance?) does this have?
Also, how does this relate to UIView derived classes where the only option you have is the init method?
I know the template code already has comments for what goes into each method, but it unclear to me why each thing goes where they say.
Clarification
I would like to know maybe at a lower level, what is the actual difference between things being done in the 'init', 'loadView' and 'viewDidLoad'. What does the framework do in between these calls that may affect the way/time I set up my views and do other work? How are these methods affected by threading?
You want to know some lower-level stuff.
init: This method gets called on ANY NSObject subclass. It is what sets up the object, which you probably already know. In many model (as in the MVC pattern) classes, init is directly used. As for the UIKit classes, very few requires init to be called directly. It should not be used. In the UIViewController, you initialize it using initWithNibNamed:. You can override this method, but in most cases this is not needed. This method is the VERY first method to EVER get called on the class (before any view setup, or such).
loadView:and viewDidLoad: read this article iPhone SDK: what is the difference between loadView and viewDidLoad? .
The only really important thing to know is that -init is the NSObject standard initialization method. -loadView and -viewDidLoad are UIViewController's methods for initialization.
In Apple's scrollView example they don't call that. I always thought that's a must. Why should I call that anyways?
If you are overriding the method you should still call the method in the super. Even if the super class is not doing anything with it today, Apple might one day change the implementation and your code will mysteriously stop working. If you really don't need to do anything in that method, leave it out of your code entirely, and the super's method will run as usual, without any intervention on your part.
No, you don't need to call [super viewDidLoad]. Edit: But read below, because I think you definitely should.
Let's be real here: Apple is not going to break thousands of apps, including those based on their published sample code, by deciding an event they're not currently handling suddenly needs to do something that developers may or may not want to stop and it's critical that if you don't need different behavior you not stop the event.
Edit: Having watched how Apple handles compatibility for an extra year, I now recommend learning and using the correct pattern. While I doubt your application binary will ever suddenly stop working, it's clear that the iPhone detects which SDK your binary was built against and modifies some OS behaviour based on this.
Apple might one day require a particular pattern be followed on some future SDK. This would not affect you until you rebuild with the latest Xcode + SDK, but then you'd get these breaks without any source code changes. Learn and follow the pattern to be safe.
As Markus says, UIViewController doesn't do anything in its viewDidLoad method, so you don't have to call it. However, it's a good habit to get into, in case you change your inheritance structure and suddenly the class that used to inherit from UIViewController now inherits from something that does do something in the viewDidLoad method.
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.
Apple's documentation for viewDidLoad does NOT state that you should call [super viewDidLoad], so I would go with what Apple's says. Note, however, that for other similar methods like viewDidAppear, you must call [super viewDidAppear].
You don't have to call the [super viewDidLoad]
As far as I know, the viewDidLoad in the superclass (UIViewController) is only an empty function that gets called when the ViewController gets initialized with a nib-file.
So if you need to do any initializing, you should override this function and put your code there.
Just noticed that the static analyzer of Xcode 6 issues a warning if you do not call super in these functions. So it seems Apple now definitely wants us to call it.
Although in xCode 7 Beta/Swift 2 super.viewDidLoad won't compile. The error says it's only available in osx 10.10 and the auto-fix does this
if #available(OSX 10.10, *){
super.viewDidLoad()}
else
{
// Fallback on earlier versions
}
// My code
}