By returning our own views from these properties we can replace the system keyboards with any custom UIView we care to construct. UIResponder gives us two read-only properties for controlling the keyboard’s appearance inputView which provides the keyboard itself and inputAccessoryView which controls the accessory view attached to the top of the keyboard (containing the “next” and “previous” buttons when editing a form in Mobile Safari for example). (If this isn’t a familiar topic then take a look at “Responder Objects and the Responder Chain” in the “Event Handling Guide for iOS” for a full discussion of how the system works.) Whenever a responder becomes the first responder (see -becomeFirstResponer) it determines what, if any, keyboard needs to be shown. All of the responder objects in our views form a responder chain, a sequence of objects which will be given a chance to respond to non-touch input events. Traversing up the class hierarchy we see that UITextField, UITextView, and indeed all UIView objects inherit from UIResponer. That’s a good place to start customizing our keyboard options but UITextInputTraits itself doesn’t present the keyboard so when we need behavior the protocol doesn’t provide we will have to keep looking.
Those options cover many of the types of text input we might want to support plain text, passwords, email addresses, urls, and so on. Both provide conform to the UITextInputTraits protocol which gives us options to set the keyboard type, return key type, keyboard appearance, and other behaviors. Our first exposure to different keyboard types probably comes from UITextField and UITextView. When we find that we really wish the keyboard had some extra controls or want to help our users enter a specific set of symbols it is time to customize our apps’ keyboards. Our applications need input and the default iOS keyboards are often not optimally suited to providing the sort of data we want.
0 kommentar(er)
