In Swift, both [someTextField].resignFirstResponder() and self.view.endEditing(true) accomplish the same task - hiding the keyboard from the user's view and de-focusing whatever text field was using it. I understand that the former is specific to a particular field, while the latter encompasses the entire view, but other than wanting to target a specific text field, when is one preferred/recommended over the other?
someTextField.resignFirstResponder()
resignFirstResponder() is good to use any time you know exactly which text field is the first responder and you want to resign its first responder status. This can be slightly more efficient then the alternative, but if you're doing something such as creating a custom control, this can make plenty of sense. Perhaps you have a text field, and when the "Next" button is pressed, you want to get rid of the keyboard and present a date picker, for example. Here, I would definitely use resignFirstResponder()
self.view.endEditing(true)
I typically reserve this for scenarios when I just absolutely need to clear the keyboard no matter what is currently going on, for whatever reason. Perhaps, I've got a slide-over menu? Just before this slides out, no matter what is going on, the keyboard should go away, so I'll make sure everything resigns its first responder status. It's important to note that endEditing() will look through the entire hierarchy of subviews and make sure whatever is the first responder resigns its status. This makes it less efficient then calling resignFirstResponder() if you already have a concrete reference to the first responder, but if not, it's easier than finding that view and having it resign.
There is no such strict rule.
You use resignFirstResponder when you have the reference of the text field currently holding first responder status. When you don't have the reference or you are unsure about that, endEditing would do the trick.
One thing however should be noted that endEditing has a boolean parameter that we occasionally set to true. By setting this parameter to true the view, on which endEditing has been called, will force every child text field to resign first responder status irrespective of it has returned a false value from textFieldShouldEndEditing delegate method. On the contrary calling endEditing with false would only ask (not force) the text field to resign, respecting the return value from textFieldShouldEndEditing protocol method.
Related
I'm working on a custom keyboard for iOS which will have its own search field (similarly implemented by PopKey).
My keyboard's textfield is able to take the focus with becomeFirstResponder and I'm able to give it up by using resignFirstResponder. However after I resign focus, the host app has a difficult time retaking focus despite touching the form. The app's textfield will still show the text cursor blinking.
Any ideas? Thanks
The solution is a hack, as of right now you can't really give the host app its focus back.
Subclass a UITextField and on its delegate implement
textFieldShouldBeginEditing by returning NO.
Add a BOOL property isSelected that gets set to YES in touchesBegan (not to be confused with the default selected property)
In your keyboard's keyPressed method, if searchField.isSelected, manipulate the searchField.text. Else, manipulate textDocumentProxy like normal.
Add a clear button and method that wipes searchField.text and searchField.isSelected, allowing any further keystrokes to return to the textDocumentProxy
Add an animation that replicates the blinking type cursor
I'm writing a keyboard extension for iOS (hence overriding UIInputViewController) and I'm trying to figure out how to detect when the first responder changes. Is this even possible?
My motivation is that when the user selects a different text input field (while the keyboard is active) the style of the keyboard might need to change to suit the attributes of that input. This can happen when there are several text fields displayed on a UI and the user first selects one (causing the keyboard to be initialized) then the user selects another with different attributes (keyboard doesn't know it).
I've looked through the methods exposed by UIInputViewController and the delegates it implements but nothing I've seen really fits the bill. The closest thing I've found is selectionDidChange on UITextInputDelegate.
I found the best way to get this information is to override the UITextInputDelegate textDidChange method (UIInputViewController implements UITextInputDelegate). It turns out that textDidChange is called whenever the user switches the input text field (first responder), or when the text changes for some reason (luckily not when it is your keyboard that initiated the change).
-(BOOL)textFieldShouldBeginEditing:(UITextField *)textField
That should tell you when it expects to become firstResponder. A couple things to keep in mind;
*This will only be called when a UITextFied is the thing becoming firstResponder. If some other object decides to, this won't be called. It'll probably call the method below.
-(BOOL)becomeFirstResponder
*Your class must conform to the UITextFieldDelegate and all of your UITextFields must set their delegates to self. Without that they won't call shouldBeginEditing on your class.
I've got a form with some UITextField instances, and I've set up an accessory view to flip back and forth between them as you fill in the form. The ugliness is that the keyboard slides away, then immediately slides back for the next form.
Since it's going to remain there, is there a way to get it to simply stay up throughout the whole form, rather than this ugly/silly gone/back behaviour? I may be doing something wrong programmatically, I'm telling fields to resignFirstResponder before the new one does becomeFirstResponder – is that the cause?
You don't need to called resignFirstResponder when switching between text fields, iOS will handle this for you when calling becomeFirstResponder on another object. You just need to call resignFirstResponder if/when you want to hide the keyboard, say at the end of the form.
Yes, that is the cause. You can just call becomeFirstResponder without calling resignFirstResponder and you'll get what you want
When you select other UITextField than automatically the last UITextField resign first responder so you should not resignFirstResponder every time. Just resign when you done with UITextField or user click on the UIView.
I have view with a text field, an image and a few buttons.
I want to make sure the keyboard is displayed and is on top when the view is displayed
AND
I want to make sure it doesn't go away after I type something in to the text field and submit it.
I called [txtField becomeFirstResponder] with viewdidload and the keyboard is appearing by default but with a tiny delay after the view is displayed.
Also the becomefirstresponder doesn't help after I have my text field submitted.
Thanks in advance for your help!
Also the becomefirstresponder doesn't help after I have my text field submitted.
That part makes no sense. By default, a text field does not dismiss the keyboard unless you dismiss it with endEditing: or resignFirstResponder. If the keyboard is going away, you must be making it go away. So don't and it won't.
EDIT: And indeed, your comment later reveals the answer: you've hooked up the didEndOnExit control event from the text field. Well, that causes the keyboard to be dismissed when the user presses the Done button! So you are effectively hitting yourself in the face and then complaining that someone is hitting you in the face.
So the solution, obviously, is don't hook up the didEndOnExit control event (to anything). Instead, just give the text field a delegate and use the delegate messages to learn what the user is doing. None of those have any automatic behavior with regard to the keyboard, so the keyboard won't be dismissed automatically. For example, to learn when the user is typing, use textField:shouldChangeCharactersInRange:replacementString:. To learn when the user has hit the Done button, use textFieldShouldReturn:. And so on.
My app basically lets you send a piece of text. When the user taps send, I would like to disable the text view which contains the text so the user can't edit it anymore as the text is being sent. It seems though that setting either enableUserInteraction or editable to NO always resigns the first responder (basically the keyboard is dismissed) which is a behavior I don't want. I want to keep the keyboard displayed. Is there anyway around this? Thanks in advance.
While I don't really understand why you think it's a good idea to keep the keyboard on screen if there's nothing to edit, you can achieve this by having a hidden UITextField and making that first responder.
If the UITextView's delegate method textView:shouldChangeTextInRange:replacementText: returns NO, its contents will not be changed.