Those are valid arguments, Dave, and I'm grateful that you pointed me to them, but not necessarily applicable in all cases. In my specific case, the app only supports one orientation (so rotation isn't an issue) and the status bar is always visible. I will not categorically claim that this design is the best for the application in question and I may very well be forced to change it later but there is a specific reason why I'm doing things this way and this is the easiest way to satisfy that need.
I want to emphasize once again that the specific problem I was having is not due to the design but simply due to the wrong settings for view resizing and view sizes. In fact, the solution doesn't just work but I also understand now exactly why it works. Granted, the fact that it works doesn't necessarily justify the choice of design but it's also the case that the choice of design doesn't necessarily cause the problems I mentioned. In fact, it doesn't. It may cause other problems that I can't foresee now but I'll cross that bridge when I get to it. On Jan 25, 2011, at 2:48 PM, Dave Carrigan wrote: > 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
