Vaya con iOS

ios 8 keyboard

It’s been over two years since I published my visual catalog of iOS’ virtual keyboards on the iPhone, which covered iOS 6. At the time, it was the only place you could get a listing of the names of the iOS keyboards and see what they looked like. Even now, I think it’s still the only information source of its kind.

We’re now well into iOS 8’s run, and it’s likely that iOS 9 will be released sometime this year. Since there still isn’t a visual catalog of iOS 8’s built-in keyboards on the iPhone, and since I’m still of the “see a need, fill a need” ethos, I put one together. It starts with a table listing all the built-in keyboard types; you can click on the name to jump to pictures of all the views for the corresponding keyboard.

I hope you find it useful!

iOS 8’s built-in virtual keyboards

UIKeyboardType Based on Emoji entry? The official description, straight from Apple’s documentation
ASCIICapable Typewriter No Use a keyboard that displays standard ASCII characters.
DecimalPad Phone No Use a keyboard with numbers and a decimal point.
Default Typewriter Yes Use the default keyboard for the current input method.
EmailAddress Typewriter Yes Use a keyboard optimized for specifying email addresses. This type features the “@”, “.” and space characters prominently.
NamePhonePad Typewriter and phone Yes Use a keypad designed for entering a person’s name or phone number. This keyboard type does not support auto-capitalization.
NumberPad Phone No Use a numeric keypad designed for PIN entry. This type features the numbers 0 through 9 prominently. This keyboard type does not support auto-capitalization.
NumbersAndPunctuation Typewriter No Use the numbers and punctuation keyboard.
PhonePad Phone No Use a keypad designed for entering telephone numbers. This type features the numbers 0 through 9 and the “*” and “#” characters prominently. This keyboard type does not support auto-capitalization.
Twitter Typewriter Yes Use a keyboard optimized for twitter text entry, with easy access to the @ and # characters.
URL Typewriter Yes Use a keyboard optimized for URL entry. This type features “.”, “/”, and “.com” prominently.
WebSearch Typewriter Yes Use a keyboard optimized for web search terms and URL entry. This type features the space and “.” characters prominently.

iOS 8 features a total of 11 built-in virtual keyboards, all of which are variations on two basic types: the typewriter keyboard and the phone keypad, both pictured below:

typewriter and phonepad - light

Typically, the keyboard isn’t shown until the user taps on a text field or text view. You can specify the type of keyboard for a text field or text view visually in Interface Builder…

choosing keyboards in interface builder

…or you can do so in code using the text field or text view’s keyboardType property and values from the UIKeyboardType enum:

If you don’t specify a keyboard type for a text field or text view, the typewriter-based Default keyboard is used.

Thanks to their growing popularity (first in Japan, and then the rest of the world), many of these keyboards feature a way to enter emoji, which have been available on iOS since version 5, which was released in mid-2011:

emoji-light

All of iOS’ virtual keyboards come in both a light and dark appearance, with the light version being the default:

typewriter and phonepad - dark

As with the keyboard type, you can choose this appearance either visually in Interface Builder (via the Appearance menu) and in code using the text field or text view’s keyboardAppearance property and values from the UIKeyboardAppearance enum.

I haven’t been able to find anything in the Human Interface Guidelines on when the light and dark keyboards should or shouldn’t be used, so let your common sense be your guide, keeping in mind this fact about common sense:

Click the image to enjoy Deadpool’s wisdom at full size.

UIKeyboardType.ASCIICapable

This used to be the default keyboard; now it’s the “no-nonsense alphanumeric keyboard”. It lets you enter letters, numbers, punctuation, and symbols, and nothing else. Use this keyboard if you need the user to enter something that’s completely or primarily letters and don’t want them to enter emoji and especially for data entry in business, productivity, scientific, health, and other “serious” apps.

Primary view (accessed via the ABC key):

ascii-1-light ascii-1-dark

Alternate view 1 (accessed via the 123 key):

ascii-2-light ascii-2-dark

