1

The [UIViewController viewDidLoad] method is called by the system after loading the associated view (obviously?). A common belief -- which I share -- is that viewDidLoad should not be called directly †. However, I can't find this guidance in the documentation, nor anything else from Apple. Does it exist?

For comparison, the loadView documentation says

You should never call this method directly.

† Excepting [super viewDidLoad] in an overridden method.

Clay Bridges
  • 11,602
  • 10
  • 68
  • 118
  • 2
    I think it's just understood that various "lifecycle" methods called by the framework should never be called directly. This includes all of the `view[Did|Will][A|Disa]appear` methods, etc. They are called to let you know something specific has happened. Any such method in any class should never be called explicitly by your own code. – rmaddy Jan 07 '18 at 19:30
  • Obviously I agree, but I would also expect this important detail to be explicitly spelled out by Apple _somewhere_. – Clay Bridges Jan 07 '18 at 19:43
  • I would suggest that that they might feel compelled to explicitly warn you to not call `loadView` yourself because unlike the `did`/`will` methods, you cannot reasonably infer this from the method name, alone. With the various `did`/`will` methods, the intent is clear, but it's not inherently obvious in method names like `loadView` (nor in `draw(_:)`, which shares a similar warning). The `loadView` just doesn't follow standard naming conventions for callback methods, so the documentation tries to remove the ambiguity. – Rob Jan 07 '18 at 20:42
  • 1
    Small addendum to the footnote, the documentation of [UIViewController viewDidLoad] does not say that [super viewDidLoad] needs to be called when you override it. Curiously enough, the template that Xcode provides still does it. – Bart van Kuik Jan 08 '18 at 07:05

2 Answers2

2

I don't think there's any rule that forbids it. I don't mean "there's a rule we all know, it's just not written down." I mean "I don't think there's any rule that forbids it." You are, as best I am aware, free to call viewDidLoad whenever appropriate (including its super).

That doesn't mean you should call it. But then you almost certainly should never call OSCompareAndSwap either. In both cases, if you had a good reason and knew what you were doing, it could be appropriate to call. But it's unlikely to come up.

While I can't think of a time I've had to call viewDidLoad directly, I have had to manually call viewWillAppear and viewDidDisappear to manage view lifecycle in a custom container view controller. There's nothing that forbids calling view lifecycle methods if that's what you mean.

That said, it would be bad practice to call a view lifecycle method if you didn't mean "the view has transitioned into this state." And since it's pretty hard to get into a situation where you have loaded the view, but viewDidLoad won't be called, it's hard to imagine many cases where it would be useful. And you shouldn't call a method uselessly. So that's the only rule at play here as far as I'm aware.

Rob Napier
  • 286,113
  • 34
  • 456
  • 610
  • 1
    :o manually calling `viewWillAppear`.. why in the world did you ever need to do that.. I've written tons of containers and never once did I need to call that. – Brandon Jan 07 '18 at 22:15
  • I can't remember the full reason. It was around the iOS 4-5 days, and something didn't call the lifecycle methods. I can't remember if it was tab view controllers or if we had built our own version of tab view controllers that needed it. But, agreed, I haven't had to do it in years. – Rob Napier Jan 07 '18 at 22:33
1

It is not mentioned explicitly but if you would call it, you would somehow violate the "contract" of the method specified in its documentation:

Called after the controller's view is loaded into memory.

cornr
  • 653
  • 4
  • 20