I know this question has been kind of asked and have looked into the solutions that others have posted but still feel quite confused on the topic so I apologize if this really is a "noob" question.
So I have a tab bar view controller and I have 2 views that should autorotate and one that never should. My understanding is that shouldAutorotateToInterfaceOrientation needs to always return YES; in order for any view controllers to autorotate. So if this is the case, how would I get only one to NOT rotate but keep the orders rotating?
Thank you very much!
P.S. I tried this from a different post found here: How to prevent the view controllers in a tab bar controller from rotating? but with no luck. The answer from that post is posted below
"This is a commonly reported "bug" - however a good workaround is to force the shouldAutorotateToInterfaceOrientation: selector to be triggered as follows:"
- (void)viewDidAppear:(BOOL)animated {
UIWindow *window = [[UIApplication sharedApplication] keyWindow];
UIView *view = [window.subviews objectAtIndex:0];
[view removeFromSuperview];
[window addSubview:view];
}
The behavior you're aiming for conflicts with the rotation rules of UITabBarControllers. You mentioned it yourself:
shouldAutorotateToInterfaceOrientation needs
to always return YES in order for any view controllers to autorotate.
But what you want is for one of the view controllers to return NO, which violates that rule. So to answer your question, you will have to implement your own custom view controller container (or a custom view).
There's a good reason this restriction was placed added to UITabBarControllers. Tabs with different rotation rules will be annoying to user since the screen will keep rotating on them each time they change tabs.
Now if I were you, I'll allow all my tabs to rotate, then present the non-rotating view as a modal view.
Related
I'm making an ipad app which has 11 view controllers in storyboard, one of which is a master view that contains buttons to control which of the other view controllers is displayed as its subview.
Does anybody know for sure if it's ok to use UIViewControllers as subviews of other UIViewControllers, with hard evidence from apple or another source? It has been working flawlessly for me using this method so far:
int nextPage = (method to determine nextPage based on button pressed);
[currentView.view removeFromSuperview];
currentView = [self.storyboard instantiateViewControllerWithIdentifier:[NSString stringWithFormat:#"page%i",nextPage]];
[self.view insertSubview:currentView.view atIndex:0];
[currentView.view setFrame:CGRectMake(0, 0, 1024, 768)];
Some people online say that if you are using ios5 or later, it's ok, but others say "NO NEVER DO THIS!!!" even if it's ios5. Others say to use container views, but in every tutorial I've seen to use a container view you just end up inserting the view controller as a subview to the main view anyway using this after you've inserted the child view:
[self.view addSubview:self.currentView];
I am not using a Navigation Controller because they have limited customizability and I do not want any stock tab bars or navigation bars, just all custom buttons.
Thanks in advance!
Yes of course, it's how UINavigationController works and how UITabBarController works. Interface Builder will event set it up for you with a container view.
see Creating Custom Container View Controllers
The takeaway is it's important to handle childViewControllers. This can get a bit tricky, but is important for notifications to propagate correctly.
Just for the purpose of learning some particular aspects of xCode, I am creating a simple app that has 2 functional view controllers. Each contains a button that can be pressed to switch to the other. I am not using segues. I am using pointers retrieved from the app delegate.
visual illustration (click for higher resolution):
When the app loads, the root view controller presents view 1. When you click "switch to view 2," the following code causes view 2 to appear:
- (IBAction)buttonPressed:(id)sender
{
AppDelegate *appDelegate = (AppDelegate*)[[UIApplication sharedApplication] delegate];
[self presentViewController:appDelegate.view2 animated:YES completion:nil];
}
So far, so good.
But when you click "switch to view 1" on the second view, this same code (replacing "view2" with "view1") gives the following error:
Application tried to present modally an active controller.
So to summarize (where --> = presents), we have root --> view1 --> view2 -x-> view1
I don't care about retaining the history of who presents whom. I simply want the buttons to bring to the top (make visible) a previously displayed view controller, maintaining the state of its views.
It would be nice to know the following:
Is there a workaround that would enable me to achieve the intended behavior using presentViewController? E.g., root --> view2 --> view1
What other method(s) would be more practical for achieving the desired behavior? It/they must use the app delegate because in my real application that will be unavoidable.
Am I breaking the rules by trying to put a view controller on top without integrating into some larger architecture? E.g, is this sort of behavior supposed to be handled by navigation conrollers and pushing/popping? If so, can you explain why xCode doesn't want me to do this? Why can't I just display whatever view controller I want, without it necessarily having any relationship to other view controllers? (Maybe because that could lead to abuse of the app delegate?)
What does it really mean to "present" a view controller? What functional limitations or capabilities does it entail beyond creating pointers between presenting and presenter? What is the importance of leaving the presenting view controller "active"?
If instead make the button on view1 send the presentViewController message to the root view (which I hoped would just change the presentation chain from root --> view1 to root --> view2, leaving view1 still existing in memory but not part of this chain), I get a different error: "Attempt to present on whose view is not in the window hierarchy!" What does this mean? I can't find an explanation of window hierarchy.
Okay, I know I'm asking a lot here, but any amount of enlightenment will be greatly appreciated!!
The correct way to do this is to get the underlying rootVC to do the presenting and dismissing (as you attempt - without the dismissing part - in point 5). You can achieve this by sending a message + completion block back to the rootVC from each of view1 and view2 when you want to present the other.
When you are in view1:
- (IBAction)buttonPressed:(id)sender
AppDelegate *appDelegate = (AppDelegate*)[[UIApplication sharedApplication] delegate];
UIViewController* presentingVC = self.presentingViewController;
[presentingVC dismissViewControllerAnimated:YES completion:^{
[presentingVC presentViewController:appDelegate.view2
animated:YES
completion:nil];
}];
}
and similarly for view2. Take care that you need this line:
UIViewController* presentingVC = self.presentingViewController;
as you can't refer to 'self.presentingViewController' inside the completion block as it's controller has been dismissed at this point.
I think that answers points 1 and 2.
To answer point 3 "Why can't I just display whatever view controller I want, without it necessarily having any relationship to other view controllers?" - well you can (via the rootViewController property of the window), but then you are going to have to implement navigation and manage your viewController pointers, which means you will end up creating a controller of some sort. Apple is helping you here by providing you with a few which cover most needs.
As regards your point 4 - the presenting of a viewController is controlled by the presenting VC, which is why you want to keep that one 'active'. When you send this message:
[self dismissViewControllerAnimated:completion:], self just reroutes the messge to it's presentingViewController. If you get rid of your presentingViewController your dismiss method will break.
Point 5 is answered above. You need to dismiss the topmost view first before asking an underlying view to present. Note that view1 is "still in memory" but only because you have retained a pointer to it in your app delegate.
update
As you are trying to get this to work with an initial launch-straight-to-view1, you could make a BOOL launched property and check/set it from your rootViewController's viewDidAppear:
- (void) viewDidAppear:(BOOL)animated
{
[super viewDidAppear:animated];
if (!self.launched) {
self.launched = TRUE;
AppDelegate *appDelegate = (AppDelegate*)[[UIApplication sharedApplication] delegate];
[self presentViewController:appDelegate.view1
animated:YES
completion:nil];
}
}
Let me try to tackle your points one by one.
1) No, you shouldn't do this all with presentViewController.
2) If you want to do root --> view1 --> view2 --> view1, then you don't do that all with presentViewController. To go from view1 back to view2 you should use dismissViewControllerAnimated:completion.
3) The view controllers do have a relationship when you use presentViewController:animated:. The presenting controller has a pointer to the one it presents, and the presented one has a pointer to the one that presented it. So, you're getting these relationships whether you want it or not. There is a way to display whatever controller you want with no relationship between them -- just reset the window's root view controller. The old view controller will be deallocated (if you don't keep a strong pointer to it), and the new one becomes the window's root view controller.
4) Presenting a view controller makes that controller a modal view controller -- it takes over the whole screen and is intended to be used as an interruption in the flow of the app. You really shouldn't use them extensively to go from one controller to another (and especially not for going "backwards" to previous controllers). Because of the way it's supposed to be used, you normally want to go back to the controller that presented it, so that's why it's kept "active" (in the sense that it's not deallocated).
5) You get that error because root's view is not on screen, view1's is. You need to present a view controller from the controller on screen.
I've trying to implement autorotate but my app is not listening to me!
The app has a tab bar controller which supervises 3 view controllers. The tab bar is created programatically in the app delegate. Each of the view controllers has this standard simple method:
- (BOOL) shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation
{
return YES;
}
The app delegate looks like this:
self.tabBarController = [[UITabBarController alloc] init];
self.tabBarController.viewControllers = [NSArray arrayWithObjects:gameVC, settingsVC, helpVC, nil];
self.window.rootViewController = self.tabBarController;
In addition, in the target summary area I have all 4 orientations for both the iPad and iPhone activated.
In the simulator, no rotation occurs with either device. I seem to be missing something. Perhaps one more setting is needed? Something out of order? There is nothing else in the project related to rotating views.
The only thing that you seemed to not have said in your response that I can think of is changing the device orientations under your info.plist. I know from personal experience that if you click on the supported device orientations in the target summary area, it might not actually change it in the Info property list. Check and make sure that all four are selected in the property list by doing the following:
Go to your Info.plist
Look under Supported interface orientations and Supported interface orientations (iPad)
Make sure that it has 4 strings under both: Portrait (bottom home button), Portrait (top home button), Landscape (left home button), Landscape (right home button)
User a ViewController for super purpose, and then inheritance it in the each of view controllers. In the super ViewController add this
(BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation{
return YES;
}
So, you just need to do once to make them autorotate
from http://developer.apple.com/library/ios/#DOCUMENTATION/WindowsViews/Conceptual/ViewControllerCatalog/Chapters/TabBarControllers.html#//apple_ref/doc/uid/TP40011313-CH3-SW26
Tab bar controllers support a portrait orientation by default and do
not rotate to a landscape orientation unless all of the contained view
controllers support such an orientation. When a device orientation
change occurs, the tab bar controller queries its array of view
controllers. If any one of them does not support the orientation, the
tab bar controller does not change its orientation.
#Zack #AlexanderZats This was subtle. I was reading this SO answer which brought me here This 2nd link is a great discussion of different possible reasons an app may not rotate. The last point caught my attention. Sure enough, I was overriding initWithNibName and not calling super on it. I think this ultimately meant that the the VCs were not in the responder chain. A huge thanks to all who gave me ideas and suggestions!
I have a situation whereby I am adding a view from another viewcontroller to an existing viewcontroller. For example:
//set up loading page
self.myLoadingPage = [[LoadingPageViewController alloc]init ];
self.myLoadingPage.view.frame = self.view.bounds;
self.myLoadingPage.view.hidden = YES;
[self.view addSubview:self.myLoadingPage.view];
Is it possible to set 'self.myLoadingPage' to be the first responder? This is the case whereby the loadingpage view size does not cover the entire size of the existing view and users can still interact with the superview (which is not the desired behaviour). I want to just enable the subview in this case.
When I had a similar problem, I made an invisible UIView that covered the entire screen, I added the large invisible UIView on top of the main view and made the loading view a subview of the invisible UIView.
The simplest solution is to override hitTest method in your loading view to return TRUE. This top view is first in the responder chain, the hitTest method gets called which NORMALLY returns TRUE if the point is within the view and will therefore be handled, returning TRUE regardless means you get the touch event and effectively block the message being resent to the next responder.
Interesting question. I found a similar post with a quote from the Apple Developer Forums on this issue:
To truly make this view the only thing
on screen that can receive touches
you'd need to either add another view
over top of everything else to catch
the rest of the touches, or subclass a
view somewhere in your hierarchy (or
your UIWindow itself) and override
hitTest:withEvent: to always return
your text view when it's visible, or
to return nil for touches not in your
text view.
This would seem to indicate there isn't a terribly straightforward solution (unless there was an API change regarding this made after October, 2010.)
Alternatively, I suppose you could go through all the other subviews in your superview and individually set their userInteractionEnabled properties to NO (but that would probably prove more cumbersome than the quoted solutions).
I would love to see other ways to allow this.
This question is about iOS device rotation and multiple controlled views in a UINavigationController. Some views should be constrained to portrait orientation, and some should autorotate freely. If you try and create the simplest setup with three views, you'll notice that the autorotation behavior has a few very nasty quirks. The scenario is, however, very simple, so I think I'm either not doing the autorotation implementation correctly, or I'm forgetting something.
I have a very basic demo app that shows the weirdness, and I made a video showing it in action.
Download the app (XCode project)
View the classes as a gist (rather lengthy)
Watch the question video (YouTube, 2m43s)
The setup is very basic: Three view controllers called FirstViewController, SecondViewController and ThirdViewController all extend an AbstractViewController that shows a label with the class' name and that return YES for shouldAutorotateToInterfaceOrientation: when the device is in portrait orientation. The SecondViewController overrides the this method to allow for all rotations. All three concrete classes add a few colored squares to be able to navigate between the views by pushing and popping the controllers onto/off the UINavigationController. So far a very simple scenario, I would say.
If you hold the device in portrait or landscape orientation, this is the result I would not only like to achieve, but would also expect. In the first image you see that all views are 'upright', and in the second you see that only the second view controller counter-rotates the device's orientation. To be clear, it should be possible to navigate from the second view in landscape mode to the third, but because that third only supports portrait orientation, it should only be shown in portrait orientation. The easiest way to see if the results are alright, is by looking at the position of the carrier bar.
But this question is here because the actual result is completely different. Depending on what view you're at when you rotate the device, and depending on what view you navigate to next, the views will not rotate (to be specific, the didOrientFromInterfaceOrientation: method is never called). If you're in landscape on the second and navigate to the third, it will have the same orientation as the second (=bad). If you navigate from the second back to the first however, the screen will rotate into a 'forced' portrait mode, and the carrier bar will be at the physical top of the device, regardless of how you're holding it. The video shows this in more detail.
My question is twofold:
Why does the first view controller rotate back, but not the third?
What needs to be done to get the correct behavior from your views when you only want some views to autorotate, but not others?
Cheers,
EP.
EDIT: As a last resort before putting a bounty on it, I completely rewrote this question to be shorter, clearer and hopefully more inviting to give an answer.
The short answer is that you're using UINavigationController, and that won't work like you want it to. From Apple's docs:
Why won't my UIViewController rotate with the device?
All child view controllers in your
UITabBarController or
UINavigationController do not agree on
a common orientation set.
To make sure that all your child view
controllers rotate correctly, you must
implement
shouldAutorotateToInterfaceOrientation
for each view controller representing
each tab or navigation level. Each
must agree on the same orientation for
that rotate to occur. That is, they
all should return YES for the same
orientation positions.
You can read more about view rotation issues here.
You'll have to roll your own view/controller stack management for what you want to do.
Make a bolean in App delegate to control which orientation you want for example make a bool to enable Portrait and in your view controller you want to allow Portrait enable it by shared application
in your view controller,where you want to enable or disable what ever orientation you want.
((APPNAMEAppDelegate *)[[UIApplication sharedApplication] delegate]).enablePortrait= NO;
in App Delegate.
- (NSUInteger)application:(UIApplication *)application supportedInterfaceOrientationsForWindow:(UIWindow *)window
{
NSLog(#"Interface orientations");
if(!enablePortrait)
return UIInterfaceOrientationMaskLandscape;
return UIInterfaceOrientationMaskLandscape|UIInterfaceOrientationMaskPortrait;
}
These method will be fired each time you rotate the device, Based on these BOOL enable the orientation you want.
There was a similar question a few years ago with a number of answers. Here is a recent answer from someone to that question:
Is there a documented way to set the iPhone orientation?
From what I understand, this is a problem a lot of people have and mostly hacks are the only way to fix it. Look through that thread if you haven't seen it before and see if anything works for you.
On a side note, I had a similar problem a while back when I was calling something in shouldAutorotate and I added some code to viewWillAppear to try to fix it. I honestly can't remember if it worked and I don't have a Mac anymore to try it out, but I found the code and I'll paste it here in case it gives any inspiration.
- (void)viewWillAppear:(BOOL)animated{
UIInterfaceOrientation o;
switch ([UIDevice currentDevice].orientation) {
case UIDeviceOrientationPortrait:
o = UIInterfaceOrientationPortrait;
break;
case UIDeviceOrientationLandscapeLeft:
o = UIInterfaceOrientationLandscapeLeft;
break;
case UIDeviceOrientationLandscapeRight:
o = UIInterfaceOrientationLandscapeRight;
break;
default:
break;
}
[self shouldAutorotateToInterfaceOrientation:o];
}
DO NOT USE THIS HACK, APPLE WILL REJECT THE APP BASED ON THE USE OF 'PRIVATE API'
For the sake of reference, I will leave my answer here, but the use of private API will not slip past the review board. I learnt something today :D As #younce quoted the Apple docs correctly, what I want cannot be achieved with the UINavigationController.
I had two options. First, I could have written my own navigation controller substitute, with all the horrors that one would have encountered while doing it. Secondly, I could have hacked the rotation into the view controllers, using an undocumented feature of UIDevice called setOrientation:animated:
Because the second was temptingly easy, I went for that one. This is what I did. You'll need a category to suppress compiler warnings about the setter not existing:
#interface UIDevice (UndocumentedFeatures)
-(void)setOrientation:(UIInterfaceOrientation)orientation animated:(BOOL)animated;
-(void)setOrientation:(UIInterfaceOrientation)orientation;
#end
Then you need to check for the supported orientations on viewWillAppear:. Next to the UIDevice methods used here, you could also force portrait orientation by presenting a modal view controller, but that will happen instantly and not animated, so this is my preferred way:
-(void)viewWillAppear:(BOOL)animated {
UIDevice *device = [UIDevice currentDevice];
UIDeviceOrientation realOrientation = device.orientation;
if ([self shouldAutorotateToInterfaceOrientation:realOrientation]) {
if (realOrientation != [UIApplication sharedApplication].statusBarOrientation) {
// Resetting the orientation will trigger the application to rotate
if ([device respondsToSelector:#selector(setOrientation:animated:)]) {
[device setOrientation:realOrientation animated:animated];
} else {
// Yes if Apple changes the implementation of this undocumented setter,
// we're back to square one.
}
}
} else if ([self shouldAutorotateToInterfaceOrientation:UIInterfaceOrientationPortrait]) {
if ([device respondsToSelector:#selector(setOrientation:animated:)]) {
// Then set the desired orientation
[device setOrientation:UIDeviceOrientationPortrait animated:animated];
// And set the real orientation back, we don't want to truly mess with the iPhone's balance system.
// Because the view does not rotate on this orientation, it won't influence the app visually.
[device setOrientation:realOrientation animated:animated];
}
}
}
The trick is to always keep the internal device orientation to the 'real' orientation of the device. If you start changing that, the rotation of your app will be out of balance.
But as I know now, this is just a sure way to get your app rejected. So option number two is just a bad option. Rewrite that NavigationController, or just have all your views support the same orientation set.
Cheers, EP.
In iOS 6, this has become a very simple issue. Simply create a special class for the views you want to autorotate. Then, in your rootVC, add this.
-(BOOL)shouldAutorotate{
BOOL should = NO;
NSLog(#"%#", [self.viewControllers[self.viewControllers.count-1] class]);
if ([self.viewControllers[self.viewControllers.count-1] isKindOfClass:[YourAutorotatingClass class]]) {
should = YES;
}
return should;
}
I know this is an old question, but I thought it worthwhile to mention.