0

I do understand how to go about making the UIKeyboard push up the UIView if the active UITextView is blocked by the UIKeyboard as per this question: How to make a UITextField move up when keyboard is present?.

What I'm wondering is, from a design perspective, how do you go about implementing the keyboardDidShow and keyboardDidHide methods so that all of the views in your app, whether they be a UIView, UITableView, or UIScrollView all have this functionality and so you need to implement these methods only once?

The only way I could think of would be to have the view property of the UIViewController always set to a UIView, and if you have a UIViewController that needs a UIScrollView or UITableView, just attach it as a subview to this. Then if the UITextView is being blocked, just move the parent UIView up so it will move all of the views that are attached to it.

Does this sound like a good plan, or is it even worth it? Anyone else have any other ideas?

Community
  • 1
  • 1
Ser Pounce
  • 14,196
  • 18
  • 84
  • 169
  • It would be possible to do that, and if thats the behavior you want, then by all means do it. However, you might want to consider each case separately. I don't imagine your app is flooded with sooo many blocked text fields that you can't/wouldn't want to provide custom functionality in each case to make everything look its best. It only takes a few lines of code to move a view. That said, based on what you're implementing, try and find a balance between consolidated code and customized layouts. – Matt Jun 06 '12 at 23:26
  • Thanks for the response. You said providing custom functionality to make everything "look its best" but wouldn't everything look fine in this instance? – Ser Pounce Jun 06 '12 at 23:35
  • It's a matter of opinion. In some cases, a single/group of controls animating up with the keyboard looks better (IMO) than the whole view (background, whatever else you have in there) moving. Sometimes the former might be too tedious to implement to be practical, or maybe the content of the layout doesn't facilitate it. Technically, your idea would seem to look fine, but maybe it could look better given the views you are working with. – Matt Jun 06 '12 at 23:41

2 Answers2

2

This is a little old, but it's a great article about using firstResponder methods to tell views to slide up. I, personally, like to put my UITextField in a parent container and move it all up. However, I do NOT suggest putting everything in there and moving it all up, because the UITextField "feels" better just above the keyboard. But I do like the background or certain items to move up with the UITextField.

See below: http://cocoawithlove.com/2008/10/sliding-uitextfields-around-to-avoid.html

This is a nice implementation that moves the field up based on the section of the screen it's in (upper, middle, lower). Works very well. May need to be updated for newest SDK, but should be pretty easy.

Matt Hudson
  • 7,329
  • 5
  • 49
  • 66
0

In experimenting with this, I noticed that if you want to make a BaseViewController that implements this functionality to work for everything that inherits from it, you have to attach another view on top of the UIViewController's view property in order to get it to work. Reason is, if you push the UIViewController's view property up when the keyboard appears, then it resets itself if the app comes back from being active and it's messy.

The problem with this however, is now in all of your child classes you have to attach your subviews to this new view property instead of the regular view property. Also, you probably have to make a custom UITableViewController which will inherit from your BaseViewController class so it can inherit the keyboard notification methods.

Ultimately, I've found it's not the worst idea to have another view on top of the UIViewController's property for a bunch of different scenarios. Making a custom UITableViewController isn't that big of a deal either. So if you have a lot of text fields in your app, this might not be the worst way to go.

Ser Pounce
  • 14,196
  • 18
  • 84
  • 169