I have some simple code that moves the 'firstResponder' between UITextFields by calling 'becomeFirstResponder' on each field in turn.
In iOS 5, the keyboard is shown as constantly, until the final textfield where resignFirstResponder is shown.
However, in iOS 6, the keyboard performs the dismiss and reappear animation each time the first responder is moved. At no point do I call resignFirstResponder when calling becomeFirstResponder to move the responder (or in any of the associated methods) - it just seems to be new default behaviour in iOS 6.
This is distracting, and unwanted.
I've looked through the Apple documentation, and can't find any mention of a change to how the keyboard animation is managed.
Can anyone refer me to documentation of these changes? Thanks.
Found the problem.
My code was also calling,
[self.tableView reloadData];
...when calling becomeFirstResponder.
Therefore, the keyboard was being dismissed while the redraw occurred.
This certainly seems to cause different keyboard behaviour between iOS 5 & 6. Though the behaviour in 6 doesn't seem wholly unreasonable, considering.
Thanks to #Fogmeister for the help.
Related
I've recently discovered a problem in my app that only seems to occur in iOS 10 where the system keyboard does not display when programmatically triggering a text field to become first responder inside of a completion handler -- specifically the completion handler I get back from a Touch ID attempt.
The crazy part of this issue is, even though the keyboard is not shown, the area on the iPhone where the keyboard normally would be is still responding to touch inputs as if the user is typing on the keyboard!
After doing a lot of investigation and debugging into the issue, I stumbled across the fact that the hidden property is set to YES on the private UIRemoteKeyboardWindow that gets created after becomeFirstResponder is invoked on the text field. In other situations where I bring up the keyboard, the value of that hidden property is set to NO.
Has anybody else run into this problem in iOS 10? If so, anybody found a solution to this? I tried manually setting the hidden value to YES on the window instance but that had no effect on it. I'm pretty much grasping at straws at this point.
Attachments:
Here's the output of the windows from the UIApplication instance when the text field becomes first responder outside of the Touch ID completion handler (pay close attention to UIRemoteKeyboardWindow):
And when the UITextField becomes the first responder inside the Touch ID handler...
First Update
So I did not consider the becomeFirstResponder being done on the main thread before that some have pointed out, but unfortunately, it did not resolve the issue -- however, I did make some additional discoveries. The hidden window issue seems to stem from outputting the details of the UIApplication instance's windows immediately after issuing the becomeFirstResponder action. After doing that, I set a breakpoint on the UITextField editing callback and proceed to interact with the keyboard (that is invisible) -- and when I output the window details, it doesn't seem like the hidden property is ever set to YES (which can possibly rule out that property being set as the cause of the issue), but I still have an invisible keyboard! I started debugging the view hierarchy and below is a screenshot of what it looks like when I examine the keyboard window:
Hopefully you guys can see what I discovered here which is that the keys are present but there appears to be some white view blocking them from sight. The thing is, I don't even see those white views on my app screen. I just see what normally sits behind the keyboard when it's present.
As a temporary workaround, call becomeFirstResponder after a delay fixed this, however, not happy with the hacky solution.
Looks like the issue occurring for different scenarios too - keyboard could be invisible even if you are selecting the textField manually after cancelling touchId alert.
I've had a crash report, it's a real edge case. I launch a pin security view from applicationWillEnterForeground (the feature is optional). However, I have some form sheets which I use in some situations in my app.
So the pin view is added as a subview on window and a keypad is presented.
When the form sheet is showing, it appears on top of the pin view (which is wrong) and an action on the form sheet causes a crash, when showing another keypad.
So I believe I need to dismiss any form sheets if the application resigns / becomes active.
I've looked into sending a notification to the form sheet in applicationWillEnterForeground, however I'll have to firstly determine if a form sheet is visible then add method to dismiss it every form sheet.
This seems a lot of work for an edge case, can anyone suggest an alternative approach?
For completeness here's the error...
The layout constraints still need update after sending -updateConstraints to <_UIKeyboardLayoutAlignmentView: 0x14e59b790; frame = (0 0; 0 0); userInteractionEnabled = NO; layer = >. _UIKeyboardLayoutAlignmentView or one of its superclasses may have overridden -updateConstraints without calling super. Or, something may have dirtied layout constraints in the middle of updating them. Both are programming errors.
I've seen this...
NSInteralInconsistencyException - UIKeyboardLayoutAlignmentView
However, I'd still need to end editing in various form sheets, which I can't access from applicationWillEnterForeground.
OK, after researching the issue I discovered that I needed to observe the application state. On notification then check if various objects are load and if so, resignFirstResponder when the keyboard is shown (aka is editing) (I had a text field in an UIAlertView), dismiss an UIAlertView and then dismiss in the view controller used in dialog.
Shesh... so not as simple as I was hoping.
Although this is an edge case for me, I figured I should fix it.
I also found this which will dissmiss alertviews https://github.com/sdarlington/WSLViewAutoDismiss
Which will save me a lot of hassle in simpler scenarios.
Apparently since iOS4, Apple recommends cancelling UIAlertViews and UIActionSheets when an application becomes active.
I have a custom inputView for a particular textfield, and it works well. However, I cannot discern how to dismiss the view and get the regular keyboard back. (I have a SWAP button right next to the TextField.) I tried setting the textfield's inputView to nil, but that did nothing.
I do not need a full custom keyboard, but I need more than an Accessory view above the keyboard, which is why I am trying this route. I need about 20 custom buttons in addition to the regular keyboard, and I do not like the idea of a huge Accessory view taking up so much space.
I also would rather not require the user to initially install a full custom keyboard before being able to use the app.
Thank you very much for any suggestions.
I think you will probably have to do this:
Call resignFirstResponder on the UITextField
After the animation finishes, set your inputView to nil
Call becomeFirstResponder on the text field
The keyboard animation duration is sent in the userInfo dictionary on the keyboard presentation notifications.
In addition to the accepted answer, you can use reloadInputViews() (and this is less likely to suffer any animation glitches resulting from the resignFirstResponder, becomeFirstResponder calls):
yourTextField.inputView = nil;
yourTextField.reloadInputViews();
Here's more info in the Apple's Docs.
I have a UITableview that doesn't take up the whole screen (screenshot). Everything worked fine in iOS 6. But in iOS 7, when the user searches, the search result table takes up the whole view (screenshot).
To fix this, I tried setting the frame manually as described in this answer. The appearance is now correct (screenshot), but now the "<" button in the top left doesn't receive tap events when the search results table is displayed.
It seems the searchResultsTableView is adding a full-screen background view that is intercepting touch events. To prove this, I added this code to didShowSearchResultsTableView:
controller.searchResultsTableView.superview.backgroundColor = [UIColor blueColor];`
This screenshot confirms my hypothesis.
How can I fix this to allow the "<" button to receive tap events?
I want to avoid modifying controller.searchResultsTableView.superview so that my change doesn't break in future versions of iOS.
And what change in iOS 7 caused this behavior to start happening?
I am still searching for a better solution, but currently my solution is in the viewControllers viewDidLayoutSubviews tell your view to move to front. The code would look something like this.
- (void)viewDidLayoutSubviews {
[super viewDidLayoutSubviews];
[self.view bringSubviewToFront:self.navigationBar];
}
My app uses a UITableView with a UINavigationController to show a more detailed view when a row of the table is tapped - the basic drill-down routine.
When I tap on a row, it is highlighted, but the delegate methods tableView:willSelectRowAtIndexPath: or tableView:didSelectRowAtIndexPath: are not called (verified using debugger).
Now here's the weird part:
There are some other table views in the app (they don't drill down) and none of them exhibit the issue.
If I tap the row rapidly and repeatedly, after many tries (10 - 20 is normal), tableView:willSelectRowAtIndexPath: and tableView:didSelectRowAtIndexPath: are called and processing continues normally.
The problem occurs only on an (any, actually) iPad running iOS 6. It works fine with iPads running iOS 5, or with any iPhone running any iOS version, 6. It also works with the iPad simulator using iOS 5 or 6.
So it seems that something is receiving the tap before the delegate methods are called. But what?
I not using any UITapGestureRecognizer, so that is not the issue.
I am not using multiple UITableViewControllers for the table, so this is also not the issue.
I was having this issue with an app when running in iOS6. The tableView:didSelectRowAtIndexPath: method was never being triggered, even though it was working before updating to iOS6.
I finally figured it out by looking at the xib and the attribute inspector for the table. In the Table View section I had the Selection option set to No Selection and Show Selection on Touch was not selected.
Changing the Selection option to Single Selection actually got this working for me again and leaving the Show Selection on Touch unselected means that I don't see any flash or change of colour when the row is selected.
I encountered a similar issue. iOS 6 appears to be much more sensitive to the slightest upward movement on a tap on a table view cell. It appears it is registering the slightest movement as a scroll request rather than a cell selection. My table view was set to scrollEnabled = NO because it is a table view with static selection values. The table view appears within a small area of a larger iPad view. If I carefully tap a cell and lift directly up, the cell is selected.
To resolve it, I changed scrollEnabled to YES and made sure the area dedicated to my tableView was larger than the actual area needed to show the table view, thus preventing it from scrolling. Not sure if this is is the cause of the issue you are experiencing, but hope it helps.
I had the same problem. The UITableView was not triggering the didSelectRowAtIndexPath method when running in iOS6, but it was working fine in iOS5.1.
I had also implemented the
- (BOOL)tableView:(UITableView *)tableView shouldHighlightRowAtIndexPath:(NSIndexPath *)indexPath{
return NO;
}
and returned NO. In iOS5 it was all working fine, but the minute I switched to iOS6 it would cease to trigger the didSelectRowAtIndexPath. Once I removed that shouldHighlightRow method, everything worked in iOS6 again. Cheers!
The usual reason that didSeletRowAtIndexPath() doesn't get called is having a UITapGestureRecognizer on your viewcontroller with Cancels touches in view set to YES.
The correct and only sensible fix is to set Cancels touches in view to NO. Then your table row selection should work nicely.
Obviously this has some implications in your gesture handlers - you may need to add some code to your gesture handler to stop some touches going on to your views i.e.
- (IBAction)onTapGesture:(UITapGestureRecognizer *)sender {
if (sender.view == someOldViewThatINeedToDealWith) {
sender.cancelsTouchesInView = true;
}
}
I tried all the other answers posted, and although they seemed promising, they didn't solve the problem.
I've since discovered the cause of problem in my case: I was calling [self.tableView reloadData] on a different thread (due to handling an NSNotification event posted from a background worker thread).
I fixed the problem by changing [self.tableView reloadData] to
[self.tableView performSelectorOnMainThread:#selector(reloadData) withObject:nil waitUntilDone:NO];
Hope this helps.
The other suspect could be a Tap Gesture Recognizer set to the view controller's view swallowing all taps like a blackhole. Remove the gesture recognizer will enable did select. I just had the same issue and the tap gesture was the cause.
The resolution is really weird: the UITableViewController registered for all notifications. In the handler for the notifications, the table view data was being reloaded using
[self.tableView reloadData]
According to Apple DTS, when the table reloads data, this causes a notification to be sent to the observer, causing a race condition ...
No explanation for why it would work sometimes or why it would always work on an iPhone. But registering only for a small subset of notifications (i.e. the ones I was really interested in) fixed the problem!
Setting
recognizer.cancelsTouchesInView = NO;
takes care of it if your use case allows simultaneous handling
of touches by [tap] gesture recognizer (kdb dismiss for example)
and the view the recognizer is attached to.
in my case I hade button which received all touch events before tableviewcell