-1

So I've searched through a few pages and found some answers here on stack overflow, but nothing seems to be working.

I have a root view controller. It has 2 children view controllers. (a base content view and a menu overlay).

The goal is to have the content view respond to orientation change, but the overlay menu to only display in portrait (design choices makes much more sense in context)

In my root VC I've added my children views in this manner:

self.contentVC = [DELEGATE.storyboard instantiateViewControllerWithIdentifier:@"content"];
[self addChildViewController:self.contentVC];
self.contentVC.view.frame = self.view.bounds;
[self.view addSubview:self.contentVC.view];
[self.contentVC didMoveToParentViewController:self];

And root VC has following methods declared:

-(NSUInteger)supportedInterfaceOrientations
{
    return UIInterfaceOrientationMaskAll;
}

-(BOOL)shouldAutomaticallyForwardAppearanceMethods{
    return YES;
}

-(BOOL) shouldAutomaticallyForwardRotationMethods{
    return YES;
}

-(BOOL)shouldAutorotate
{
    return YES;
}

In my conentVC:

-(NSUInteger)supportedInterfaceOrientations
{
    return UIInterfaceOrientationMaskAll;
}

-(BOOL)shouldAutorotate
{
    return YES;
}

And in the menuVC:

-(NSUInteger)supportedInterfaceOrientations
{
    return UIInterfaceOrientationMaskPortrait;
}

-(BOOL)shouldAutorotate
{
    return NO;
}

I programmatically solved this by just having the rootVC call a method on contentVC that positions and rotates elements, and this is working fine right now. My main concern is that if apple adds more screen sizes, autorotate is much more adaptable. Is there an autorotate solution I am missing?

As stated, I've checked some posts out already and know that similar things have been discussed, but any solutions I've found dont seem to work.

dave
  • 1
  • 1

2 Answers2

1

You've misunderstood what shouldAutomaticallyForwardRotationMethods does. It forwards these methods only (see the docs, please):

 willRotateToInterfaceOrientation:duration:
 willAnimateRotationToInterfaceOrientation:duration:
 didRotateFromInterfaceOrientation:

There is no need for the framework to call supportedInterfaceOrientations: and shouldAutorotate on the children, because nowadays only the topmost view controller is consulted. (A UINavigationController no longer consults its newly pushed child, for example.) If your parent feels like consulting its children, fine; it should just go ahead and consult them. But that's your call and has nothing to do with shouldAutomaticallyForwardRotationMethods.

matt
  • 515,959
  • 87
  • 875
  • 1,141
  • Thanks for the quick response. Clarification on shouldAutomaticallyForwardRotationMethods cleared a few questions. Def wasnt Is there a way to decouple the rotation behavior on the two children VC's and have one respond to autoRotate and the other not to? The only reason I am attempting to keep both children VC's tied to the parent is a pre-existing menu structure that changing will ripple effects that Im really attempting to minimize here. – dave May 30 '14 at 18:07
  • I don't understand your secondary question ("decouple"). The children are not consulted in any way. Only the topmost view controller is consulted (the ultimate parent or presented view controller). What happens depends on the answer that it gives. I'm just repeating myself at this point. – matt May 30 '14 at 18:10
  • My question: Is there a way to have only 1 of the 2 child view controllers I have set up respond to auto rotation in this scenario. That is my goal, and my original question was is there a way to set this up. I stated I have currently implemented a methodology that 'works' to replicate this interface - the root VC calls a method on the child VC it wants to rotate, and that method handles the rotation on that screen. I would PREFER to use auto rotate if that is an option. – dave May 30 '14 at 18:14
  • Neither of the child view controllers "responds to auto rotation" because neither of them is or ever will be consulted by the framework. What _you_ do is up to _you_. Now I've repeated myself a third time. – matt May 30 '14 at 18:17
  • Look - I get the impression you for some reason are irritated by a stranger you (for some reason) are trying to help. I understand that neither child VC class is being consulted by the framework. Thanks for your time, but Im not asking you to repeat any part of you prior answers. I understand that the framework is not consulting the children VC. – dave May 30 '14 at 18:26
  • What I "Want to do" is in landscape mode have one child VC display in landscape and the other stay in portrait. I cant seem to do that. The code content above is just the setup I have for context. You seem to be confusing reiterating that my setup does not work - which is evident by my placing the question to begin with - with answering my question. – dave May 30 '14 at 18:29
  • And while I would prefer to keep the current parent - child configuration (due to the architecture currently existing in the app) if the only way to obtain said behavior is to go another direction, then so be it. – dave May 30 '14 at 18:32
  • I don't see that you need to go in any new direction. To me, you seemed to have solved it. The parent can give different answers to `supportedInterfaceOrientations` at different times. However, this will not _cause_ rotation. The only to cause rotation in iOS 7 is to use a presented view controller, as I have explained in various places such as http://stackoverflow.com/questions/22538461/cant-restrict-uiviewcontroller-to-portrait-only/22538751#22538751 – matt May 30 '14 at 20:35
0

You can have a look at the menu Device Orientation in TARGETS-General-Deployment Info enter image description here

GhostCat
  • 137,827
  • 25
  • 176
  • 248
  • The system intersects the view controller's supported orientations with the app's supported orientations (as determined by the Info.plist file or the app delegate's application:supportedInterfaceOrientationsForWindow: method) to determine whether to rotate. by[supportedInterfaceOrientations](https://developer.apple.com/documentation/uikit/uiviewcontroller/1621435-supportedinterfaceorientations?language=objc) – TengFeng Lian Jul 19 '17 at 06:57