in an iPad application, I am displaying a modal view controller (through presentModalViewController) in a FormSheet style (so it's about 540 pixels wide and high), the root view controller displays fine (its frame's size is set to roughly (540, 540) and my code takes care of laying out the content properly).
However, when a push a view controller, its frame's size always has (768, 1024) which is wrong. I tried to set its frame explicitly like this:
DetailViewController* detailController = [[DetailViewController alloc] init];
detailController.view.frame = self.view.frame;
[self.navigationController pushViewController:detailController animated:YES];
Any ideas why it doesn't set the size properly?
well, layoutSubviews should be used if the actual frame of the view at runtime is needed. I ended up using that to lay the subviews inside the controller's view. (although I had to create a custom UIView subclass for controller's view)
Your approach looks right. Forgive my question, but have you debugged this with breakpoints and GDB?
You might try this from the console (cmd shift r):
print [[self view] frame]
and
print [[detailController view] frame]
print this before and after you call pushViewController:animated on the UINavigationController to see if its frame size changes from the pushViewController:animated method.
Another note, its hard to see a use case for pushing a view controller to a UINavigationController that would NOT consume the entire UINavigationController's views area. Every push onto the navigation controller represents a level deeper into some navigation (unlike UIView - addSubView).
http://developer.apple.com/library/ios/#documentation/uikit/reference/UINavigationController_Class/Reference/Reference.html
Update: This is why you are having problems:
The view is automatically resized to fit between the navigation bar and toolbar (if present) before it is displayed.
You will find that on apple's documentation on the link I provided. See pushViewController:animated:
View controllers are expected to manage an entire "screenful" of content. Only one view controller (not counting container controllers like UINavigationController) is active at any given moment. The only exception is UISplitViewController, which allows two view controllers to have content on the screen at once.
Related
Given the below code
self.view.backgroundColor = [UIColor yellowColor];
MyViewController *myVC = [[MyViewController alloc] initWithNibName:#"MyView" bundle:nil]
myVC.view.backgroundColor = [UIColor clearColor];
myVC.modalPresentationStyle = UIModalPresentationFullScreen;
[self presentViewController:myVC animated:NO completion:nil];
What happens under the hood when we call presentViewController ? When myVC is visible I cannot see yellow color, then I checked myVC.view.superView in it's viewDidAppear method and it is UIWindow.
Q1. Is that mean until the modal window is up presentingViewController.view (self.view in above case) is removed from the View hierarchy and presentedViewController.view (myVC.view in above case) is added over UIWindow ?
Q2. What will be the case if myVC.modalPresentationStyle != UIModalPresentationFullScreen ?
Q3. Does iOS also remove all the views from UIWindow except presentedViewController.view until the full screen modal dialog is up for optimization ? If NO why not ?
First, let's discuss the case without animation.
Before calling present:
Your window has one view hierarchy, starting from its rootViewController view.
After calling present:
The view hierarchy still exists without change.
A special full-screen view called "dimming view" is added to the window (that is, not inside the rootViewController's view but inside the window (window is a UIView, too). This view is transparent, dims the presenting controler and blocks user interaction.
The presented (modal) controller's view is then added also to the window.
There are some other views added in between the window and the presented controller's window. If you log your view hierarchy, you'll see classes named _ControllerWrapperView or something similar. However, this has changed between iOS versions and you shouldn't rely on the view structure.
Note that that the modal controller can't ever be transparent because it is not direct subview of the window and the wrappers between the controller and the window are not transparent.
The animated case is almost the same. Only there are some fancy animations between the steps.
Edit 2:
The answer was really a bit incorrect. There is a big difference between iPhone and iPad presented controllers.
On iPhone, the presented controllers are always displayed full screen and the presenting controllers are actually removed from the window.
On iPad, if the presented controller is not fullscreen (see UIModalPresentationStyle), the presenting controller stays in the window.
Your questions:
Is that mean until the modal window is up presentingViewController.view (self.view in above case) is removed from the View hierarchy and presentedViewController.view (myVC.view in above case) is added over UIWindow ?
If the controller is full screen, then this claim is true. Otherwise, the presenting view controller stays there but the whole contents are overlapped by other views (even if they are semi-transparent). Also, there are always some views between the presented and the presenting controller views.
What will be the case if myVC.modalPresentationStyle != UIModalPresentationFullScreen ?
See the answer to the previous question - on iPhone, there would be no difference.
Does iOS also remove all the views from UIWindow except presentedViewController.view until the full screen modal dialog is up for optimization ? If NO why not ?
From my tests, only the presenting controller is removed from the window hierarchy. This is probably to optimize drawing performance. This is the only controller the system can safely remove. Removing any other view could cause problems (e.g. views that should be always visible).
Edit:
If you want to make a transparent controller, you can:
Add the view directly to your view hierarchy (either to the controller's view or to the window) with a transition animation (+[UIView transition...])
The same but also adding a child controller to your controller.
I've been trying to add a UIView (with a UIImageView) as an initial screen when the user launches my application for the first time. However, even after I hide the tab bar, or move its frame out of the screen, the UIView still crops itself as if the tab bar was still there.
Both of these code blocks produced the same result:
[appDelegate.tabBarController.tabBar setFrame:CGRectMake(0,1000,0,0)];
[self setView:InitialView];
and
[appDelegate.tabBarController.tabBar setHidden:YES];
[self setView:InitialView];
Here's a screenshot of the incident in action:
Does anyone know how to fix this problem? I've been puzzling away at this for the past few hours, and I can't seem to do anything about it.
Presumably you have your view's view controller inside this tab bar controller. As a result, the view controller's view is getting sized appropriately to fit inside the tab bar controller's view. Why don't you just get the frame of the tab bar and adjust the height of your view by the view's current height + the tab bar's height?
As a side note, I am assuming InitialView is a UIView (or subclass) instance. It is standard Object-Oriented Programming convention to name instances of classes with a lower case letter, and then to proceed in camel case, as in initialView. Just an FYI.
Try this reference your App Delegate which should take in account the UITabBarController. Just the UIImageView as a subview, and when you are done just remove it. You'll obviously have to import your AppDelegate.
AppDelegate *appDelegate = (AppDelegate*)[[UIApplication sharedApplication]delegate];
[imageView addSubview:appDelegate.window];
I have a tabbar -> navigationcontroller structure. In one of these tabs, I want to switch between two UIViewControllers (a KalViewController and a UITableViewController to be be exact), using a UISegmentedControl located in the Navigation Bar.
Currently, I have a third UIViewController, that pops and pushes the appropriate ViewControllers on segment value change. I don't think thats the right way to do it and it also destroys the navigation stack (when I tap on the bar item, the navigation controller goes the root controller, which won't work). And there's even another bug, related to the Kal Component.
So, what's the right way to do it?
The right way to do it is to have the controller handling the UISegmentedControl add the views of the controllers as subviews.
[self.view addSubview:controller.view];
It's your responsibility to send viewWillAppear: and so on.
EDIT: The offset you're talking about can be adjusted using:
controller.view.frame = CGRectMake(x, y, width, height);
EDIT 2: In response to tc.'s comment:
From the documentation of UISplitViewController:
Message Forwarding to Its Child View Controllers
A split view controller interposes itself between the application’s window and its child view controllers. As a result, all messages to the visible view controllers must flow through the split view controller. This works generally as you might expect and the flow of messages should be relatively intuitive. For example, view appearance and disappearance messages are sent only when the corresponding child view controller actually appears on screen. Thus, when a split view controller is first displayed in a portrait orientation, it calls the viewWillAppear: and viewDidAppear: methods of only the view controller that is shown initially. The view controller that is presented using a popover does not receive those messages until the popover is shown or until the split view controller rotates to a landscape orientation.
This is not magical and there is no reason why you wouldn't be able to write a similar controller yourself. In fact I've done it and it worked just fine.
I am sure this is an easy question, but one that has escaped me for some time now.
Say I have a UIViewController, either defined as a root in an XIB or on a stack. At some point in my code I want to replace it with another view controller. Just flat out replace it. How would I do that?
I have tried defining the controller and assigning, but not sure what actually makes it push on the screen with the absence of a navigation controller.
I think when you say that you want to replace the view controller, what you actually mean is that you want to replace the view. Bear in mind that view controllers aren't visible, but every view controller maps to a view, which can become visible by getting added as a subview of a visible view.
Your solution of replacing self.view with the new view controller's view may work in your particular case, but it's probably not the "correct" answer to your question. There are going to be cases where this solution won't work for you.
Let's say you have a simple view based application with no navigation controller and no tab bar controller. In your app delegate you construct an instance of YourFirstViewController, and you call [window addSubview:yourFirstController];. Your view hierarchy now consists of a UIWindow with a single subview -- the view for YourFirstViewController.
Now let's say the user presses a button on that view, which is handled by an IBAction defined in YourFirstViewController. You want to respond by "replacing" YourFirstViewController's view with a view associated with YourSecondViewController. I put "replacing" in quotes because we more commonly present a view by pushing its view controller onto a navigation stack, or calling presentModalViewController:animated: to present the view modally, but let's assume that you've rejected those options for some reason, and you actually do want to manually replace YourFirstViewController's view with YourSecondViewController's view.
This is a simple matter of manipulating the view hierarchy. You want to remove YourFirstViewController's view from its superview (the UIWindow in this case), and you want to add YourSecondViewController's view as a subview to replace it. Your action would therefore look something like this:
- (IBAction)replaceButtonClicked {
UIView *mySuperview = self.view.superview;
YourSecondViewController *secondController = [[YourSecondViewController alloc] init];
[mySuperview addSubview:secondController.view];
[self.view removeFromSuperview];
[secondController release];
}
When we use a methods like -pushViewController:animated: or -presentModalViewController, the receiving controller manipulates the view hierarchy for us. This may make it seem like we're looking at view controllers on the screen, but we're not. We're just looking at a big hierarchy of nested views going all the way up to a UIWindow at the top.
You can present a new view controller modally:
[self presentModalViewController:aViewController animated:YES];
This won't outright replace the current VC, but it will display a new view over the current view.
I'm having a problem getting my view to be sized properly when created via -loadView. It seems that my view frame is always (0, 0, 320, 460), even when the view/controller is nested inside a UINavigationController and/or UITabBarController. Is there a way to detect programmatically when my view controller is nested within these items, so that I can set the proper frame? My loadView is just setting up a nested UIScrollView that should match exactly the visible size on the screen (460px is too tall when there is a tab bar and nav bar visible).
The reason I'm not hardcoding these values is that I would like this view controller to be reusable and work in all scenarios.
There are a few properties of in UIViewController that might be of interest here:
navigationController
tabBarController
If these are not nil you should be able to tell if you need to resize your view or not.
Do not layout your views in loadView: or viewDidload: without a nib. Do it in viewWillAppear:, the main view's frame is properly at that time.