I'm new to iOS development and have recently learned that to make the on screen keyboard disappear we must always call resignFirstResponder on the text view. This causes the text view to relinquish it's first responder status, and hence the keyboard disappears, since there is no need for the text view to respond.
However I also noticed that there's the becomeFirstResponder method to make a view a first responder. However, this method is never called on the text view. So when/how does a textview become first responder when that method is never called?(at least, by me. I'm unsure if it is called elsewhere in the system)
My theory is that is has to already be a first responder before it can resign the first responder status.
firstResponder status is automatically handled for you when a user taps on the text field. So long as user interaction is enabled for the UITextField/UITextView, the keyboard should appear when tapped.
You can monitor for it using the delegate method textViewDidBeginEditiing or, more broadly, by listening for keyboard appearance notifications (UIKeyboardWillShowNotification and UIKeyboardDidShowNotification).
Further, there are ways to dismiss the keyboard without the need of calling the corresponding method resignFirstResponder (such as calling endEditing: on a container view, or setting a scroll view's UIScrollViewKeyboardDismissMode).
Note: In the simulator, it is possible that the keyboard still doesn't appear even if all is correctly working. In that case you just want to make sure keyboard hardware is toggled (CMD+K) for the simulator.
You call becomeFirstResponder yourself if you want to give a UITextField focus and show the keyboard.
This is useful for view controllers that are basically forms. For example, if a user presses a "Sign Up" button, you might push a view controller with a couple of text fields and call becomeFirstResponder on the first one to automatically give it focus and open the keyboard.
Related
I have a ViewController with a TextField for user input and a Quit button in a NavigationBar.
Normally, the user inputs text into the textField and the input is processed in textFieldDidEndEditing. If the Quit button is tapped before editing starts, then it segues correctly to the parent ViewController.
However, if editing has started on the textField and then the Quit button is tapped, textFieldDidEndEditing is still called, which I don't want to happen.
I have tried using textFieldDidEndEditing:reason: but the returned reason in both cases is UITextFieldDidEndEditingReasonCommitted. It seems that UITextFieldDidEndEditingReasonCancelled is only valid in tvOS not iOS.
How else can I detect that the user has Quit and prevent textFieldDidEndEditing from running to completion?
You can't prevent textFieldDidEndEditing from being called. Dismissing the view controller dismisses the text field. Since the text field is no longer being edited, the delegate method will be called.
One option you have is to set a flag when the user taps the Quit button. Then in your implementation of textFieldDidEndEditing you can check if that flag it set or not and act accordingly.
I've got a keyboard toolbar that isn't being hidden properly. If the user hits the Done button, I call the following code:
- (void)accessoryDoneAction:(id)sender {
[self.selectedAmount endEditing:YES];
}
Then if the user moves to the next screen, comes back, locks the phone and unlocks it everything is fine. However, if the user does not hit the Done button, and moves on to the next view, comes back, locks the phone and unlocks the phone, they will see the keyboard toolbar at the bottom of the screen.
The only difference between the two scenarios, that I can see, is that if the user does not hit the done button, endEditing isn't called until viewWillDisappear: or viewDidDisappear: (I've tried both.) Neither one seems to have the same effect, as the toolbar is still present after moving on, coming back, locking and unlocking.
I've even tried placing it in viewDidAppear: after reading through this thread Keyboard does not disappear after viewDidDisappear on iOS 7, but that didn't work either.
Any suggestions for why calling endEditing: in the lifecycle methods isn't accomplishing the same thing as calling it when the Done button is hit?
I know that the view controller must be firstResponder in order for the inputAccessory to stay at the bottom. I am using a custom inputView / keyboard. I can manually dismiss it with a done button by removing the inputView but not resigning first responder. However when I enable the interactive drag to dismiss on my scrollview, the code automatically resigns first responder. So how can I use the interactive drag to dismiss and yet keep my viewcontroller as first responder? Anyone done this before? I thought maybe it is not possible and that I may need to make my own interactive drag to dismiss using a gesture recognizer.
More info:
I have a button that swaps between standard keyboard and my custom one. I have seen dismissing these cause 2 keyboard did dismiss notifications. I thought I could become firstResponder in the keyboardDidHide method but this didn't work well since I couldn't tell the difference between when I manually dismissed the keyboard and when the interactive drag does it. This matters because I don't need to reload the input view or become first responder when I manually dismiss because I took care of it already.
Any suggestions would be amazing. I am trying to use inputView and inputAccessoryView on the UIViewController level.
Well after a day of pulling my hair, I have an answer.
Using the canResignFirstResponder of my viewcontroller did the trick. In viewWillAppear I set a BOOL responderOverride = YES;
In viewWillDisappear I call
responderOverride = NO;
[self resignFirstResponder];
When the interactive drag on the scrollview tries to resignFirstResponder, canResignFirstResponder returns no which prevents my viewcontroller from resigning and keeps my input accessory retained and sitting at the bottom of the screen.
There is a lot of other code with reloading input views but since the real question was how to force a controller to stay first responder so we don't lose our input accessory view, then this solution works.
override var canBecomeFirstResponder : Bool {
get {
retrun true
}
}
This works for me
In my iOS project, I have a form which contains various text fields. Some text fields are edited by keyboard and some by picker view which is placed on the popover.
When I go on filling text fields, without dismissing it and then if I click on popover text field keyboard remains open.
It appears as both keyboard and popover present on screen at the same time, which I don't want.
I am able to get whether the keyboard is opened or not by setting a flag in keyboard notification methods and also the last text field that was edited through text filed delegates. And have tried
[self endEditing: YES]; (as it is in a table cell)
[lastEditedTextField resignFirstResponder];
Even try to pass keyboard dismiss the notification by my self (without knowing whether it is possible or not)
[[NSNotificationCenter defaultCenter] postNotificationName:UIKeyboardWillHideNotification object:nil];
but nothing is working.
How can I dismiss keyboard (if already open) whenever popover appears?
You can call:
[self.view endEditing:YES];
But, a better solution is likely to present the picker using the UIResponder
inputView so it automatically replaces the keyboard and you don't need to mediate between 2 different things (and the user doesn't switch between different parts of the screen potentially).
Try to implement textFieldShouldBeginEditing: and inside it check which text field is this. If it is one of the fields that should display a popover, first call [self.view endEditing:YES] to hide the keyboard, then present the popover and return NO. This way the text field won't take first responder status and the keyboard will not appear again. And if it is one of the "normal" text fields, just return YES.
I know it's a very long shot and the problem description is vague at best, but I'm hoping someone might have encountered that as well.
I have a UIViewController subclass that is being presented modally. The view of the controller contains some UIButtons and some UITextFields. The view controller might be presented multiple times during a user session; it is created every time it's presented and gets destroyed when it's dismissed. Most of the time everything works as expected, however, sometimes the text fields don't respond to user touch, i.e. tapping them does not bring up the keyboard. The buttons on the view work fine, it's just the text fields that become disabled.
What could possibly be causing this?
Turns out the reason UITextFields inside a modally presented view controller were not responding was that one of the long-living view controllers in the app called [self becomeFirstResponder] on itself, but never called [self resignFirstResponder]. It had to be the first responder in order for it to receive remote controls events when the app was playing music.