0

Is that correct, when ViewController creates another ViewController inside its' methods (let's say viewDidLoad or viewWillAppear)?

In my case - I have a view A, that contains several other views - B and C, which are quite complex by themselves, so special view controllers vcB and vcC were designed for them and these view controllers are created inside vcA view controller of view A.

Is this OK? What if, for example, vcA sets itself as a delegate for vcB. Which means, that vcB will retain vcA. In this case, to correctly release all objects, we need somewhere set vcB's delegate to nil, but what is the good moment to do this? viewWillDisappear:, viewDidDisappear: or smth. else?

I'm sure it's not the only case, where problems are rise up, so I'm looking for your opinions how to correctly design these kind of interactions between view controllers.

Justin Boo
  • 10,132
  • 8
  • 50
  • 71
peetonn
  • 2,942
  • 4
  • 32
  • 49

2 Answers2

1

I have witnessed a dogmatic adherence to the idea that only one view controller should be operating at one time. As for myself, I lean toward using more than one view controller at the same time if it simplifies the overall design (reduces complexity) and makes design management easier. As you can read in a recent response that I posted, it appears to me that Apple has moved in the same direction by providing support for custom content view controllers that allow you to operate multiple view controllers at the same time.

The blog by Jonah Williams is worth reading, just to be aware of what you might have to deal with. But Frankly, I haven't had any problem contradicting his advice. (That post is about a year old.)

A key roll of the view controller is to hold the delegate methods of the view it is managing. The view really doesn't care what object is acting as its delegate. So if you wanted a design that is more harmonious with the single-VC point-of-view, you can put the delegate methods into a subclassed NSObject and not call it a view controller. You will most likely have to create some of the methods that a UIViewController already has in it though. But then you don't have to call it a view controller. Me, I just subclass a UIViewCcontroller.

Community
  • 1
  • 1
Jim
  • 5,940
  • 9
  • 44
  • 91
0

Generally, you don't want separate view controllers for subviews of another controller. That's not the way view controllers were designed to work.

Apple's navigation and tab bar controllers do this but they're hideously complicated and non-standard (which is presumably why you're not allowed to subclass them.)

smparkes
  • 13,807
  • 4
  • 36
  • 61