I would like to know if there is a way to keep UIKeyboard up while reloading section in UITableView? I have UITextField inside a header view of UITableView's section. Typing into this UITextField fires action that requires a section to be updated (reloaded).
As a result of calling [tableView reloadSections:...] the keyboard hides itself, because UITextField loses it's firstResponder status.
I would like to achieve similar effect like when using UISearchBar component in UITableView.
Thanks!
If you reload, everything will get refreshed. When that happens, the current first responder is resigned and the keyboard is animated out. To avoid that you need to no reload...
You would need to update the visible cells directly and use insertRowsAtIndexPaths:withRowAnimation: and deleteRowsAtIndexPaths:withRowAnimation: to make changes to the number of rows the table is managing. In this way the section won't be reloaded and you will avoid any cell animations / refreshing of views.
Related
I have UITableView in a ViewController (not a UITableViewController) with UITextFields in each row. I would like the TableView to automatically scroll so that the row below the row being edited is always displayed. This allows the user to tap the next row to edit it. The built in iOS Reminders app has this behaviour.
I have followed Apple's advice on managing the keyboard but that only scrolls to show the row you are editing just above the keyboard, not the row below it.
I have tried adjusting the frame in scrollRectToVisible: but it makes no difference. In fact commenting out that line of code seems to have no effect at all.
It seems that the UITableView will always try to scroll to show the UITextfield being edited just above the keyboard, and I can't find a way of adjusting or overriding this behaviour so that it shows the row below it also.
Update:
I've found that the automatic scrolling behaviour can be prevented by overriding the private scrollTextFieldToVisible method of UITextField.
However, the automatic scrolling code provided by Apple in the linked documentation still does not work.
You can try setting setContentOffset property instead of scrollRectToVisible. like
[self->_scrollView setContentOffset:CGPointMake(0, textFieldRect.origin.y)];
Please follow the below link, it will make your work very easy.
Just add the files and make the tableview class name as "TPKeyboardAvoidingTableView"
https://github.com/michaeltyson/TPKeyboardAvoiding
I have a UICollectionView with a header, some cells and a footer supplementary views. The header contains a UISearchBar. If I type something into the search field, the keyboard automatically dismisses after the first letter. I think it is caused by my -searchBar:textDidChange:, which contains code for refreshing the collection view (via -reloadData, because this is the only method I know which works).
My theory is, that reloading the UICollectionView causes it to become first responder, but that somehow does not work.
I have this line in my output every time the keyboard dismisses:
setting the first responder view of the collection view but we don't know its type (cell/header/footer)
I attempted to overwrite UICollectionView's -canBecomefirstResponder, but unfortunately that didn't work.
Any ideas how can I prevent UICollectionView to become the first responder after the reload?
I've had luck restoring the search bar as the first responder after updating the table view:
collectionView.reloadData()
searchBar.becomeFirstResponder()
In a UITableView where the cells contain UITextField objects, does having one of those UITextField objects be the first responder prevent its cell from being re-used?
For example, with a UITableView that has more rows than will fit on the screen, one can tap on a UITextField to bring up the keyboard for the field in that cell. Then scroll the table view to make that cell go off screen. When scrolling back to the cell, I can see calls to -tableView:cellForRowAtIndexPath: for all the cells, except the one that contains the UITextField that currently has first responder status.
This behavior leads me to believe that iOS is aware that my cell contains the first responder and thus chooses not to discard the cell, thus not needing to call the data source to get the cell when it scrolls back into view.
This behavior is desirable, but I am concerned because I have not seen any documentation that indicates that this behavior is guaranteed, and I would hate to rely on it if there are conditions where it isn't true.
Can anyone point me at some documentation about table view cell re-use and first responders that covers this situation?
There is no such reference in the official iOS SDK documentation. You are correct to be concerned that this behavior you are observing is not guaranteed and should not be relied upon.
Maybe I'm missing something obvious, but I'm have a hard time programmatically setting the row selection in a tableView. The goal is to simply have a tableView open with a row already selected. The problem appears to be that I have to wait until the tableView is fully loaded before I can modify the selection.
I've read various strategies such as calling reloadData for the tableView in the viewController's viewWillAppear method, then immediately calling selectRowAtIndexPath for the target row. But when I do that, I get a range exception because the tableView has zero rows at that point. The UITableViewDelegate methods (numberOfRowsInSection, etc.) don't appear to be called immediately in response to reloadData (which makes sense if the table rows are drawn "lazily").
The only way I've been able to get this to work is to call selectRowAtIndexPath after a short delay, but then you can see the tableView scroll the selected row into view.
Surely, there's a better way of doing this?
Well, you can use another strategy. You can create a hidden table view, configure how you want and than show to user. Use the tableview.hidden = YES.
I have a UITableViewController, a bunch of sections and rows, and for each row I added a UITextField as a subview, right aligned in the row itself.
If the users taps on the row, I locally save the indexPath, make the corresponding text field become the first responder and finally, when the keyboard appears, I make the table view scroll so that the row remains visible.
I am facing the problem to obtain the same behaviour when the user taps the text field instead. In this case the didSelectRowAtIndexPath: method isn't called, so I do not know how to tell the table view to scroll to make sure that the "selected" row is still visible.
Probably the whole process is not correct. Do you know a way to solve it?
Thanks a lot!
I'm not absolutely sure about this, but...
Set the userInteractionEnabled property of the UITextField to NO. This way, the touch goes "through" the control, tapping the UITableViewCell. When didSelectRowAtIndexPath: is called, set the userInteractionEnabled property of the UITextField to YES. When the editing is complete, change it back to NO.