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: ?
Related
With iOS8, I noticed that a view controller was no longer receiving a UIKeyboardWillSHowNotification, when it previously was with iOS7.
Here's the scenario:
1.) View Controller A is displaying a keyboard, and pushes View Controller B without resigning first responder
2.) View Controller B has a control that becomes first responder during its viewDidLoad call, while it's being created by VCA, before it's pushed onto the nav controller
3.) If VC A is NOT displaying a keyboard when pushing B, the notifications work fine. However, if A is still editing when pushing B, then B does not get a keyboard will show notification.
Without the keyboard notification, VC B is not resizing / repositioning and does not look right.
The workaround I'm using until I find a solution is to do the following from any view controllers that might be editing when pushing another view controller that might be editing:
i.e., before pushing another view controller, be sure to call:
[self.view endEditing:YES];
While it works, it doesn't seem good that the view controller (B) can be 'broken' by the state of the app prior to displaying it.
Question: Am I doing something wrong here?
As far as I can tell, one of 3 things are possible:
A.) I should be getting the notifications, but I'm not b/c I'm doing something wrong
B.) I should be getting the notifications, but I'm not b/c of a bug
C.) I can't rely on always getting the notifications...But if I don't get the notifications in VC B when it appears, I need to be able to get the keyboard dimensions of the displayed keyboard without relying on the keyboard notification info. All the apple docs say to use the notifications though (as far as I can find).... which points back to options A.) or B.).
I can create and upload sample code later tonight / early tomorrow to try and isolate / for you all to test/reproduce to see what I'm doing.
I can see the same issue with iOS8 / xCode6 (works with iOS7 and xCode5). In my case, I'm observing a systemStatus property on the model in my AppDelegate so as to log the user out and bring the user back to the login screen when the user logs out from anywhere in the app. I'm doing that by setting the window.rootViewController to the loginViewController in my App Delegate observeValueForKeyPath: method.
This works fine on iOS7 / xCode5 but on iOS8 / xCode6, I loose the keyboard in the way. Looks like my loginViewController might be registering for keyboard notifications (in its ViewWillAppear method) before the window's rootViewController switch is complete (in iOS8) thus registering to the old window's notification center...
I moved the registration for keyboard notifications to the ViewDidAppear: method instead and that seems to fix it but somehow this seems to be called twice for some reason.
I had a question regarding shouldAutorotateToInterfaceOrientation:
I have a grid view controller and I have put a breakpoint in the autorotate method it see if the method was being called. Turns out, even if I rotate the device (testing on simulator), the method is not being called.
Can anyone suggest me how to investigate this problem? Thanks.
Ensure that your view controller is either set as the window's rootViewController, or it is contained within a container view controller that is set as that.
Your issue will be that it is not receiving the window notification which is passed to the root view controller, and then further down to each of its children, and then down to their children etc.
If you have made your own custom container view controllers, ensure they all forward the message on to their children appropriately. Somewhere in that chain is a break.
Must I always resignFirstResponder for a UITextView? Or, will this happen automatically when its view controller disappears?
I'm asking because I'm having an issue similar to iPhone Objective-C: Keyboard won't hide with resignFirstResponder, sometimes, where the keyboard stays up even when the nav controller pushes and pops other view controllers. The keyboard works, and when I hit done, it unfocuses the UITextView (i.e., the cursor disappears), but the keyboard stays up.
I never found out why this is happening, but maybe it's due to not doing resignFirstResponder before pushing another view controller, but I thought it was optional?
At a total guess, the UITextView has a reference to the view controller (as its delegate) but does not retain it. When you go to the next screen, the controller is dealloced and then the UITextView (which has perhaps been retained by something else) tries to call back to the dealloced controller and crashes. When you call resignFirstResponder, you reverse the order this happens, and therefore no crash.
The way round this to add a textView.delegate = nil call in your view controller's dealloc method - obviously put it before you release the text view.
The contract between a UITextView and it's delegate says that the delegate will send -resignFirstResponder when the text view is done editing. This informs the framework that the view is done editing, fires the events relating to that (willEndEditing and didEndEditing), and allows other parts of the responder hierarchy to react accordingly. Failing to do so might work, but it's not following the contract (that's all a protocol is) it agreed to.
I don't think you have to because the Xcode Sample UICatalog UITextField doesn't call resignFirstResponder before the TextViewController is popped.
The reason the keyboard got stuck for me is that I was having the same view controller present two view controllers modally at the same time, one after the other. UIKit didn't like that.
Calling resignFirstResponder makes sure that the text property contains the actual text shown in the control.
Depending on the state this is not always necessary, but if your controls have resigned first responder, you know that you're working with valid data.
I have a login page at the beginning of my app that I do not want on the view stack. Is there a way to load my first post-login view after the login without using UINavigatorController?
Is there a better way to be doing this? Should I be using 2 UINavigationControllers? Is there a way to change the RootViewController for a UINavigationController?
Yes, you can change root controller of window. Set window's property rootViewController to new controller and you're done. Don't forget though that first controller (one you are removing) will not receive viewWillDisappear: and viewDidDisappear: messages. Send them yourself before switching controllers if you're interested in them.
You might also look at UIViewController#presentViewController
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.