StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>donkim is right but don't take my word for it ;)</p> <p>See this post by Rincewind: <a href="https://devforums.apple.com/thread/81930" rel="noreferrer">https://devforums.apple.com/thread/81930</a> and any number of older comments from other Apple employees on their forums.</p> <blockquote> <p>If I'm understanding what you are saying, you've created another view controller (BlueViewController) and added its view as a subview of another view controller? If so, then this is covered by the docs – specifically to say not to do that because it is not supported.<br> A view controller is meant to manage an entire screen's worth of content. If you want to subdivide your content further, then it is recommended that you use objects other than subclasses of a UIViewController to manage those subregions and manage those objects with a UIViewController subclass.</p> </blockquote> <p>In addition we have the <a href="http://developer.apple.com/library/ios/#documentation/UIKit/Reference/UIViewController_Class/Reference/Reference.html" rel="noreferrer">UIViewController class reference</a> which states:</p> <blockquote> <p>You use each instance of UIViewController to manage a view hierarchy. A typical view hierarchy consists of a root view—a reference to which is available in the view property of this class—and usually one or more subviews presenting the actual content. On iPhone and iPod touch, the root view typically fills the entire screen but on iPad this view may fill only part of the screen. In both cases, the view controller is responsible for managing the entire view hierarchy, including all subviews.</p> </blockquote> <p>and also the <a href="http://developer.apple.com/library/ios/#featuredarticles/ViewControllerPGforiPhoneOS/BasicViewControllers/BasicViewControllers.html#//apple_ref/doc/uid/TP40007457-CH101-SW1" rel="noreferrer">View Controller Programming Guide for iOS</a>:</p> <blockquote> <p>The root view acts as the container for all other views associated with your view controller. You typically define the frame for this view to match the size of the application window, which itself should fill the screen. However, the view controller also adjusts the frame size as needed to accommodate the presence of assorted views, such as the system status bar, a navigation bar, or a tab bar.</p> </blockquote> <p>Unfortunately none of those are as explicit as I would like about <em>why</em> UIViewController makes these assumptions and when it might be safe to break them. From what I can tell without access to UIKit code somewhere UIKit assumes a single view controller will be responsible for a given screen worth of content. In some cases it therefore sends messages like -viewWillAppear: or -didRecieveMemoryWarning to only one (or maybe only some) view controllers if you have multiple view controllers visible in a single window. It should be possible to demonstrate this in at least a couple of different ways though I haven't tested all of these recently so I'm going off of other user's reported problems. Nested view controllers will not receive -didReceiveMemoryWarning Multiple view controller's view will not be rotated if rotation occurs while a modal view controller is presented and the modal is then dismissed. View controllers' views are sometimes expected to fill the window and be opaque so the content drawn in regions of the window they do not cover can be undefined. Trying to present a modal view controller which did not fill the screen would not render underlying views, at least in iOS 3.1.x or whatever the last version I tried was.</p> <hr> <p>To try to directly answer hmthur's question. A UIViewController should have a single root view (its 'view' property) which fills the window and which can handle being resized to fit status bars, tab bars, and so on. That controller may have any number of sub views of that root view and properties which reference those sub views.</p> <hr> <p>As a further update consider this thread on "<a href="https://devforums.apple.com/message/365171#365171" rel="noreferrer">Creating container UIViewController subclasses?</a>" on the Apple developer forums (discussing setting <code>parentViewController</code> in order to build custom container view controllers).</p> <blockquote> <p>All UIKit ivars are considered private and their direct access is unsupported, including access through setValue:forKey:. The method that sets this ivar is also private.</p> <p>As for this ivar [parentViewController], I will warn you that its behavior is likely to change.</p> <p>Unfortunately I don't have any good suggestions for alternatives, though for what it's worth we do recognize the difficulty in creating container view controllers.</p> </blockquote>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload