One thing you quickly realise after deploying your app is there are a number of places where the appearance of the keyboard makes the app almost unusable. For example I have a View with a TextArea that occupies the lower third of the View and, as soon as the user taps on it, the entire View moves up and pushes the navigation bar off the View. I have another View with a custom UITableView control that allows inline editing and, if the editable row is towards the bottom of the View, tapping it will display the keyboard without scrolling the View and obscure the editable row!
I’d be interested to know how others are dealing with the keyboard…
[quote=179516:@Jason Tait]One thing you quickly realise after deploying your app is there are a number of places where the appearance of the keyboard makes the app almost unusable. For example I have a View with a TextArea that occupies the lower third of the View and, as soon as the user taps on it, the entire View moves up and pushes the navigation bar off the View. I have another View with a custom UITableView control that allows inline editing and, if the editable row is towards the bottom of the View, tapping it will display the keyboard without scrolling the View and obscure the editable row!
I’d be interested to know how others are dealing with the keyboard…[/quote]
I remember writing not long ago that because of the keyboard, the iPhone quickly looked like a Blackberry’s small screen, and the iPad from all it’s 10" screen ended up with a 5" screen. On the app I am currently designing for Windows tablet the same issues present, although I devised my own virtual keyboard that is a bit less bulky than the iPad one.
I have a screen with a listbox and inline editing pretty much the same way. When the physical keyboard is plugged in, the table goes down to the bottom of the screen. When the on screen keyboard is here, I push up the table, and make it shorter. I believe you can do that with the constraints by naming the Top constraint as well as the height one and modifying them when the keyboard is present. I never tested the XojoiOSWrapper isFirstResponder with UITableView, but if need be, the guru who created the UITableView can probably add it.
Incidentally, what I found out is that sometimes tablets can have keyboards, and then they do not display the virtual one, making it necessary to have a design to accommodate that. From what I see on my iPad, when I use the BlueTooth keyboard, it does not display the virtual one. Then isFirstResponder does not suffice. One has to check when an editable control gets focus that a physical keyboard is not there before pushing up the view or modifying the height of the table.
It seems as though the best solution is in the third answer from the top (the one with the tick), which is that it’s automatic if you have the UITableView in the right place in the view hierarchy.
Did you experiment with UIScrollView’s keyboardDismissMode? This should be fairly easy to implement:
[quote]UIScrollViewKeyboardDismissModeNone
The keyboard does not get dismissed with a drag.
Available in iOS 7.0 and later.
UIScrollViewKeyboardDismissModeOnDrag
The keyboard is dismissed when a drag begins.
Available in iOS 7.0 and later.
UIScrollViewKeyboardDismissModeInteractive
The keyboard follows the dragging touch offscreen, and can be pulled upward again to cancel the dismiss.
Thanks Ulrich. But I don’t want to dismiss the keyboard. In my first example (the TextArea), the user has tapped the TextArea to enter text so they need the keyboard. The problem is that they then can’t navigate off the view because the navigation bar has scrolled off screen and, even though I could programmatically dismiss the keyboard, I don’t know when they might want to finish entering text so I can’t do this. In my second example (UITableView) the user has tapped in a cell of the UITableView to enter text so they need the keyboard, but the problem is that the keyboard obscures the cell because the UITableView does not scroll up when the keyboard appears.
Oh, I see, thanks, Jason. Yes, so I go with you two: This looks like a case for a delegate or a custom control. The current implementation of a tableview doesn’t fire a touchesShouldBegin event, or did I miss it?
It doesn’t implement most things The only way to gain functionality like this will be to recreate the view controller, table view, datasource, delegates, and custom cells necessary. And the custom cells should be made completely in code since we can’t make container views. Not a small task.
Ah yes, I do remember playing with the tableview properties and finding out that colors do not stick to cells because the hidden template is being reused for faster drawing and all that stuff. No, this isn’t just a weekend project.
Thanks Jean-Paul and I was just about to post that you’ve also solved the issue with the custom UITableView control by using your dtEvents control to fire an event when the iOS keyboard is shown or hidden.
At the risk of sounding like an advertisement, if you haven’t already taken a look at Jean-Paul’s controls you really should; the ListView alone is worth the price of admission!
The only way to gain functionality like this will be to recreate the view controller, table view, datasource, delegates, and custom cells necessary. And the custom cells should be made completely in code since we can’t make container views. Not a small task.