I've spent the last hour or so trying to work out why not all my UIViewControllers are receiving orientation change notifications.
I've got a subclassed UIViewController attached to the window, that internally creates a few other UIViewControllers to manage smaller portions of the screen which are re-used elsewhere in the application I'm building.
The problem is, only the UIViewController attached to the window is receiving the orientation change notifications.
The other UIViewControllers aren't firing their - (void)willAnimateRotationToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation duration:(NSTimeInterval)duration methods.
I'm assuming it's expected behaviour, and I can't seem to find anything mentioning it in the docs.
Is there a way to make sure all active UIViewControllers are getting orientation changes? Or does the parent view controller have to tell it's children when changes are occurring?
Cheers.
Are all your view controllers returning YES to shouldAutorotateToInterfaceOrientation: ? If so, I suggest to pass the interface orientation messages from the parent to the children viewControllers, as you suggested.
I have been doing so before and had no problems with that approach so far.
Related
I've tested the same code I'm using now in iOS7 and it works fine, but in iOS8 my scrollview appears to not be passing touch events to subviews. I have a view structure like this:
- UIScrollView
- UIView
- buttonView
I've subclassed each of the above views and added the touchesBegan:, touchesCancelled:, touchesShouldCancelInContentView, touchesShouldBegin: methods to each and the only view that ever registers anything is the UIScrollView. Also the only method that executes on the UIScrollView subclass is touchesBegan:. No other delegate methods are fired. This didn't happen in iOS7 with the same code, but it's happening now in iOS8. Can anyone tell me what may have changed that would cause this behavior or even better a fix. I've looked at many posts on this topic, but the standard answers have not done anything.
I've tried changing delaysContentTouches and CancellableContentTouches to no avail.
Thanks for any help.
I have a following situation (testing on iPad, iOS 5.1):
There is a UIPopoverController with UINavigationController inside and custom popover background view (subclass of UIPopoverBackgroundView).
There is a generic UIViewController (let's call it VC1) as the root VC in the Navigation Controller.
I push another UIViewController (VC2) with UITableView on the Navigation Controller stack.
Effect:
Table scrolling is choppy (looks like 10-15 fps). For testing purposes I use a simplest possible UITableView, without images etc. so it's NOT caused by bad UITableView implementation.
Scrolling is not choppy if the VC2 is the root view controller of
Navigation Controller, even with the custom Popover background.
It's also not choppy if pushed as the second VC but I don't use custom bg view class for UIPopoverController.
I log each of the overriden methods inside my UIPopoverBackgroundView subclass, and they aren't called constantly or anything, which could theoretically cause performance hit. I'm going to debug the problem further but maybe someone has already solved it before?
Or maybe someone has good suggestions on how to find the culprit? I tried looking into time profiler for offending function calls, but I didn't find much there...
Let me start off by saying I'm not having a problem when rotating views in iOS6 after the app is open. This issue is only happening for me when the app is launched for the first time while in landscape. The new shouldAutorotate and supportedInterfaceOrientations methods are both called when launched, however none of the rotation methods are called, like willRotateToInterfaceOrientation:duration:. (shouldAutorotate is always returning YES, and supportedInterfaceOrientations is always returning UIInterfaceOrientationMaskAll)
In iOS5, the 'first' orientation to landscape on launch was taken care of automatically. Is there an explanation for why the device wouldn't call this first landscape rotation in iOS6? (The view controller I'm checking is the root controller of the window/app delegate).
Thanks in advance for any help with and insight into this.
I suppose that since the interface is not actually rotating, that the method isn't being called.
If you want to do some setup based on the orientation, have you thought of using the view controller's intefaceOrientation property?
You should now use the viewWillLayoutSubviews method and not willRotateToInterfaceOrientation:duration:. The reason is because willRotateToInterfaceOrientation:duration: is not guaranteed to be called in a number of situations.
This is stated in the iOS6 release notes among other places.
Is there a way to prevent auto-rotation from a view controller when the keyboard is showing?
I don't want to capture the notifications and handle all drawing by hand if possible.
Edit:I found that the root view controller in the chain was preventing the shouldAutorotateToInterfaceOrientation: message from coming down the pipe. Once it was taken away at the root view controller level and left to the sub-view controllers to handle it worked quite well.
Does the editing use a UITextField? If so, have you tried using the UITextFieldDelegate method textFieldShouldBeginEditing: as a place to modify a flag referenced by shouldAutorotateToInterfaceOrientation: ?
I wonder what is the proper way to get back some message from a child view.
I have a object that is edited in the child view. I wanna see in the TableView their modifications.
However, I don't know a clean way to do it (I don't like a singleton here).
Is possible get notified when the Child view dissapear and get some info on that?
You can use the UIViewController notifications viewWillDisappear: and viewDidDisappear: to be notified right before a certain UIView is about to disappear and right after it disappears respectively. Note that most of the various UIKit objects (including UITableView) are subclasses of UIView.
IMHO, the "correct" way would be to implement a custom protocol in the view's controller (probably navigation controller in your case) or the application delegate and have the child view communicate using it when it gets the viewWillDisappear and/or viewWillDisappear notifications (as mentioned in Adam's reply). Similarly, in the parent view you can refresh the necessary information in the viewWillAppear handler.
This way, the parent view is getting its data from the delegate and not directly from a specific child view, which maintains MVC in your design.
You could also issue a notification (using NSNotificationCenter) that the parent would be subscribed to listen for - that has the side benefit that other classes could be notified as well.
But if it's a pretty strict relationship where only the sub view and master table will care, you probably should set your table view controller as a delegate of the subview and have the subview call the delegate directly (a protocol as mentioned is a good idea for something like this).