12 Weeks as an iOS Developer Apprentice
Week Nine
Rolling right along into the second week on the client project. Tackling the good ol’ UITextField and its compadre the UIKeyboard. Like peanut butter and jelly, rice and beans, Donald Trump and a bad, bad taste in your mouth- you really can’t have one without the other.
Many devs have had to tackle the problem of the keyboard coming up and covering the very text field it was meant to be of use to.
That’s why there are many libraries available to help solve the problem. (Here’s a nice one)
Even so, you may need to customize one some day. Or maybe you’re just curious to know how it works under the hood. Here’s what I learned this week when putting together a keyboard manager from scratch…
First, we wanted to make sure the keyboard popped up right away without the user tapping in the text field in order for it to come up.
This is actually a job for the text field itself. The text field must become the “first responder”.
Drop this in your viewDidLoad or viewWillAppear accordingly and the keyboard will slide up when the view is shown.
This actually doesn’t cover up the text field on the iPhone6, but it’s definitely not working for us on the 4 or the 5. On all devices, the Next button is completely covered by the keyboard.
Let’s move the next button to the top of the keyboard when it rises and bring it back down when the keyboard drops.
In order to grab the height of the keyboard, we’ll have to set up our view controller to listen to notifications from the window and let us know when the keyboard has been shown and hidden.
Using NSNotificationCenter, we can register two different methods to be called when we receive either a UIKeyboardWillShowNotification or UIKeyboardWillHideNotification from the window.
Note that each notification includes a “userInfo dictionary containing the beginning and ending keyboard frame in screen coordinates”
So we’ll grab that keyboard height in the methods we’ve registered to be called when we receive notifications.
Now we just have to adjust the constraints of the pieces of our layout that are affected by the keyboard height.
Start with the Next button’s bottom constraint. It’s set in the storyboard to be constrained to the superview without any padding. The constraint’s constant is zero.
Make an outlet from the constraint in the storyboard to the view controller.
With an outlet to the constraint, we can now change the constraint’s constant to the height of the keyboard and make the Next button appear to be sitting on top of the keyboard.
Then we can bring it back down again when the keyboard is hidden by making the constant zero again.
Let’s also make the keyboard respond to tapping in the text field rather than sliding up when the view is shown.
Change .becomeFirstResponder() to .canBecomeFirstResponder()
And since we’re asking for the user’s email address, let’s give them the appropriate keyboard by setting the text field’s UIKeyboardType.
Here’s our results on the iPhone 6:
Looking good!
But here’s our results on the iPhone 4:
The Next button is moving with the keyboard, but it still covers the text field. We can fix this by adding more outlets to constraints and adjusting them according to the device’s screen size.
Our To-Do list:
- Adjust the size of the email icon
- Move the text field up above the next button
- Give everything a nice bouncy touch
First, let’s find out which size device is being used. We can easily do this by calculating the window’s screen height. Let’s create a struct to handle this.
Once we’ve made all the appropriate outlets to the constraints we want to manipulate, we can animate the transition.
Lines 4–11 and 19–21 make use of the outlets to our constraints and our DeviceManager.
And here’s what’s happening in the pulseAnimation()
We make use of CGAffineTransformMakeScale to quickly make all of our elements get a little bigger than a little smaller for a pulsing effect.
Lastly, a couple of extras for the final touch…
Add a UITapGestureRecognizer so the user can tap anywhere on the screen to dismiss the keyboard.
And because we have our next button, we could also hide the return button on the keyboard by changing the UIKeyboardType to .Twitter
Results
The iPhone 4:
The 5:
And the 6:
View the entire example on GitHub.
See? No need to go back in time and make keyboards great again. They’ve already become pretty freakin awesome. Like puppies.
Just keep moving onward and upward from here.
