From the View Controller Programming Guide: "It is recommended that you use only the suggested techniques for displaying the views of your view controllers. In order to present and manage views properly, the system makes a note of each view (and its associated view controller) that you display directly or indirectly. It uses this information later to report view controller-related events to your application. For example, when the device orientation changes, a window uses this information to identify the frontmost view controller and notify it of the change. If you incorporate a view controller’s view into your hierarchy by other means (by adding it as a subview to some other view perhaps), the system assumes you want to manage the view yourself and does not send messages to the associated view controller object."
This is what you're doing - adding a VC's view as a subview of another VC, and that last sentence means that your VC won't be getting all of the goodness that VCs usually get. While the technique you listed below might have worked, you are still going to run into problems later when you try to handle rotation, or showing/hiding the status bar, etc. I've been in the same position as you, trying to write a subclass of UIViewController that acted as a container for other UIViewControllers, and had all of the problems you've listed so far, plus a bunch that you have yet to encounter. On Jan 25, 2011, at 8:05 AM, WT wrote: > On Jan 25, 2011, at 8:04 AM, Matt Neuburg wrote: > >> No, it's not. What you're doing is very thoroughly illegal, which is why >> you're getting strange results. > > I beg to differ and would like you (or someone else) to point me to the part > of the documentation that says that a view controller cannot be made to mimic > a navigation or tab bar controller. If Apple thought that tab bars and > navigation bars could/should only be used within their respective controllers > then they would not have made them available as stand-alone objects. > >> You can't use view controllers this way. > > Yes, you can, at least according to the docs. > >> A view controller is for the view that backs the whole view structure, the >> root view of the window. > > The part after the comma isn't true. According to the docs (The View > Controller Programming Guide for iOS): > > "View Controllers Manage a View Hierarchy > Each view controller is responsible for managing a discrete part of your > application's user interface. View controllers are directly associated with a > single view object but that object is often just the root view of a much > larger view hierarchy that is also managed by the view controller." > > So, the root of that view tree for a given view controller need not be the > window. > >> In addition, certain special built-in view controllers and other controllers >> can accept a view controller which they then own and "contain" and use to >> produce their view. But your root view is not controlled by that sort of >> view controller - it isn't a UITabViewController. So it cannot obtain its >> views by way of "contained" view controllers. > > And it (the root view controller) doesn't. It's merely a UIViewController, > like any other you'd put in MainWindow.xib. Just as when you use the > View-Based Application template, it loads its view from a separate nib file. > What that view contains is not something its view controller knows or cares > about (at the level of IB). Nothing demands that the root view controller > sitting in MainWindow.xib be a UITabBarController or a > UINavigationController, and nothing in the API constrains what its view > should or should not contain. > >> a view loaded by a view controller thinks it will be the root view, in the >> window, so it allows 20 pixels for the status bar (the top 20 pixels of the >> window are behind the status bar). > > Where is that said in the docs? In fact, what I quoted just above from the > docs contradicts your statement. A view loaded by a view controller knows > nothing about what part of the window it's about and doesn't make any > assumptions about whether there is or there isn't a status bar, for instance. > It's the view controller's responsibility to manage all that by positioning > and resizing the view as necessary. The view only thinks it's sitting pretty > at its frame's (x,y) coordinates and even those are generally not of > importance to the view, since everything in the view happens in its bounds > rectangle, which has (0,0) for its origin. One can use the simulated UI > elements panel to automatically change the view size on IB, but that's the > extent of any direct effect the status bar and other such elements have on a > view. > > --- > > While writing this reply, it occurred to me to try something I thought I had > tried before but which I had not, namely, to turn off "resize view from nib" > for the window root view controller (tabBarVC, in MainWindow.xib) and then > make its view (loaded from a separate nib file, containing the fake tab bar > controller) 480 pixels tall by not selecting a status bar in the simulated UI > elements panel and by setting its frame to (0, 0, 320, 480). Nothing else is > changed. > > And guess what... it works, which goes to show that just because a design is > non-standard, it doesn't mean it's illegal in the sense you were referring > to. As I suspected, nothing in the docs prohibits the design I have, nor > anything suggests that it shouldn't be done. Moreover, also as I claimed, the > 20-pixel slide has nothing to do with faking a tab bar controller. > > Thank you for your reply, Matt. Although incorrect, your argument prompted me > to try something (which I thought I had done before) and the problem is now > solved. > > For future reference, here's a link to the test project containing the fix: > > http://www.restlessbrain.com/NavTest_fixed.zip > > WT > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/cocoa-dev/dave%40rudedog.org > > This email sent to d...@rudedog.org -- Dave Carrigan d...@rudedog.org Seattle, WA, USA _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
