I have a standard split view controller that I want to always show it's master view on iPads.
In the master view's viewDidLoad, I'm calling:
self.splitViewController.preferredDisplayMode = UISplitViewControllerDisplayModeAllVisible;
With this one line in place, I'm getting my desired effect (always shows the master). However, a strange thing also happens: The top layout guide appears to move to the top of the master view, under the navigation bar.
You can see the effect in this picture, where the first cell in the table view is partially hidden behind the navigation bar. In fact, there is a green view above it (it's a placeholder for something that will be there soon) that is totally hidden.
If I rotate the device to landscape then back to portrait, autolayout works as expected, and the views appear in the correct place:
I've tried the following in both viewDidLoad and viewDidAppear to try to force the views to lay out properly, but it's had no effect:
[self.splitViewController.view setNeedsLayout];
[self.splitViewController.view layoutIfNeeded];
I'm looking for any solutions/suggestions.
I want to answer my own question with a hindsight point of view.
Apple mentioned in its documentation:
When building your app’s user interface, the split view controller is typically the root view controller of your app’s window.
And later warns:
You cannot push a split view controller onto a navigation stack. Although it is possible to install a split view controller as a child in some other container view controllers, doing is not recommended in most cases. Split view controllers are normally installed at the root of your app’s window. For tips and guidance about ways to implement your interface, see iOS Human Interface Guidelines.
Although they're not outright saying never to use UISplitViewController as a non-root view controller, I have found that UISplitViewController behaves unreliably when used in a non-root manner. The bug mentioned in the question is just one of many other problems you will encounter, the worse of which (in my experience) is not propagating-viewWillAppear or -viewDidAppear calls to child view controllers.
If you want a non-root split view, I suggest roll your own custom split view.
The only thing that's worked for me is this:
https://stackoverflow.com/a/22084634/1919412
In my case, the issue only shows up the first time the user rotates from landscape to portrait mode (and without manually revealing the master pane first). So even though Rivera's workaround causes a jarring visual blip, it only has to happen at most once per launch.
I recently ran into the same issue and solved it by setting the preferredDisplayMode on launch like so:
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
...
if let splitController = self.window?.rootViewController as? UISplitViewController {
splitController.preferredDisplayMode = .allVisible
}
...
return true
}
Well:
I was facing the same problem (I guess).
But If I call:
.preferredDisplayMode=UISplitViewControllerDisplayModePrimaryOverlay
It worked like a charm.
Related
I'm really at a loss with this one, especially considering it has previously been working fine and I can't find anything in my commits that would have broken it.
I have a UITabBarController as the master view of a UISplitViewController. Each tab in the UITabBarController has its own UINavigationController that manages a stack of child VCs.
The issue is that any child VCs that have hidesBottomBarWhenPushed set to true results in a glitchy transition, but only the very first time any UINavigationController push occurs.
Here is a video of the transition bug
As you can see, it appears as if the safe area is collapsing on transition (and indeed, this does not occur on iPad or any other iPhone that lacks a bottom safeAreaInset. Yet, on the second (and all subsequent) push, it behaves perfectly fine.
The only thing I can think of is that I'm implementing the UISplitViewControllerDelegate methods to ensure Show Detail segues occur as a push rather than a modal when on the iPhone. However, the issue still happens with a regular push (bypassing the delegate methods altogether).
The various view controllers are all the standard base classes with no overridden layout behaviour, and I'm not implementing any custom transitions or transition coordinators.
Any thoughts on what the issue might be would be greatly appreciated.
So I managed to fix it. I was performing a modal segue before the UITabBarController was coming on screen. Apparently that messes up the layout, as I was able to confirm via a minimal replication. Changing the segue presentation type to "over full screen" rather than "default" stops the underlying UITabBarController from being removed from the view hierarchy and fixes the issue.
While that's six hours of my life I'll never get back I hope it helps someone in future.
My app has a simple organization, which I've configured in an Interface Builder storyboard (not in code). There is a Navigation View Controller, which has its Root View Controller set to my Main View Controller. My Main View contains a table, where cells segue to a Detail View Controller.
When I suspend the application while looking at the Detail View and then resume it, I'm returned to the Main View, rather than the Detail view. Why might this be?
Details:
I have set Restoration IDs in Interface Builder for the Navigation View Controller, the Main View Controller and the Detail View Controller. I've also tried adding a Restoration ID to the Table View and making the Main View Controller implement UIDataSourceModelAssociation.
My app is returning YES from shouldRestoreApplicationState and both the Main View and the Detail View have encode/decodeRestorableStateWithCoder methods.
I'm testing suspend/resume using the simulator: I run the app, navigate to the Detail View, hit the home button, and then click the stop button in XCode. To resume, I'm running the app again from XCode.
I see the following calls on suspend:
AppDelegate shouldSaveApplicationState
MainViewController encodeRestorableStateWithCoder
DetailViewController encodeRestorableStateWithCoder
And on resume:
AppDelegate shouldRestoreApplicationState
AppDelegate viewControllerWithRestorationIdentifierPath Navigation
AppDelegate viewControllerWithRestorationIdentifierPath Navigation/MainView
MainViewController viewDidLoad
AppDelegate viewControllerWithRestorationIdentifierPath Navigation/DetailView
MainViewController decodeRestorableStateWithCoder
In addition to the wrong view being restored, there's something else odd: Why is the Restoration Identifier Path for the Detail View "Navigation/DetailView" and not "Navigation/MainView/DetailView"? There is no direct relationship between the Navigation View Controller and the Detail View Controller. Their only connection in Interface Builder is via the segue from the Main View.
Have I misconfigured something?
I have tried assigning a Restoration Class to the Detail View. When that restoration code is invoked, it fails because the UIStateRestorationViewControllerStoryboardKey is not set in the coder.
Here's a toy version of my project which replicates the problem: https://github.com/WanderingStar/RestorationTest
I'm trying this with XCode Version 5.0 (5A1413) and iOS Simulator Version 7.0 (463.9.4), in case those are relevant.
The answer turned out to be simple: I was not calling
[super encodeRestorableStateWithCoder:coder];
in the encodeRestorableStateWithCoder:coder method in my View Controllers (and doing the same in decode...) which is what sets the storyboard in the coder.
This tutorial helped me step through each step of the process, and find out where I'd gone wrong:
http://useyourloaf.com/blog/2013/05/21/state-preservation-and-restoration.html
Also, it turns out that "Navigation/DetailView" is what's expected. The Navigation View Controller restores all of the views in its stack and then puts them back into the stack, rather than each view restoring the later views in the stack.
In the iOS App Programming Guide, section "State Preservation and Restoration" there is a convenient checklist for what you have to do to make restoration work.
After looking at your code it seems that you forgot step 3, Assign Restoration Classes. Your classes do not have these properties, and you did not implement viewControllerWithRestorationIdentifierPath in the app delegate.
Assign restoration classes to the appropriate view controllers. (If you do not do this, your app delegate is asked to provide the corresponding view controller at restore time.) See “Restoring Your View Controllers at Launch Time.”
I took a look at your sample and the applicationWillFinishLaunching is missing [self.window makeKeyAndVisible] which is a requirement for state restoration. This will make the split controller immediately collapse and then it will be restored correctly.
There is an issue that if it was preserved in landscape, i.e. separated split view , and then launched in portrait then the path will not be correct. In this case at launch it will first collapse to match the current screen, then it begin restore and first separate, then after restore has finished it will collapse again to match the current screen. During this time you need to implement viewControllerWithRestorationIdentifierPath and use the last string in the path to identify the controller and return it after having captured it from what the storyboard created initially in will finish launching. Then you can clear those properties in didFinish.
I have to support down to iOS 4.3.
My app outputs in the console :
Using two-stage rotation animation. To use the smoother single-stage animation, this application must remove two-stage method implementations.
As far as I know I'm not using two-staged rotation. I just have this method in my view controllers :
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation {
return YES;
}
What else should I check in order to fix that?
Edit:
More precisions: my app uses a UITabbarController subclass. When the app starts, it checks if a user is logged in and then initiates the controllers of the tabbar controller if it's the case. If there's no user logged in, a modal view is presented (from the tabbar controller) the prompt the user to login and the controllers of the tabbar controller aren't initialized (yet). The "two-staged rotation" error is shown only at that moment and the rotation doesn't work.
So to summarize, the problem happens in that situation:
The rootViewController of the main window is the tabbar controller
The tabbar controller is empty (there are no view controller in the tabs and there's no tab)
A view controller is modally presented from the tabbar controller
OK I found a solution.
It seems like the presented modal view won't rotate until the viewControllers property of the UITabBarController is initialized. Since the concerned modal view is actually for login, I don't want to display anything behind it until the user is logged in because the views intended to be hold by the tabbar controller depend on the fact that a user is logged in.
So now just before presenting the modal view, I initialize the tabbar controller with a single, empty UIViewController and I remove it when the modal view is dismissed (i.e. a user logged in).
Perhaps it seems like a hack but it works well. And even if I don't understand why, it doesn't seem completely illogical that the tabbar controller doesn't behave like we want until it is fully initialized.
If someone has a better solution or explanation, feel free to comment :)
There aren't many posts regarding this error, so I'll admit my own shortcomings for the benefit of the next person so focused on the trees they might miss the forest. I found a missing
[super viewWillAppear:animated];
call inside my sub.
I am writing an iPad application using MonoTouch, MonoDevelop and Interface Builder, and i've stumbled across a problem that I can't seem to solve. It is probably something simple. What I am trying to do is force an application to Landscapemode from start. The application starts in Landscape, but doesn't resize the subviews correctly.
Basically what I am doing in my appdelegate is that I add a SubView called IndexViewController.xib to Window. In IndexViewController I have a View with a Label on it, if I then in IndexViewController override the ShouldAutorotateToInterfaceOrientation to return this: it works correctly.
public override bool ShouldAutorotateToInterfaceOrientation (UIInterfaceOrientation toInterfaceOrientation)
{
return ((toInterfaceOrientation == UIInterfaceOrientation.LandscapeLeft) || (toInterfaceOrientation == UIInterfaceOrientation.LandscapeRight));
}
However, I now try to create a NavigationController and add it to the IndexController.xib-view on the Initialize:
void Initialize ()
{
this.View.AddSubview (NavController.View);
}
It rotates correctly but doesn't fill the entire "window", I have posted a screenshot and a sample solution. And my info.plist is set to allow "UIInterfaceOrientationLandscapeLeft" and "UIInterfaceOrientationLandscapeLeftRight" as UISupportedInterfaceOrientations
Screenshot
Sample solution here
There is probably something dead simple simple that I am missing, but I can't figure it out.
I'd say this may be due to the fact the way you're building the app's hierarchy isn't the suggested way of doing so. While you could carry on this way, you'll encounter more problems down the road.
Ideally you want to be adding the NavigationController's View the window rather than the having the NavigationController contained within a UIViewController.
In the app delegate, I would do something along the lines of:
IndexViewController indexVC = new IndexViewController()
UINavigationController navController = new UINavigationController(indexVC);
window.AddSubview(navController.View);
This will add the navigation controller's view to the window, with the RootViewController of the NavigationController being your IndexViewController
You should also remove the UINavigationController that is added to your IndexViewController in Initialise().
I just downloaded your sample solution and tried this very quickly and it loaded the app in Landscape with the view fully filling the screen. It didn't auto rotate, but this'll certainly be a good starting point for you :)
Short version:
I'm alloc/init/retaining a new UIViewController in one UIViewControllers viewDidLoad method, adding the new View to self.view. This usually works, but it seems to mess up orientation change handling of my iPad app.
Longer version:
I'm building a fairly complex iPad application, involving a lot of views and viewcontrollers. After running into some difficulties adjusting to the device orientation, I made a simple XCode project to figure out what the problem is.
Firstly, I have read the Apple Docs on this subject (a small document called "Why won't my UIViewController rotate with the device?"), and while I do believe it has something to do with one of the reasons listed there, I'm not really sure how to fix it.
In my test project I have an appDelegate, a rootViewController, and a UISplitViewController with two custom viewControllers. I use a button on the rootViewController to switch to the splitViewController, and from there I can use a button to switch back to the rootViewController. So far everything is great, i.e. all views adjust to the device orientation.
However, in the right viewController of the splitViewController, I use the viewDidLoad method to initialize some other viewControllers, and add their views to its own view:
self.newViewController = [[UIViewController new] autorelease];
[newViewController.view setBackgroundColor:[UIColor yellowColor]];
[self.view addSubview:newViewController.view];
This is where things go wrong. Somehow, after adding this view, adjusting to device orientation is messy. On startup everything is fine, after I switch to the splitViewController everything is still fine, but as soon as I switch back to the rootViewController it's all over. I have tried (almost) everything regarding retaining and releasing the viewcontroller, but nothing seems to fix it.
As you can see from the code above, I have declared the newViewController as a property, but the same happens if I don't.
Shouldn't I be adding a ViewController's view to my own view at all? That would really mess up my project, as I have a lot of viewControllers doing all sorts of things.
Any help on this would be greatly appreciated...
I had the same problem, seams resolved by removing from the parent view the "autoresize subview" option in IB.
Select the view a then: Inspector -> Attributes (first tab) -> drawing.
What I think is happening is that your new viewcontroller is getting the autorotation calls and probably not handling them. Meanwhile your old viewcontrollers and its views won't get the autorotation calls and will be stuck in whatever orientation they were in.
I can't tell, but I think what you want to do is to make a UIView and add it to your old viewcontroller, instead of making a UIVIewController and adding its view.