I start my app in landscape for iPad. A nav controller holds my tableVC I click on a cell we push a new VC onto the stack. That works fine. The problem is, when I press the standard "back" button on the nav controller, my app gets forced into portrait and my tableVC is off of the screen. I am doing no manual positioning of views. This doesn't happen if I start the app in portrait mode.
How do I fix this abnormal behavior?
Notes: There is also a tab bar present in the app if it matters.
Upon further testing, if I load the NavController in portrait (with the first view being the table view) then switch it to landscape, then select the cell, then press back, it works fine. So the problem only happens if i start the app in landscape and never turn it to portrait.
EVERY VC has shouldAutoRotate set to return YES. I have subclassed the tab bar and done the same. I am wondering if this is a bug. Perhaps the problem lies in the fact that I took existing .XIB files and their views that were created for iPhone, then copied and pasted them, then deleted the iPhone specific views and then added iPad views.
If your subclassed TabBar Controller returns yes, and ALL of your VCs return yes for shouldAutoRotate, then the problem lies within your xib files. Though your explanation makes it sound like the VC you are pushing doesn't return yes, you've stated that it does, so it must be the xib files.
In IB, try setting the default orientation of your xib views to landscape, clean - build and run.
That may provide a clue or two.
Maybe you can create a new and simple iPad application with just a tabbarcontroller a navigation controller and 2 viewcontrollers to test if the cause is or is not the recycled iPhone .XIB files.
Also you can Command+Shift+F to search in the whole project for ": UIViewController" to double check that every VC has shouldAutoRotate set to return YES, in case you have third party code in your application that has a subclass of UIViewController on it. (the search will return a list of headers files that inherits from UIViewController).
I had had similar problems with really weird behaviors that were fixed by deleting the .XIB file and made it again.
Good luck finding the problem =)
Related
I have a UINavigationController controlling a stack of UIViewControllers. When I push a certain UITableViewController onto the stack, I find that the top row of its UITableView is hidden behind the UINavigationBar.
This problem only happens on the iPad, not the iPhone. I am using the same stack on both.
Also it only happens on one of my controller stacks. I push the same UITableViewController subclass on stacks controlled by two other UINavigationControllers, and there is no problem.
One difference in the problem case is that the UITableViewController is pushed from a UIViewController that is displaying the results table generated by a UISearchDisplayController. I don't see why this should matter (and, as I said, on the iPhone it works fine), but maybe it is significant given that a UISearchDisplayController hides the navigation bar when the UISearchBar becomes first responder.
The problem affects both the iPad device and the iPad simulator. I am using a typical UISplitViewController design, with these stacks in the left hand pane. The problem still occurs in the popover when in portrait.
I had the same problem after migrating an iphone app to a universal app. Here is what solved the problem for me. open your MainWindow.xib and dbl-click the window object. If it opens in iphone size you need to upgrade your nib. Select the document window and choose the menu item File > Create iPad Version. Save this nib with the name MainWindow-iPad.xib. Delete you original MainWindow.xib and add this one instead. After doing these steps problem disappeared and works fine for me on both iPad & iPhone.
Cheers, Harry
I'm aware some of you may not be familiar with Monotouch, but this could certainly be a general iOS issue rather than a specific Monotouch issue.
I'm recreating an app with similar functionality to the default mail app:
This is a simple recreation of our app. It's a UIView which contains a UITableView and a UIToolbar. It's loaded from a XIB file (which contains accompanying view controller code). This view is a UITabController view (though I'm sure this shouldnt affect things?).
This has been pushed from a navigation Controller using
controller.PushViewController(inboxItem.Controller, true);
(where inboxItem is a custom object I've made, the Controller property being the inboxItem's view controller).
Pressing the right hand button on the toolbar presents a new modal view (compose new message) - which does its thing and no matter which way its dismissed, upon dismissal, the UIToolbar disappears. However, if I am to click on another tab then click back onto this tab, the Toolbar reappears. Is this a redraw issue?
Am I doing something wrong with the way I'm structuring my app? Or have I happened to stumble across some bizarre iOS/Monotouch bug? (I'm hoping it's for the former - so I can improve my iOS development).
I solved the problem. Basically, what was happening was when the ModalView was being presented and then dismissed, the toolBar was being moved down by 44 pixels each time.
In my example, the toolBar is placed above a UITabBar, so when the modal view was dismissed the toolbar was being moved out of view. I'm not sure why this is happening but I'll be sure to file appropriate bug reports.
One quick and (very) dirty way around this is to move the toolBar up 44 pixels when displaying the modalview, so that when it is dismissed, it will move it back down to the appropriate position.
I have application with multiple UIViewControllers using navigation controller. UIViewController contains tableView, searchbar (that I can show/hide) and toolbar. All of this is added as subviews to its view. All this subviews are created after UIViewController is initialized and their content depend on UIVievController's content.
It works fine expect one problem. When I play with my app a little, move back and forth, open some modal views etc sometimes after navigating back to my root VC all it's subviews dissapear and all I get is white screen.
I double checked all my code and I can't find source of problem (I certainly don't remove them myself). I wasn't able to find exact patern how to reproduce this, it seems random. Any idea why iphone would remove my subviews from VC? I would post some code, but I don't want to put it all here and I am not sure which part is important, so if you wish to see some, let me know
Add your views in loadView or viewDidLoad: when viewDidUnload is called, the view is released, so they need to be created again when the view is shown again.
I'm doing an iPad tech demo and I'm running into a serious technical problem.
I have an app concept that leverages UISplitViewController, but NOT as the primary controller for the entire app.
The app flow could be described roughly as this:
Home screen (UIViewController)
List->Detail "Catalog" (UISplitViewController)
Super Detail Screen (UIViewController but could conceivable also be a child of SplitView).
The problem is in the flow between Home and Catalog. Once a UISplitViewController view is added to the UIWindow, it starts to throw hissy fits.
The problem can be summarized at this:
When a UISplitView generates a popover view, it appears to then be latched to its parent view. Upon removing the UISplitView from the UIWindow subviews, you will get a CoreGraphics exception and the view will fail to be removed.
When adding other views (presumably in this case, the home screen to which you are returning), they do not autorotate, instead, the UISplitView, which has failed to be removed due to a CG exception, continues to respond to the rotation instead, causing horrible rendering bugs that can't be just "dealt with". At this point, adding any views, even re-adding the SplitView, causes a cascade of render bugs.
I then tried simply to leave the SplitView ever present as the "bottom" view, and keeping adding and removing the Home Screen from on top of it, but this fails as SplitView dominates the Orientation change calls, and Home Screen will not rotate, even if you call [homeScreen becomeFirstResponder]
You can't put SplitView into a hierarchy like UINavigationController, you will get an outright runtime error, so that option is off the table. Modals just look bad and are discourages anyway.
My presumption at this moment is that the only proper way to deal with this problem is so somehow "disarm" UISplitViewController so that it can be removed from its parent view without throwing an unhandled exception, but I have no idea how.
If you want to see an app that does exactly what I need to do, check out GILT Groupe in the iPad app store. They pulled it off, but they seem to have programmed an entire custom view transition set.
Help would be greatly appreciated.
Apple states:
The split view controller’s view
should always be installed as the root
view of your application window. You
should never present a split view
inside of a navigation or tab bar
interface.
This does mean it should be root view and not subview of another view. Even though they add:
You should never present a split view inside of a navigation or tab bar interface
That does not mean you can add it as a subview of any other controller either. (sorry)
I have a feeling that what you are experiencing is the byproduct of trying to do so. I am actually surprised that GILT Groupe's app did not get rejected. Apple has a tendency to enforce these HIG guidelines rather strictly lately. They (as you found out already) cause a rather nasty runtime error when you attempt to add them to a NavigationController.
I've solved this for myself... actually worked around... by presenting all other possible full screen views as modals of the SplitView...
This is an unsavory way of doing things in my book, but Apple leaves you little choice if you want to leverage a SplitView only "sometimes" within an app.
I had some success by creating a second UIWindow. I associate the UISplitViewController with that, and switch it out with the main window when I want to show the splitview. It seems to work they way I wanted, except for a slight delay in rotations and a log message about "wait_fences".
Unless your developing for jail-broken devices then bending apples rules/wishes isn't a good idea. Like Jann and Jasconius state above this means keeping a splitView controller view root, not over-using modals (vague) and not using multiple windows.
Also, the Gilt app is only available in the US
I'v been trying to find a solution too and have ended up programatically removing views from the window like Tuannd talks about but the landscape rendering bug is unforgivable.
#Jasconius, What is the max number of modals are you are presenting at any time?
I am struggling with this same issue. I've been trying various things poking at the UISplitViewController as a black box and see how it reacts.
I seem to have come up with a solution to my case which seems to be working satisfactorily.
The key appears to be that the first view added to the UIWindow is the only view properly initialized. All the problems I've had tend to stem from incorrect notification of the orientation of the device. The first view added, apparently has this correctly configured.
In my case I didn't want the UISplitView as the first view. The following is working for me.
The app delegate application:didFinishLaunching method is special. Adding the view to the UIWindow must occur here. If it is done elsewhere it does not get configured properly.
Essentially the magic sauce, is have the split view be the first view added to the window. Its then ok to remove it as long as you retain the UISplitViewController. From then on you can swap other views in and out, including the UISplitView and most things seem to be ok.
I've still run into a few issues. Popovers on views other than the split view are confused on the views frames and location of toolbar buttons and will display in the wrong location. I place then in a specific location and that seems to handle that case.
If a popover on the split view is still displayed, and you try to view another view, the orientation of the second view is confused and shows up sideways. If that view is accessed before the popup is displayed, all is well. I've fixed this my manually dismissing the popover before switching to any other view.
Here's the code if it helps. All the controllers are instance variables of appDelegate
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
// This also seems to work as good magic. Seems to set orientation and size properties that persist.
[window addSubview:splitViewController.view];
[splitViewController.view removeFromSuperview];
[self switchToNewViewController:firstController];
[window makeKeyAndVisible];
return TRUE;
}
- (void)switchToNewViewController:(UIViewController *)newViewController {
[popoverController dismissPopoverAnimated:FALSE];
if (newViewController != currentViewController) {
[currentViewController removeFromSuperview];
currentViewController = newViewController;
[window addSubView:newViewController.view];
}
}
Just wanted to say that I was running into these same issues, found this forum topic, and followed the advice from g051051 above. This is working perfectly for me. I am not seeing any glitch, and no messages about wait_fences in the console of the device.
I simply used IB to create two UIWindow objects in the main XIB, created as normal the UISplitViewController and then also an instance of my other controller derived from UIViewController (which I am using for full screen display). I have simply hooked them up by attaching the rootViewController for each UIWindow to its appropriate controller.
In application:didLaunch...: method I can decide which window to send the makeKeyAndVisible method and which to set to hidden. When the user want to switch back and forth I simply have to send makeKeyAndVisible to one and set the hidden property on the other, that's all there is to it.
As indicated all of the rotation related messages are sent to each controller appropriately, regardless of which one is associated with the currently visible window.
Anyway, works great for me, and actually quite easy to set up.
My application is pretty simple: it starts up with a view controller that holds a table view (in grouped view layout) with a few options. When the user taps on one of the options, I push another view controller onto my navigation controller.
This second view controller simply displays a UIImageView, and the user can change the screen orientation on this view controller between portrait/landscape modes. This works just fine, and all is happy.
However, if the user taps on the "Back" button on my navigation bar while on the landscape mode, the first controller's layout is all messed up. See below for before/after screenshots:
(source: pessoal.org)
(source: pessoal.org)
Any clues on how to force the first view controller (second screenshot in this post) to stay within the portrait screen orientation?
There does not appear to be a way to do this using the documented methods.
I have filed a bug for this: rdar://6399924
"There is no way to always restrict a UIViewController to one orientation"
You can see it on open radar (along with a link to sample code to reproduce the problem) here: http://openradar.appspot.com/radar?id=697
Like someone on the open radar suggested, a workaround is to disable "back" button while in non-portrait:
- (void)didRotateFromInterfaceOrientation:(UIInterfaceOrientation)fromInterfaceOrientation{
// don't let user press "back" button in landscape - otherwise previous view and the rest of the application
// will also be in landscape which we did not feel like testing yet
self.navigationController.navigationBarHidden = (UIInterfaceOrientationPortrait != self.interfaceOrientation);
}
There is a solution to do that : it's to use a view controller and adding its view to the window. then in that controller you force landscape in the shouldAutorotate... methode. It works fine, but be sure it's necessary for your project to use that, because it's not very smart to force the user to turn his iPhone. By the way, here is an example code if you need it.
http://www.geckogeek.fr/iphone-forcer-le-mode-landscape-ou-portrait-en-cours-dexecution.html
I wasn't able to get this to work the way I wanted. You ought to be able to set a particular orientation for a ViewController, but the NavigationController doesn't seem to always do the right thing.
I ennded up re-designing my screens so that they all work in either orientation. That might be extra work, but it "feels" more natural, anyway.