In UIViewController\'s documentation, Apple suggests calling the super at some point in the implementation of viewWillAppear, viewDidAppear, viewWillDisappear, viewDidDisapp
For UIViewController
's view life cycle methods, I'd say that there is no silver bullet rule for determining when to call super
, what you should be aware of is that sometimes you must call it regardless of whether it should be at the begging or at the end of the method. For instance, citing from viewDidDisappear(_:):
You can override this method to perform additional tasks associated with dismissing or hiding the view. If you override this method, you must call super at some point in your implementation.
However, as a general practice we usually call the super
method at the beginning in methods that related to initialization, setup or configurations; On the other hand, we usually call the super
method at the end in methods related to deinitialization or similar methods.
Here is an example of XCTestCase
class's invocation methods:
override func setUp() {
super.setUp()
// do the setups, such as creating the mock objects...
}
override func tearDown() {
// make your objects no be nil for the next test...
super.tearDown()
}
So (as another example), when it comes to the viewWillAppear
and viewDidDisappear
methods:
override func viewWillAppear(_ animated: Bool) {
super.viewWillAppear(animated)
// my code...
}
override func viewDidDisappear(_ animated: Bool) {
// my code
super.viewDidDisappear(animated)
}
I generally will call these first within my implementation. In most cases it shouldn't matter though.
In viewDidAppear
call super
first so that your calls will override.
In viewWillDisappear
it seems to be a toss up, I have researched that extensively and could not find a conclusive answer and it seems to be 50/50. I have decided to call super
last in my code in the same manner we call super
last in dealloc
.