Alternate view 2 (accessed via the #+= key):

ascii-3-light ascii-3-dark

UIKeyboardType.DecimalPad

Use this keyboard if you want the user to enter either whole or fractional numbers. This keyboard provides the decimal separator appropriate for the user’s locale; the screenshots below show my locale settings, English/US. Note that there’s no return key of any sort on this keyboard.

decimalpad-light decimalpad-dark

UIKeyboardType.Default

If you don’t specify the keyboard type, you get this one, which lets the user enter letters, numbers, punctuation and symbol characters, and emoji. This is the most general-purpose keyboard in iOS.

Primary view (accessed via the ABC key):

default-1-light default-1-dark

Alternate view 1 (accessed via the 123 key):

default-2-light default-2-dark

Alternate view 2 (accessed via the #+= key):

default-3-light default-3-dark

Alternate view 3 (accessed via the the 😀 key):

emoji-light emoji-dark

UIKeyboardType.EmailAddress

If you want the user to provide an email address, this is the preferred keyboard.

Primary view (accessed via the ABC key):

email-1-light email-1-dark

Alternate view 1 (accessed via the 123 key):

email-2-light email-2-dark

Alternate view 2 (accessed via the #+= key):

email-3-light email-3-dark

Alternate view 3 (accessed via the the 😀 key):

emoji-light emoji-dark

UIKeyboardType.NamePhonePad

For fields where you want the user to enter data without punctuation — typically names or integers — use the NamePhonePad keyboard. It features typewriter-style input for entering letters, and phone-style input for entering numbers.

Primary view (accessed via the ABC key):

namephone-1-light namephone-1-dark

Alternate view 1 (accessed via the 123 key):

namephone-2-light namephone-2-dark

Alternate view 2 (accessed via the the 😀 key):

emoji-light emoji-dark

UIKeyboardType.NumberPad

This is amother numeric entry keyboard. It lets the user enter digits, but not the decimal separator.

Note that there’s no return key of any sort on this keyboard.

Primary view:

numberpad-light numberpad-dark

UIKeyboardType.NumbersAndPunctuation

Think of this as the ASCIICapable keyboard, but with an emphasis on numeric entry. Like the ASCIICapable keyboard, it lets you enter letters, numbers, punctuation, and symbols, and nothing else.

Use this keyboard if you need the user to enter something that’s primarily numeric but may also include letters, symbols and punctuation, but not emoji. You’ll find it especially useful for numeric data entry in business, productivity, scientific, health, and other “serious” apps. You should also use this keyboard when you want the user to enter numbers in scientific notation.

Primary view (accessed via the 123 key):

numbersandpunc-1-light numbersandpunc-1-dark

Alternate view 1 (accessed via the ABC key):

numbersandpunc-2-light numbersandpunc-2-dark

Alternate view 2 (accessed via the #+= key):

numbersandpunc-3-light numbersandpunc-3-dark

UIKeyboardType.PhonePad

If you want the user to enter a phone number or a touch-tone sequence, this is the preferred keyboard.

Primary view (accessed via the 123 key):

phonepad-1-light phonepad-1-dark

Alternate view 2 (accessed via the +*# key):

phonepad-2-light phonepad-2-dark

UIKeyboardType.Twitter

If you want the user to enter a tweet, this is the preferred keyboard.

Primary view (accessed via the ABC key):

twitter-1-light twitter-1-dark

Alternate view 1 (accessed via the 123 key):

twitter-2-light twitter-2-dark

Alternate view 2 (accessed via the #+= key):

twitter-3-light twitter-3-dark

Alternate view 3 (accessed via the the 😀 key):

emoji-light emoji-dark

UIKeyboardType.URL

If you want the user to enter a URL, this is the preferred keyboard.

Primary view (accessed via the ABC key):

url-1-light url-1-dark

Alternate view 1 (accessed via the 123 key):

url-2-light url-2-dark

Alternate view 2 (accessed via the #+= key):

url-3-light url-3-dark

Alternate view 3 (accessed via the the 😀 key):

emoji-light emoji-dark

UIKeyboardType.WebSearch

This keyboard is very similar to the Default keyboard, with two notable differences:

  • There’s a . key in the bottom row
  • The return key is blue, and by default is labelled Go.

It’s meant for entering both URLs and web search terms, but it’s equally useful for any kind search or even typed commands.

Primary view (accessed via the ABC key):

websearch-1-light websearch-1-dark

Alternate view 1 (accessed via the 123 key):

websearch-2-light websearch-2-dark

Alternate view 2 (accessed via the #+= key):

websearch-3-light websearch-3-dark

Alternate view 3 (accessed via the the 😀 key):

emoji-light emoji-dark

{ 1 comment }

Check out this update (May 24, 2016)!

update

The material in this article is still applicable, but you’ll also want to read a newer one titled A better way to program iOS text fields that have maximum lengths and accept or reject specific characters, which shows you how to make text fields that let you specify the following in Interface Builder or using less code:

  • The maximum number of characters that a text field will accept
  • The only characters that can be entered into a text field
  • The only characters that can’t be entered into a text field

I’m already using that material in a couple of projects, and I think you’ll find it handy, too. Check it out!

 

 

 

And now, the original article…

Constraining text fields

constrained text fields demo app

Click the image to see it at full size.

Update, August 26, 2015: I’ve updated this article so that its code works with Swift 2. It compiles under the latest version of Xcode 7, beta 6.

swift kickA little while back, I published an article that covered constraining text fields so that they accepted only values that evaluated to numeric ones, and limited them to a specified maximum number of characters (don’t bother looking for it; it redirects to this article now). This article expands and improves on it by showing you how to create iOS text fields that:

  • accept only numeric values,
  • accept only characters that appear in a specified string,
  • accept any characters except those that appear in a specified string, and
  • combine any of the features listed above

zip file iconIn order to demonstrate this, I’ve created a quick sample app, ConstrainedTextFieldDemo. You can download it here [90K Xcode project and associated files, zipped]. When you run it, you’ll the screen pictured above. It contains a set of text fields, each one with its own set of constraints:

  1. A text field that accepts only vowel characters (upper- and lowercase), and no more than 6 of them.
  2. A text field that accepts any character except vowels, and no more than 8 of them.
  3. A text field that accepts digits only, and no more than 3 of them.
  4. A text field that accepts only numeric values, as long as they’re 7 characters or fewer in length. Note that this field allows numbers in scientific notation.
  5. A text field that accepts only positive integers up to 5 characters in length.

In this article, I’ll walk you through the app and show you how to create your own constrained text fields in iOS. Better still, I’ll give you the project files so that you can experiment with the app.

Cut to the code (and the storyboard, too)!

Before we get into the explanations, let me cut to the chase and just give you the code.

For the purposes of discussing constrained text fields, we need to consider only two files:

  1. The view controller, ViewController.swift, and
  2. a set of string utility methods contained in StringUtils.swift.

Here’s ViewController.swift:

I gave the outlets for the text fields sensible names, but I thought that it might be helpful to show you an annotated storyboard that points out which outlet belongs to which text field:

constrained text fields screenshot

The code in the view controller calls on some string utility methods that I decided to put into their own module: the StringUtils.swift file:

Let’s take a closer look at the code…

The delegate pattern and text fields

The delegate pattern in general

the delegate pattern

The Delegate pattern is a fundamental part of iOS app development. You’ll encounter it often when programming user interfaces, including those times when you want to your program to react to what the user does with text fields.

The delegate pattern involves two categories of object:

  • A delegator, which needs to perform a task, but doesn’t have some needed information, resources, or logic to do so. It gets that needed information, resources, or logic from…
  • A delegate. While it typically can’t do what the delegator does, it has the information, resources, or logic that the delegator needs to perform its task.

My pet analogy for the delegate pattern is pictured above: an airplane and air traffic control. Unlike the driver of a car, who’s controlled only by traffic signals and pretty much free to choose any destination and route s/he pleases, the pilot of a plane has to delegate a lot of those choices to air traffic control. The airplane, which does the actual flying, is the delegator, and air traffic control, which gives clearance for takeoff and landing and tells the plane the heading, speed, and altitude at which it should fly, is the delegate.

The delegate pattern in iOS

If you look at the delegate pattern in Wikipedia, you’ll see that there are a number of ways to implement it. Here’s how it’s done in iOS (and Cocoa), whether you’re doing it in Objective-C or Swift:

delegate pattern in iOS

There are three things in play:

  • The delegator, which keeps a reference to the delegate, which will end up having the task delegated to it,
  • The delegate, which implements the methods and properties used to accomplish the delegated task, and
  • The protocol, which connects the delegator and delegate by:
    • giving the delegator a way to send messages to the delegate, and
    • giving the delegate a way to perform actions on behalf of the delegator.

The delegate pattern with iOS’ text fields

Let’s make the above diagram a little more specific and talk about delegation in terms of iOS’ text fields:

delegation with text fields

iOS text fields — that is, instances of the UITextField class — participate in a delegate pattern as delegators. They’ve got the power to control what happens when the user starts and stops editing their contents and what characters can be typed into them, but they offload the logic that handles those tasks to another object: the delegate.

A specific protocol, the UITextFieldDelegate protocol, connects the text field and its delegate together. A protocol is simply a set of declarations of class members — instance properties, instance methods, type methods, operators, and subscripts. These instance properties, instance methods, type methods, operators, and subscripts are implemented in the delegate (implementing a protocol’s members is called adopting the protocol), and the delegator calls on these implemented members.

The protocol: UITextFieldDelegate

Let’s look at the UITextFieldDelegate protocol. You can actually check it out for yourself; the simplest way is to control-click or right-click on any occurrence of UITextField in your code and then click on Jump to Definition in the contextual menu that appears:

getting to uitextfielddelegate

You’ll be taken to UITextField.h, a header file that allows Swift to connect to the Objective-C code on which UITextField is built. It contains the declarations for all the publicly-accessible parts of UITextField, including the UITextFieldDelegate protocol. You’ll find it near the end of the file. I’ve reproduced it below:

The delegate: ViewController

In order to become a delegate, a class has to adopt the protocol. If you’re familiar with languages like C# and Java, “adopting a protocol” is similar to “implementing an interface”: we add the protocol to a class’ definition, as if we’re inheriting it. In this case, we’ll have the view controller adopt the protocol:

This says that the ViewController class inherits from the UIViewController class and adopts the UITextFieldDelegate protocol. Having the view controller act as the delegate makes sense: it controls the user interface, and the text fields are part of the user interface.

Just as you have to implement the methods in an inherited interface in C# and Java, you have to implement the methods in an adopted protocol in Swift. There is a difference, however: in Swift, you can choose not to implement methods marked as optional.

You may have noticed that all the methods in the UITextFieldDelegate protocol are optional. This means that a delegate that adopts the protocol can implement as many or as few of its methods as necessary. For the purposes of our app, we’re implementing two of them in ViewController:

  • textField(textField: UITextField, shouldChangeCharactersInRange range: NSRange, replacementString string: String) -> Bool: The text field calls this whenever the user tries to change the contents of a text field, whether by typing in or deleting a character, or by cutting or pasting. The method should return true if the change is to be accepted, and false to reject the change and keep the contents of the text field the way they are. We’ll use it to limit the types of character that can be entered into the view’s text fields and set a maximum the number of characters that can be entered for each field.
  • textFieldShouldReturn(textField: UITextField) -> Bool: The text field calls this whenever the user taps the Return key or its equivalent on the keyboard. We’ll use it to dismiss the keyboard when the user taps Return.

We’ll talk about the implementation of these methods in the next section. We have to take care of the delegators first.

The delegators: the text fields

We’ve got a protocol, and we’ve got a delegate that adopts it. Now we need to set up the delegators, which in this case, are the text fields — we need to tell them who their delegates are. We do this by setting each text field’s delegate property in the initializeTextFields method of the ViewController class:

By setting all the text fields’ delegate properties to self, we’re saying that this class is their delegate. Any events arising from editing the text fields will be handled by this class.

Constraining the text fields

The magic that constrains a text field so that it’s vowels-only, numbers-only and so on happens inside the protocol method with the very long signature, textField(textField: UITextField, shouldChangeCharactersInRange range: NSRange, replacementString string: String) -> Bool. This method needs to be coded so that it returns true if we want the user’s changes to be accepted (which then updates the text field), or false if we don’t want the user’s changes to be accepted (which leaves the text field unchanged).

Here’s its code:

This method takes three parameters:

  • textField: the text field that either had a character added to or removed from it.
  • range: the range of the characters within the text field that are to be replaced.
  • string: the replacement string.

Does the change add characters?

The first thing the method does is see if the change adds characters to the text field:

  • If the user has typed a character or pasted non-empty text into the text field, string is non-empty and has a length greater than zero. In this case, we’ll want to do more processing.
  • If the user has deleted a character, cut text, or simply moved the insertion point, string is empty and has a length of zero. In this case, we don’t want to do any more processing; removing characters means we don’t have to see if we want to disallow any added character or if the maximum number of characters for the text field has been exceeded. We’ll just exit the method, returning true so that the change still happens, whether it’s a deletion, a cut, or moving the insertion point.

What will the text field look like after the change?

We want to figure out what the text field would contain if the change were allowed. We’ll call that the prospective text, which we’ll assign to a local constant called prospectiveText. We can figure out what the prospective text is by using NSString‘s stringByReplacingCharactersInRange method on the contents of textField.text.

Here’s where we run into a problem:

  • In order to use NSString‘s stringByReplacingCharactersInRange method, we need to convert a Swift String into an NSString.
  • The type of a text field’s text property type isn’t String, but String?. That’s because a text field’s value can either be:
    • a string when it contains at least one character, or
    • nil when it’s empty
  • String can be cast into NSString; String? can’t.

To get around this problem, we’re going to create a String constant called currentText, which we’ll fill as follows:

  • If the text field isn’t empty — that is, if its value isn’t nil — we’ll simply assign currentText the value of textField.text.
  • If the text field is empty — that is, if its value is nil — we’ll assign currenttext the value "", the empty string. There’s a difference between nil (which denotes no value) and the empty string (which is a value, just one that has a length of 0 characters).

Here’s the code:

As we’ll see shortly, having prospectiveText lets us set a maximum number of characters that can be put into a text field.

Taking care of business

Now that we’ve dealt with cases where the change to the text field deletes characters and have created prospectiveText, we can now start constraining text fields. This is handled in the switch statement, which we use to separate the constraining logic for each text field:

The cases for each text field are listed in the order in which they appear onscreen. Let’s look at them one by one:

The “Vowels only” text field

In this text field, we want the user to be able to enter only vowels — the upper- and lower-case versions of the letters a, e, i, o, and u. We also want to limit its contents to a maximum of 6 characters. Here’s the code that does this:

This code makes use of the String extension method containsOnlyCharactersIn, which I defined in StringUtils.swift. It returns true if the String contains only characters in the provided parameter.

If both conditions in the return statement evaluate to trueprospectiveText contains only vowels and has 6 characters or fewer — the method returns true, the change to the text field is allowed, and the text field is updated. If both conditions don’t evaluate to true, the method returns false, the change to the text field is not allowed, and the text field’s contents remain the same.

The “Anything BUT vowels” text field

In this text field, we want the user to be able to enter any character except vowels and limit its contents to a maximum of 8 characters. Here’s the code that does this:

This code is similar to the code for the “Vowels only” text field. The major difference is that it makes use of another String extension method defined in StringUtils.swift: doesNotContainCharactersIn, which returns true if the String doesn’t contain any of the characters in the provided parameter.

The “Digits only” text field

In this text field, we want the user to be able to enter only digits, and no more than three of them at most. Here’s the code that does this:

This code is almost the same as the code for the “Vowels only” text field.

The “Numeric values only” text field

Here’s an interesting one: a text field that accepts only user input that evaluates to a proper numeric value. That means it will accept the following characters:

  • The digits 0 through 9
  • The (negative) symbol
  • The decimal separator, which is either . or , depending on the user’s locale settings
  • The letter e, which is used for numbers specified in scientific notation

Even when limiting the user to these characters, it’s possible for non-numeric values to be entered. Here are a couple of example non-numeric values that we don’t want the user to be able to enter:

  • More than one decimal separator, such as 1.2.3 or 1,2,3, depending on the user’s locale settings
  • The unary minus being placed anywhere other than the start, such as 4-5

We also want to limit the text field to a maximum of 7 characters.

Here’s the code:

This code makes use of the String extension method isNumeric, which I defined in StringUtils.swift. It returns true if the String contains a value that evaluates to a numeric value. It’s powered by NSScanner, a class that’s handy for going through strings and extracting useful data from them, and its scanDecimal method, which returns true if it finds a value that can be evaluated as an NSDecimal value.

If both conditions in the return statement evaluate to trueprospectiveText evaluates to a numeric value and has 7 characters or fewer — the method returns true, the change to the text field is allowed, and the text field is updated. If both conditions don’t evaluate to true, the method returns false, the change to the text field is not allowed, and the text field’s contents remain the same.

The “Positive integers only” text field

This is a more strict version of the “Numeric values only” text field. It requires that anything entered into it needs to evaluate as a proper numeric value, but it also requires that the value be a positive integer and not be stated in scientific notation. It has a maximum length of 5 characters. Here’s the code:

In order to disallow negative numbers, we use the String extension method doesNotContainCharactersIn to block out characters. We disallow scientific notation by using the same method to block out e characters. The tricky part is disallowing the decimal separator, which can be either . or , depending on the user’s locale. We identify it with NSLocale.currentLocale().objectForKey(NSLocaleDecimalSeparator), which we add to the parameter for doesNotContainCharactersIn.

Any other text fields that might be on the screen

Finally, we handle the default case: any other text fields that might be on the screen, which we won’t constrain:

Other UI goodies

This app has a couple of UI features that I’ll cover in a subsequent article:

  • specifying the keyboard for a specific text field,
  • dismissing the keyboard when the user taps the Return key or its equivalent, and
  • dismissing the keyboard when the user taps on the view

It’s all in the code, so if you’d like to jump in and learn how it works on your own, go right ahead!

Resources

zip file iconIn case you missed it, here are the zipped project files for the demo project, ConstrainedTextFieldDemo [90K Xcode project and associated files, zipped].

{ 25 comments }

The book 'Beginning iPhone Development with Swift'As I wrote in an earlier article, I’ve been working my way through Apress’ Beginning iPhone Development with Swiftan iOS 8/Swift-flavored update of Beginning iOS 7 Development. The original book was released in March 2014, the iOS 8 and Swift betas came out that June, the GM versions came out in September, and the revised book was released in mid-November. In the eight-month span between the original book and the revision, the authors didn’t have much time to try out iOS 8 and Swift, never mind do the rewrite, and as a result, they ended up with a few errors in their text, as well as leaving out some useful material.

I also wrote in that earlier article that in spite of these problems, I still think it’s a good book (as do some other people; it’s got 5 stars on Amazon as of this writing), and where some may see errors and oversights, I see opportunities.

Here’s another opportunity that came up…

The date picker exercise

Chapter 7 of Beginning iPhone Development with Swift, Tab Bars and Pickers, has you build a multi-view app where you use all kinds of “picker” controls. The first view you work on is one with a date picker; here’s a screen shot:

iOS app showing a date picker and a button labelled 'Select'. The selected date in the date picker is 'Today, 4:20 PM'

In this simple view, you use the picker to select a date, tap the Select button, and you’re presented with an alert that looks like this:

iOS app with date picker and button, overlaid with an alert showing the selected date as '2015-01-14 21:20:13 +0000'

Note the format of the date displayed in the alert:

  • It’s not formatted in the most readable way.
  • It has too high a level of detail. The user didn’t enter the number of seconds or a time offset.
  • I entered the time in my time zone (4:20 p.m., Eastern Standard Time, or GMT-5), but the alert is displaying the time for GMT.

Here’s what the book had to say about this:

Note
The date picker does not allow you to specify seconds or a time zone. The alert displays the time with seconds and in Greenwich Mean Time (GMT). We could have added some code to simplify the string displayed in the alert, but isn’t this chapter long enough already? If you’re interested in customizing the formatting of the date, take a look at the NSDateFormatter class.

I’d much rather have the alert look like this…

iOS app with date picker and button, overlaid with an alert showing the selected date as 'Wednesday, January 14, 2015 at 4:20 PM'

…but they’d left doing so as an exercise for the reader. Let’s go through this exercise, shall we?

The original code

Here’s what the view looks like in the Storyboard:

datepicker view

And here’s the code for buttonPressed in the corresponding view controller:

In this code, we’re simply taking the value from the date picker’s date property and using its string representation in the string constant message. In iOS, dates are represented by instances of the NSDate class, which is all about representing a single point in time. While it has the date property for access the date stored within, it doesn’t have any members for formatting that date.

Enter NSDateFormatter

iOS has a number of formatter classes, whose job is to take data and convert it into a text representation, typically for the benefit of the user. These classes have names that end with the word Formatter and are subclasses of the abstract class NSFormatter. You can find out more about these classes in NSHipster’s excellent overview.

The book pointed us towards NSDateFormatter, a class that serves two purposes:

  • Converting NSDate objects into string representations, and
  • Converting strings into NSDate objects.

NSDateFormatter has a class method called localizedStringFromDate that does what we want. Given the following:

  • An NSDate instance,
  • A style specifying how we want the date part of the NSDate instance formatted, and
  • A style specifying how we want the time part of the NSDate instance formatted

…it returns a string representing the NSDate instance in the format we specified.

We specify the styles for the date and time using values from the NSDateFormatterStyle enum, which has the following values:

  • NoStyle: Unstyled.
  • ShortStyle: Typically numeric-only, such as 1/14/15 and 4:20 PM.
  • MediumStyle: A medium-length style, using abbreviations. Examples are Jan 14, 2015 and 4:20:00 PM.
  • LongStyle: A longer style with full text. Examples are January 14, 2015 and 4:20:00 PM EST.
  • FullStyle: Full style with complete details. Examples are Wednesday, January 14, 2015 and 4:20:00 PM Eastern Standard Time.

For our code, we’ll use FullStyle for the date and ShortStyle for the time. Here’s what the revised code looks like — the highlighted lines show the new or modified code:

This code gives us the date in a more user-friendly format.

This example scratches the surface of what’s possible with NSDateFormatter. You should take a look at Date Formatters, which is part of a larger section of their documentation called Data Formatting Guide.

dates and times in swift - smallRelated articles

How to work with dates and times in Swift, part one: An introduction of Cocoa’s date and time classes, and how they work together. This article covers UTC (Coordinated Universal Time), and the key classes: NSDate, NSCalendar, NSDateComponents.

How to work with dates and times in Swift, part two: Calculations with dates: Now that we’ve got the basics, it’s time to do some date arithmetic: comparing two dates to see which one is the earlier and later one, finding out how far apart two dates are, and adding and subtracting from dates.

How to work with dates and times in Swift, part three: Making date arithmetic more Swift-like: Cocoa’s date and time classes have an Objective-C heritage, which in the Swift context, feel kind of clunky. In this article, I look at ways — and by ways, I mean helper functions and class extensions — to make date calculations feel more like Swift.

How to work with dates and times in Swift, part four: A more Swift-like way to get the time interval between two dates: This quick article shows you how to make an operator overload that makes getting the time interval between two dates more like subtraction.

You might also want to check out: How to program an iOS text field that takes only numeric input with a maximum length

{ 3 comments }

Update (April 27, 2015)

updated article

Guess what — this article’s out of date. If you want the latest version of the code for programming constrained text fields in iOS with improved features, point your browser at the revised article, How to program an iOS text field that takes only numeric input or specific characters with a maximum length. It even comes with a sample app that you can download!

The original article

control fun app

One of my favorite ways to get a deeper understanding of programming in a given language or for a given platform is to pick up a highly-rated book for that language or platform and go through all the example tutorials and exercises, no matter how simple they seem. Although I often end up covering ground that I’ve gone over so many times before, I usually find that one or both of the following happen:

  • I end up learning something I didn’t know before, even in subject areas where I consider myself well-versed, or
  • I decide to see if I can improve the implementation or add a new feature, and in the process, learn about a feature new to me or figure out a new way to use a feature I’m already familiar with.

beginning ios development with swiftI got Apress’ Beginning iPhone Development with Swift for less than half price during their recent Cyber Monday sale, and I’ve been working through its tutorials during the holiday downtime. It’s a revision of a book released in late March 2014, Beginning iOS 7 Development (which I also own), updated to cover both a language and OS version whose first betas were released in June and whose 1.0 versions were made available in September. Given that the book was released in mid-November, they updated it in a hurry, which means that the book contains a few errors and oversights. In spite of this, I still recommend the book because:

  • The book is pretty much a straight “port” of an excellent book, Beginning iOS7 Development, for Swift and iOS 8, and
  • where some may see only errors and oversights, I also see learning opportunities.

The oversight

In chapter 4 of Beginning iPhone Development with Swift, whose title is More User Interface Fun, the exercise is to build an app that features a number of commonly-used user interface controls. The app you build starts with a couple of labels and text fields laid out so that they look like this:

name and number text fields

The user is supposed to be able to type in any kind of character into the Name text field, and only numeric characters into the Number field. The exercise in the chapter walks you through the process of setting the Keyboard Type of the Number field to Number Pad using the Storyboard and the Attributes Inspector:

setting keyboard type

While doing this goes a long way to preventing non-numeric input, it isn’t enough. On the iPhone, the Number Pad keyboard allows only digits to be entered…

ios 8 iphone number pad

…which works just fine if the user needs to enter positive whole numbers. If you want the user to enter negative numbers or use a decimal point, you’ll need to use the Numbers and Punctation keyboard, which features some additional characters. Here’s what it looks like on the iPhone:

ios 8 iphone numbes-punctuation keyboard

On the iPad, choosing either the Number Pad or Numbers and Punctuation keyboard gives you the same thing. It looks like this:

ipad number pad keyboard

These keyboards make it possible to enter some decidedly non-numeric input into the Number field.

copy and paste

If that weren’t enough, there’s also cut/copy and paste to contend with. The user can easily type an alphabetical string into the Name field, copy or cut it, and then paste it into the Number field. Clearly, you need to take more active measures if you want to ensure that a field meant for numeric input gets only numeric input.

Beginning iPhone Development with Swift points the way to a solution, but stops short. Here’s what the book says on page 110:

Tip    If you really want to stop the user typing anything other than numbers into a text field, you can do so by creating a class that implements the textView(_, shouldChangeTextInRange:, replacementText:) method of the UITextViewDelegate protocol and making it the text view’s delegate. The details are not too complex, but beyond the scope of this book.

This is wrong for two reasons:

  • I don’t think that disallowing unwanted characters from being input into a text field, which I think is a pretty basic UI feature in this day and age, is beyond the scope of the book, and
  • the method that should be used is part of the UITextFieldDelegate protocol, not the UITextViewDelegate protocol. As I said earlier, they rushed the production of this book.

In this article, I’m going to correct this oversight and show you how to do the following in iOS 8 and Swift:

  • Intercept the user’s input as s/he types or pastes into a text field
  • Allow only a specified set of characters to be entered into a given text field
  • Limit the number of characters that can be entered into a given text field
  • Confirm that the value entered into a text field is numeric

Intercepting the user’s input as s/he types or pastes into a text field

interception

Creative Commons photo by Torsten Bolten, AFpix.de. Click the photo to see the source.

Beginning iPhone Development with Swift was right: the way to really control what the user can enter into a text field is to implement this method in the UITextFieldDelegate protocol:

This method, called textField(_:shouldChangeCharactersInRange:replacementString:), is automatically called in view controllers that conform to the UITextFieldDelegate protocol whenever the user adds a new character to a text field or deletes an existing one. It gives you three parameters to work with:

  • textField: The text field whose contents are being changed
  • range: The range of characters to be replaced
  • string: The replacement string

If we want to accept the changes that the user made to the text field as-is, we have this method return true. If we don’t want to accept the changes, or if we want to alter them, we have this method return false.

In order to implement this method, we need to make the view controller conform to the UITextFieldDelegate protocol. We do this by adding UITextFieldDelegate the view controller’s declaration. In this example, the view controller is simply named ViewController, so we’ll added UITextFieldDelegate to its declaration like so:

In this example, the text field that we want to make “numbers only” is named numberField. We need to specify its delegate — the class containing the UITextFieldDelegate protocol methods that will be called whenever changes are made to its contents. We’ll specify that the view controller should be the delegate, and we’ll do it in the viewDidLoad() method:

Allowing only a specified set of characters to be entered into a given text field

Now that we have the view controller properly set up as a delegate for calls from the numberField text field whenever changes are made to its content, it’s time to implement textField(_:shouldChangeCharactersInRange:replacementString:). We want to implement it in such a way that the only characters that can be entered or pasted into numberField are the digits 0 through 9 and the . and characters.

Here’s the code:

The method starts off with the assumption that the user’s input is legal, and then applies the test to see if that’s actually the case. It then checks to see that the text field whose contents changed is numberField, the field whose content we want to restrict to numeric values. Next, it sees if the replacement string contains at least one character; if it doesn’t, there’s no point testing its content.

The method makes use of an NSCharacterSet instance to define the set of characters that we don’t want to allow inside numberField. Since the set of disallowed characters is much larger than the set of characters we want to allow in numberField,  we define the set by first creating an NSCharacterSet of allowed characters and use the invertedSet method.

Once we’ve defined a set of disallowed characters, we test the replacement string string to see if it contains any of them. If the replacement string string contains disallowed characters, string.rangeOfCharactersFromSet(disallowedCharacterSet) returns the range of the first disallowed character. If it doesn’t have any disallowed characters, it returns nil.

Limiting the number of characters that can be entered into a given text field

Now that we’ve restricted numberField to a small set of characters — the digits 0 through 9 and the . and characters — let’s set a maximum number of characters that numberField can contain; let’s make it 6.

Here’s what our code looks like with this new constraint:

First we determine the prospective text — that is, what the text field would contain if we allow the user’s changes. We do this by using the stringByReplacingCharactersInRange:withString: method, which accepts a range of characters to be replaced, and the string to replace that range of characters.

Note that we have to cast textField.text into an NSString first; that’s because Swift’s String class’ stringByReplacingCharactersInRange:withString: method expects a range in Range<String.Index> format, and we’re working with a range specified as an NSRange. Good ol’ NSString‘s stringByReplacingCharactersInRange:withString: method takes its range as an NSRange.

Once we have the prospective text, we simply check its length. If it’s greater than 6, we have the method return false, which means that the text field simply won’t accept any more than 6 characters.

Confirming that the value entered into a text field is numeric

Let’s add one more constraint to our text field: let’s make sure that only proper numeric values can be entered into the text field. Even though we’ve restricted the user to entering the digits 0 through 9 and the . and characters, it’s still possible to enter non-numeric values such as:

  • 1.2.3 (more than one decimal point), and
  • 4-5 (placing the unary minus anywhere other than at the start of the number).

Let’s add some code to disallow such entries:

What powers this constraint is NSScanner, which is a great tool for parsing string data. We’re using two of its methods:

  • scanDecimal(_:), which returns true if the scanner finds a valid NSDecimal representation in the string, and
  • atEnd, which returns true if the scanner has scanned the entirety of the string.

With the final code shown above, we’ve got a way to ensure that the user can enter only numeric values into a text field, and that those values no longer than a specified number of characters. Contrary to what was implied in Beginning iPhone Development with Swift, it wasn’t all that hard to do.

{ 22 comments }

swift roundup

swift kickAs useful as Apple’s The Swift Programming Language book is, it’s focused solely on the language and has nothing at all about the other 90% of iOS development: the various Cocoa Touch APIs and libraries. Luckily, it’s not that hard for a developer with some iOS/Objective-C coding experience to figure out how to call on them in Swift, and a number of them are sharing their knowledge and findings. Here are some of the more interesting Swift finds that I’ve stumbled across online this week.

Tutorial: Conway’s “Game of Life”

life in swift

If you’re looking for a tutorial that walks you through the process of building a reasonably complete iOS app, MakeGamesWith.Us’s tutorial is for you! You’ll build Conway’s Game of Life using SpriteKit, and get a better understanding of how to call various Cocoa Touch APIs in Swift.

Brian Advent’s video tutorials

If you’ve gone through Apple’s The Swift Programming Language book and are feeling confident about the language itself but less so about calling the various iOS APIs, you’ll find Brian Advent’s video tutorials helpful.

Simple UI in Swift

Want to get started writing full iOS apps in Swift rather than just coding up language-features-only stuff from the book? Start here.

Swift and UIKit

This goes over Swift and some of the UI features we’ve come to know and love — text fields, alert views, and table views — as well as using Swift delegates and closures.

Blurring with UIVisualEffect and Preview in Interface Builder

UIVisualEffect is a new class in iOS 8; this tutorial shows you how to use it to get a blur visual effect. This video also shows you how to use the Preview feature in IB.

iOS 8 notification

iOS 8 lets you add custom actions to your notifications, whether on the lock screen, the Home screen, or the Notification Center. This tutorial shows you how to code them.

Swift projects on Github

Swift-2048

swift - 2048

Austin Zheng posted iOS-2048, his rendition of the game 2048 in Objective-C a few months back, and he’s since made a Swift version, Swift-2048. It’s not complete, but the basic game works, and it should give you a good starting point for your own non-SpriteKit game projects.

Swift Weather

swiftweather

Swift Weather uses not just an Apple API — Core Location —  but also the third-party AFNetworking framework by way of CocoaPods. Be sure to follow the “How to Build” section of the readme.

Want to see more Swift content?

Click here or on the “Swift Kick” logo near the top of this article to see all the Swift-related articles on Global Nerdy.

{ 1 comment }

Update, July 24, 2014: I’ve updated this article to match the updates made to Swift with the release of Xcode beta 4. Gotta love languages in beta!

ios 8 is coming

swift kick

Welcome to another installment of Swift Kick, the series of articles on Global Nerdy covering programming in Apple’s new Swift programming language. Fell free to follow along and fire up your Xcode 6 beta, copy the examples, and experiment on your own! You can find earlier articles in this series by clicking on the Swift Kick logo to the right.

Spoiler alert! This article uses the events from the TV series Game of Thrones as a framework. You don’t need to have watched the series to understand this article, but it will reveal some plot points from the first three seasons.

Game of Thrones is popular among the sort of people who like programming, and given that the show often adds and (very brutally) deletes characters, I thought it would be a fun basis for an article on arrays in Swift.

Here are the Starks, the first family that we’re introduced to in the series:

starks

In this article, we’re going to be working with an array representing the Stark Family. As you might expect, it’s called starkFamily, and here’s its visual representation:

The Stark Family
Parents Children
0
Ned
(Dead)
1
Catelyn
(Dead)
2
Robb
(Dead)
3
Jon
(Alive)
4
Sansa
(Alive)
5
Arya
(Alive)
6
Bran
(Alive)
7
Rickon
(Alive)
Ned Catelyn Robb Jon Sansa Arya Bran Rickon

Here’s code to define the array and then display its contents:

Here’s the output of that code:

While most statements in Swift end at the end of a line, there are certain exceptions. One such exception is made for array literals, which you can write over several lines as shown below. I prefer defining longer arrays this way, as I find them easier to read:

If you’ve programmed in Python or Ruby, you’re familiar with this sort of thing, where the interpreter (or in Swift’s case, the compiler) “knows” that arrays and dictionaries can extend beyond a single line.

Getting individual array elements

stark family array notation

If you’re familiar with programming languages like C#, Java, JavaScript, Lua, Objective-C (more modern versions, anyway), PHP, Python and Ruby, you’ll find Swift’s basic array notation familiar — it’s good ol’ reliable arrayName[index], where arrayName is the name of the array, and index is an integer specifying which element of the array we want to retrieve. As with most programming languages, the first element of an array with n elements is at index 0, the second is at index 1, the third is at index 2, and so on up until the last element, which is at index n-1.

In the code snippet below, we want to access the 3rd and 6th elements of the starkFamily array. Put another way, we want the starkFamily elements at indices 2 and 5:

Here’s the output of that code:

Setting individual array elements

The same array notation can be used to set array elements. In the code below, we want to change the contents of the element at index 0 from “Ned”, which is a nickname, to his proper name, “Eddard”:

Here’s the output:

Is the array empty, and if not, how many elements are in the array?

empty fuel gauge

Swift’s Array type has two handy methods that answer these questions:

  • The isEmpty method returns true if the array has no elements, false otherwise
  • The count method returns the number of elements in the array. If the array is empty (that is, if isEmpty returns true), then count returns 0.

For the code snippet below:

the resulting output is:

Getting ranges of array elements

Swift lets you get sub-arrays of an array by specifying a range of elements. This is one of those things that’s easier to show first, then tell afterwards, so I’ll let this picture do the talking first:

selecting sub-arrays using ranges

  • starkFamily[0..<3] (with 2 dots and a <, also known as the half-open range operator) specifies an array made of the elements of starkFamily starting at index 0, and up to but NOT including the element at index 3. If you’re mathematically inclined, you can think of 2 dots as defining a left-closed, right-open interval, which you write as [0, 3).
  • starkFamily[0...3] (with 3 dots, also known as the closed range operator) specifies an array made of the elements of starkFamily starting at index 0, and up to and including the element at index 3. If you’re mathematically inclined, you can think of 3 dots as defining a closed interval, which you’d write as [0, 3].

Here some code showing array ranges in action. Let’s say we want to pull a couple of arrays out of starkFamily:

  1. An array consisting of only the parents (elements 0 and 1).
  2. An array consisting of only the children (elements 2 and beyond).

Here’s the output:

The half-open range operator is useful for when you want to retrieve a range of array elements starting at some given index, and going on for the rest of the array. You use it in conjunction with the count property, like so:

Remember, in an array of n elements, the index of the last item is n – 1. Of course, you can always get an equivalent result with a 3-dot range…

…but in my opinion, that makes things more complicated than they need to be.

Adding elements to an array

Adding to the end of an array, part 1: The append method

hodor

Let’s add some elements to the end of the array.

While Hodor doesn’t provide much in the way of conversation — the only thing he can say is his own name — he’s practically part of the Stark family. Let’s add him to the end of the starkFamily array with the append method. Here’s a representation of what that would look like:

add hodor

Here’s the code:

and here’s the output:

Adding to the end of an array, part 2: Adding single elements with the += operator

osha

Later in the series, Osha the wildling is taken prisoner and agrees to work for the Starks as a nanny, so she too is practically part of the family. Let’s add her to the starkFamily array, but using the += operator instead. Here’s the visualization of that operation:

add osha

Here’s the code:

And here’s the output:

Adding to the end of an array, part 3: Adding arrays with the += operator

stark direwolves

In the very first episode of Game of Thrones, the Starks come across a dead direwolf and several surviving pups. Each of the pups — eventually named Grey Wind, Lady, Numeria, Summer, Shaggydog, and Ghost — is taken by the Stark children as a pet, making them practically part of the family. Let’s put the direwolves’ names into an array, and then add that array to starkFamily. Here’s the visualization:

add direwolves

The corresponding code:

And the output:

Inserting new elements at a specified position

theon

What if we want to add elements to the array, but somewhere other than the end?

After his father’s failed rebellion against the Starks, Theon became a hostage and ward of the Stark family, who raised him as one of their own. Let’s add him to the family, between the two elder brothers, Robb and Jon, using the insert method:

add theon

The output:

Want to add an element at the beginning of an array? Just use the insert method to insert the new element at index 0.

Deleting elements from an array

Deleting elements from a specified position

The advice given to people new to Game of Thrones is to not get too attached to a character, because anyone — even a lead character — could die. This happened in season 1 when Ned was falsely accused and found guilty of treason:

beheading

…and then Catelyn and Robb (and a good chunk of the army of the North) were killed at the “Red Wedding”, which got this sort of reaction from viewers:

Let’s reflect these deaths by deleting them from the starkFamily array. Here’s the visualization:

killing off characters

Here’s the code:

And here’s the output:

There’s a reason I removed element 2, then element 1, then element 0 rather than starting with element 0 and worked my way up. I’m going to leave it to you to figure why I did it that way.

Deleting the last element of an array

Suppose we want to get rid of the last element in starkFamily. One way to do it is to use the count property of the array to get the array’s size, then subtract 1 from it to get the last index of the array. Then, you’d use the removeAtIndex method to remove that element. It’s done in a single line of code:

While it’s simple, there’s an even simpler way that doesn’t require you to calculate the last index of the array. It’s the removeLast method, and it removes the last element of the array. Here’s the visualization:

removelast

Here’s the code:

The output:

Replacing ranges of array elements

Replacing a range of array elements with an array of equal size

don and betty draper
Let’s cross over to another popular show that airs on Sunday nights: Mad Men. As ill-advised as many of the choices made by the heads of the Stark family were, chances are those choices might by much worse if they were made by Don and Betty Draper. Still, people who make good choices don’t make good drama, so let’s go ahead and replace Ned and Catelyn with Don and Sally.

We could perform the replacement element by element:

But we can reduce this operation to a single line by specifying a range in our array, and assigning a replacement array:

replace range equal size

For this code:

We get this output:

Replacing a range of array elements with a smaller array

In season 4 of Mad Men, Betty had divorced Don and his second bachelorhood is in full swing. Let’s represent this with an array containing only Don, and let’s use this array to replace the range in starkFamily containing Ned and Catelyn. Here’s a visualization of the result:

replace range smaller

Here’s the code:

And here’s the output:

Replacing a range of array elements with a larger array

Later in the Mad Men series, Don marries his second wife, Megan. Let’s treat Don, Betty, and Megan as an array of parents and use them to replace Ned and Catelyn in starkFamily. Here’s the visualization of that arrangement:

replace range larger

Here’s the code:

And here’s the output:

Replacing a range of array elements with an empty array

Earlier in this article, we represented the deaths of Ned, Catelyn, and Robb by deleting them from the starkFamily array one at a time. Since Ned’s, Catelyn’s, and Rob’s elements are all in a row in the range [0...2], we can delete them in a single action by replacing that range with an empty array. Here’s the visualization:

replace range empty

Here’s the code:

And here’s the output:

Want to find out more about arrays in Swift?

There’s more in the Collections Types chapter of Apple’s The Swift Programming Language, and I’ll cover more in part 2 as well.

{ 4 comments }

swift projects on github

Click the image to see Swift language projects on GitHub.

swift kickApple’s documentation, The Swift Programming Language, is a pretty decent read, but its examples are geared around showing individual language features and not around building full-blown apps. With Swift having been released to registered Apple developers a mere three days ago and the NDA preventing the posting of screenshots of iOS 8 and Xcode 6 until their general release, we’re going to be short on books and detailed tutorials for the next few months. So how’s a developer to learn about Swift and still play within the rules of their developer agreement with Apple?

The answer: Github. More accurately, Swift projects on Github. And there are more of them than you might think.

As I write this (10:00 a.m. EDT, June 5, 2014), even though it’s been less than 72 hours since the beta of Xcode 6 (and therefore Swift) was made available for download, there are already about 350 repos on Github marked as being done in Swift. There may be more by the time you read this.

Update: As of 1:45 p.m. EDT, June 5, 2014, there are 370 Swift repos in Github.

Some of these repos are simple experiments with Swift and its syntax, some are tests of interacting with various API using Swift, some are the sort of mini-apps you build when learning a new language, and then there’s this:

flappyswift

That’s right: it’s an implementation of Flappy Bird in Swift. If you’ve always wanted to learn SpriteKit and now want to learn Swift, go to the FlappySwift repo on GitHub and kill two — ahem — birds with one stone.

Keep an eye on Swift projects in Github; I’m sure that their numbers will keep growing. And don’t forget to make your own contribution!

 

{ 1 comment }