Re: [iPhone] can't get views not to slide off by the height of the status bar
Re: [iPhone] can't get views not to slide off by the height of the status bar
- Subject: Re: [iPhone] can't get views not to slide off by the height of the status bar
- From: WT <email@hidden>
- Date: Tue, 25 Jan 2011 15:14:17 -0200
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 (email@hidden)
>>
>> 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:
>>
>> This email sent to email@hidden
>
>
>
> --
> Dave Carrigan
> email@hidden
> Seattle, WA, USA
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden