Resignfirstresponder VS. Endediting for Keyboard Dismissal

resignFirstResponder vs. endEditing for Keyboard Dismissal

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.

To dismiss keyboard is there any difference between using `resignFirstResponder` and `endEditing`?]

self.view.endEditing(true) is less efficient because it will cycle through the entire view hierarchy and makes sure anything that can be a firstRepsonder has resigned it.

If you know which item is currently the responder, it is more efficient and better practice to call resignFirstResponder on it directly.

iOS hiding keyboard on Return press, resignFirstResponder vs endEditing

In this case, it doesn't really matter which you use though technically, using textField.resignFirstResponder() is more efficient because you already know that is the text field you need to resign.

The call to self.view.endEditing(true) is going to have to figure out what the current first responder is and then call resignFirstResponder on it.

My general rule of thumb is to use resignFirstResponder if you have a reference to a specific view you wish to resign. And use endEditing if you don't and you just want the current first responder to be resigned.

On a side note, you should return false from textFieldShouldReturn in either case. There is an edge case where returning true can lead to a newline being added to a UITextView after resigning the UITextField. So as a rule I always return false.

Performance of -endEditing vs conditionals in dismissing keyboard

I ran a performance test tonight on the difference between these two methods of resigning the first responder.

For the first test, I allocated and initialized 4000 UITextFields and added them as subviews to the main view in a UIViewController. I then made one of the UITextFields a firstResponder, then took the current NSDate. I then called [self.view endEditing:YES]; and took another current NSDate. I took the time interval between the start and end dates, and got a difference in seconds of: 0.000029.

In the second test, I allocated one UITextField, set it as the first responder. I then performed the same NSDate calculation, but used an if statement to check and see if the UITextField was currently a firstResponder, and then called -resignFirstResponder if it was, indeed, the first responder. The time difference (in seconds) for this was: 0.000012.

Both of these tests were ran on-device on an iPhone 5s.

So, what we're measuring here is how long the main thread is being blocked (which would cause a laggy feeling app). Still, it's pretty amazing to see that using -resignFirstResponder with a test to see if the textField is a first responder is only .000017 faster than just calling -endEditing:YES on the main view. What this shows though is that the performance difference between these two methods of relinquishing first responder status is really negligible.

I wonder what Apple is doing behind the scenes there?

How do you dismiss the keyboard when editing a UITextField

I set the delegate of the UITextField to my ViewController class.

In that class I implemented this method as following:

- (BOOL)textFieldShouldReturn:(UITextField *)textField {
    [textField resignFirstResponder];
    return NO;
}

Why call method to resignFirstResponder from textFieldShouldBeginEditing?

In the examples you cite, the textField is being used to display a date. When the user selects this field, the app designers want the UIDatePicker to be displayed instead of the keyboard. Hence they call resignFirstResponder to hide the keyboard. At the same time, they display the date picker.

ResignFirstResponder will not hide the date picker, so the "input device" (for this field) will still be available.

Also, note that in one case the developer has used textFieldShouldBeginEditing, and returns false because they are providing the date picker. In the other case the developer uses textFieldDidBeginEditing (which has no return value).

---

Related Topics