I am troubleshooting a strange behaviour of a UITextField in my app.
During editing the above textField, if the app goes to the background and comes back to the foreground, the keyboard disappears. I have kept breakpoints at all places where the resignFirstResponder is getting called. But, I am unable to find the cause of the disappearing keyboard.
Is there any instance when the keyboard will be dismissed without specifying resignFirstResponder explicitly in code?
What is the expected standard behaviour in the above case?
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'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.
I have a UISearchBar which is an IBOutlet. Tapping on the search bar or calling [searchBar becomeFirstResponder] in viewDidAppear results in a few seconds delay where the UI is locked before the keyboard appears.
I've looked at this in Instruments, and there is a CPU usage spike when becomeFirstResponder is called, but I'm not sure how I can narrow this down to a method / bunch of methods within the spike.
The view controller is not doing anything blocking, and there is nothing else running on the main thread (as far as I can see). This only happens the first time after calling becomeFirstResponder or tapping on the search bar. It does not happen again once the keyboard has been dismissed.
Any help would be much appreciated, as I can't see what's wrong really.
This is all running on iOS7, on iPhone and iPad BTW.
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.