Ios

Swift

http://ct.techrepublic.com/clicks?t=1173650495-27e04be60d132c4e5345bb426b99bf3a-bf&brand=TECHREPUBLIC&s=5

http://ct.techrepublic.com/clicks?t=1171694010-27e04be60d132c4e5345bb426b99bf3a-bf&brand=TECHREPUBLIC&s=5

http://ct.techrepublic.com/clicks?t=1170573106-27e04be60d132c4e5345bb426b99bf3a-bf&brand=TECHREPUBLIC&s=5

http://ct.techrepublic.com/clicks?t=1167542399-27e04be60d132c4e5345bb426b99bf3a-bf&brand=TECHREPUBLIC&s=5

Unittesten met xcode

ios7 door ogen appdeveloper

iOS shipment tracker

orientation en shake motion detection

add emailfunctionality to your app

learn iOS als android dev

UIRefreshControl

clock app

Cursus op Techrepublic

pull to refresh

---

Automatisch iconen genereren, afkomstig van Techrepublic

Apple now requires applications to have a high resolution icon of size of 1024×1024 when submitting to iTunes. This same icon should be scaled down to various sizes for your application binary to support all the different screen resolutions of iOS devices. This includes app and search spotlight icons for the original iPhone, iPhone w/ Retina display, iPad, and iPad with Retina display. The help documentation specifies exact filenames that should be used for older devices as well as Info.plist keys that should be used for new devices.

Relieve the pain

It can be a little painful generating all the different icon sizes (currently there are 10) whenever you do an application update. If you use Photoshop to create your icons, then I recommend creating an Action Script to automate the process for you.

Always start with a 1024×1024 canvas when creating a new application icon. When you are ready to save your icon into the different format, pull up the Actions window, create a new action named ‘Export Icons for iOS’, and then hit the record button. For each of these icon filenames and formats select File | Save for Web & Devices, select PNG-24 non-transparency, and export to a folder on your desktop (ex: Exported Icons) using the following filenames and sizes:

• Icon.png - 57 x 57
• Icon@2x.png - 144 x 144
• Icon-72.png - 72 x 72
• Icon-72@2x.png -144 x 144
• Icon-Small.png - 29 x 29
• Icon-Small@2x.png - 58 x 58
• Icon-Small-50.png - 50 x 50
• Icon-Small-50@2x.png - 100 x 100
• iTunesArtwork - 512 x 512
• iTunesArtwork@2x - 1024 x 1024

Once you finish exporting, stop recording your action, and now you can run this script whenever it’s time to export a new batch of icons. However, one thing you will have to do is rename the iTunesArtwork files to remove the PNG extension. I couldn’t figure out how to have the action script do this for you so you will have to do it manually every time.

Now add all the icon files to your iOS project in Xcode. (Figure A)

Figure A

[1][img]http://i.techrepublic.com.com/blogs/a_add-icons-to-project.png[/img]

And update your Info.plist file with the following keys to let the system know the icons exist. (Figure B)

Figure B

[2][img]http://i.techrepublic.com.com/blogs/b_icon-plist-file.png[/img]

That’s it! Now when you create new projects you have an Action Script that can export your icons, and you can copy/paste the Info.plist keys from this project. I think you’ll find it will save you a ton of time for the next project.

Download an example of the generated icons.

See official iOS documentation for more information on icons.

---

Build a Flickr-app, deel 1, afkomstig van Techrepublic

[img]http://i.techrepublic.com.com/gallery/6376816-80-80.jpg[/img]I am going to assume you all know Flickr. In this tutorial we will show you how to create a simple app that connects to Flickr, sends a request, parses the results, and displays them into a table view. The table view you should be quite familiar with. The Flickr connection itself will be a little bit new, however you will notice that it is very similar to our Twitter app. Finally, we will toy with the app to make it load photos in a non-obstructive way.

The sketch for this app would be simple: A single window that contains a table view.

Steps

Let’s review the steps:

1. Create the app mold
2. Connect to Flickr
3. Fetch and Parse the data
4. Populate the table view
5. Tinker!

Okay, let’s start by creating an Empty Application and call it TRFlickApp. Your app simply contains an AppDelegate. From this AppDelegate we will instantiate a UITableViewController which will display our final data. So go ahead and create a new UITableViewController Class file and name it MyTableViewController.

Aside from the AppDelegate and the UITVC, you will need a Flickr app and a JSON folder to parse json results from web responses. The Flickr app is easy enough to create. Simply go to flickr.com and login with your account or else create a new one. I’ll make your life easier and suggest you simply follow this link: [3]

You will basically need to Request an API Key. Give your app a title if you wish. The important resource here is the API Key. This is what Flickr.com API will use to authenticate your iOS app in order to access Flickr.com.

Now on to the JSON parser! We will be using Stig Brautaset’s JSON parser. It’s located at Github and you just need the Classes folder, which contains the SBJSON files in it. So add this to your project.

Now that we have all four resources, let’s get to work.

Code

Forward declare your MyTableViewController in your AppDelegate.h, create an ivar for it and make it a property:

@class MyTableViewController;

MyTableViewController *myTableViewController;

@property (nonatomic, retain) IBOutlet UIWindow *window;

The three lines above accomplish this task. You already know where they should go inside your AppDelegate. As for the AppDelegate.m file, import the MyTableViewController, synthesize the property and instantiate/load the vc in the appDidFinishLaunching method.

#import "MyTableViewController.h"

@synthesize myTableViewController;

self.myTableViewController = [[MyTableViewController alloc] initWithStyle:UITableViewStylePlain];

 myTableViewController.view.frame = [UIScreen mainScreen].applicationFrame;

[window addSubview:myTableViewController.view];

// Override point for customization after application launch

[window makeKeyAndVisible];

And don’t forget to release the property in your dealloc method, unless you are using ARC. That’s it for the AppDelegate.

Moving on to the vc, add two ivars to contain names and photos in MyTableViewController.h:

NSMutableArray *photoNames;

NSMutableArray *photoURLs;

Let’s make sure to import the remaining two resources into MyTableViewController.m:

#import "JSON.h"

#import "FlickrAPIKey.h"

Now let’s put these resources together. In your vc initializer, init your array ivars:

- (id)initWithStyle:(UITableViewStyle)style

{

 self = [super initWithStyle:style];

 if (self) {

 photoURLs = [[NSMutableArray alloc] init];

 photoNames = [[NSMutableArray alloc] init];

 [self loadFlickrPhotos];

 }

 return self;

}

Since images need to be larger to be appreciated, let’s do the user a favor and enlarge the typical cell by doing this in our viewDidLoad:

- (void)viewDidLoad

{

 self.tableView.rowHeight = 95;

}

You require the numberOfRowsInSection method at least, so implement it based on your array count:

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section

{

 return [photoNames count];

}

Now let’s assume our photo and names array are populated and worry about displaying them in the table view:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath

{

 UITableViewCell *cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:@"Cell Identifier"] autorelease];

 cell.textLabel.text = [photoNames objectAtIndex:indexPath.row];

 NSData *imageData = [NSData dataWithContentsOfURL:[photoURLs objectAtIndex:indexPath.row]];

 cell.imageView.image = [UIImage imageWithData:imageData];

 return cell;

}

Ok, let’s review. If our photos and names arrays were populated, we would extract the value in the names array and place it in the cell.textLabel.text. We would do something similar with the images. We would extract them into an NSData object and put it into the cell.imageView.image.

Populate the arrays

Now that we have the display part out of the way, let’s focus on actually populating those arrays correctly. For that, let’s turn to our initWithStyle method where we called a [self loadFlickrPhotos]; method. Let’s implement that method now.

- (void)loadFlickrPhotos

{

 // 1. Build your Flickr API request w/Flickr API key in FlickrAPIKey.h

 NSString *urlString = [NSString stringWithFormat:@"http://api.flickr.com/services/rest/?method=flickr.photos.search&api_key=%@&tags=%@&per_page=10&format=json&nojsoncallback=1", FlickrAPIKey, @"mayan2012"];

 NSURL *url = [NSURL URLWithString:urlString];

 // 2. Get URLResponse string & parse JSON to Foundation objects.

 NSString *jsonString = [NSString stringWithContentsOfURL:url encoding:NSUTF8StringEncoding error:nil];

 NSDictionary *results = [jsonString JSONValue];

 // 3. Pick thru results and build our arrays

 NSArray *photos = [[results objectForKey:@"photos"] objectForKey:@"photo"];

 for (NSDictionary *photo in photos) {

 // 3.a Get title for e/ photo

 NSString *title = [photo objectForKey:@"title"];

 [photoNames addObject:(title.length > 0 ? title : @"Untitled")];

 // 3.b Construct URL for e/ photo.

 NSString *photoURLString = [NSString stringWithFormat:@"http://farm%@.static.flickr.com/%@/%@_%@_s.jpg", [photo objectForKey:@"farm"], [photo objectForKey:@"server"], [photo objectForKey:@"id"], [photo objectForKey:@"secret"]];

 [photoURLs addObject:[NSURL URLWithString:photoURLString]];

 }

}

Ok let’s review this. Notice it is very similar to Twitter’s API. You construct a Request object using something to authenticate you (API Key) and something to look for (”mayan2012″ string) in our case.

We then create an NSURL out of the string object. We then get the URL response and parse it using JSONValue and put it into an NSDictionary. We then simply loop through the resulting dictionary and retrieve the values we are interested in and put them into their respective array.

Voila! We are done!

Well, except for one more thing. We need to actually tell the app what our API Key is. Create an Objective C header file called FlickrAPIKey.h and put this line into it:

NSString *const FlickrAPIKey = @"YOURAPIKEYVALUE";

Okay, now you can Build & Run your project. You will see the table view populate with names and images related to “mayan2012″ Flickr search.

View controllers

This was a pretty simple app but its intent is quite important. If you have been following our iOS Build it Yourself series, this app will reinforce your knowledge about table view controllers, connecting to web services, using JSON to parse results from the web and basic Objective-C coding practices.

Drop us a line if you have any questions so far. We will continue polishing this app in a second part later this month.

---

Build a Flickr-app, deel 2, afkomstig van Techrepublic

Now, let’s tinker with it!

The first thing we will tinker with is performance. We will actually use Part 1 of this project in a further lesson having to do with performance. First of all let’s just take note that loading pictures from the web is a very “expensive” operation. Expensive meaning that it consumes a lot of resources.

If you recall from Part 1, our app builds a tableview and when it wants to fulfill the image requirement, it calls this line:

NSData *imageData = [NSData dataWithContentsOfURL:[photoURLs objectAtIndex:indexPath.row]];

A web call had already been made in our loadFlickrPhotos method. But that is a very simple web call. Let’s review that method next. We created a string to fetch initial data from its URL like so:

NSString *urlString = [NSString stringWithFormat:@"http://api.flickr.com/services/rest/?method=flickr.photos.search&api_key=%@&tags=%@&per_page=10&format=json&nojsoncallback=1", FlickrAPIKey, @"mayan2012"];

As you can see, we go to the resource api.flick.com and send our api_key and get 10 results per page in json format while sending the keyword mayan2012. Then we put the results into an NSDictionary and finally build our photoNames and photoURLs arrays.

Notice we are not specifying what size of picture to get, so we just fetch the default size which is thumbnail. Notice it takes very little time to load the images and even when you scroll the tableview the UI is not SO slow. But let’s look at the next web fetch in that method:

NSString *photoURLString = [NSString stringWithFormat:@"http://farm%@.static.flickr.com/%@/%@_%@_s.jpg", [photo objectForKey:@"farm"], [photo objectForKey:@"server"], [photo objectForKey:@"id"], [photo objectForKey:@"secret"]];

Here we are building the photoURLs array and we build it using the known info so far. Let’s make it fetch a medium sized image instead by changing it to this:

NSString *sizeit = @"m";

NSString *photoURLString = [NSString stringWithFormat:@"http://farm%@.static.flickr.com/%@/%@_%@_%@.jpg", [photo objectForKey:@"farm"], [photo objectForKey:@"server"], [photo objectForKey:@"id"], [photo objectForKey:@"secret"], sizeit];

Now we are telling it we want the m-sized image. Run the app once again and watch how much slower it is at fetching the images. Scroll the tableview and weep!

Enter GCD

GCD, known as Grand Central Dispatch, is a very good tool for tuning your app’s performance. Basically when your app launches, it fetches most of its files from the sandboxed content included in the app. Of course apps would not be as fun nor would they be as popular if they didn’t fetch data from the almighty cloud. This is a resource-heavy operation.

Other expensive transactions include editing media files or preloading large media files, complex database searches etc. However, most apps you see in the appstore manage to do precisely these tasks and still seem quite fast and responsive. They do this by creating multiple threads.

The main thread is where the apps’ UI runs in. That thread is used for drawing cells, local images, text, scrolling, gesturing etc. This is the thread the user interacts with which makes it the most important thread. You never want to slow this thread down, much less stop it or freeze it. That’s for Android and Windows phones.

GCD lets you, quite simply, take expensive transactions and send them out to another thread. So let’s take a look at how this works.

We want to take that expensive line that fetches NSData and “wrap it” around a GCD call, which will send it off to the side and return the results whenever they are ready WITHOUT slowing us down. So go to your cFRAIP method and change it to this:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath{

//P1

UITableViewCell *cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:@"Cell Identifier"] autorelease];

cell.textLabel.text = [photoNames objectAtIndex:indexPath.row];

<strong>//P2</strong>

<strong> dispatch_async(kfetchQueue, ^{</strong>

//P1

NSData *imageData = [NSData dataWithContentsOfURL:[photoURLs objectAtIndex:indexPath.row]];

<strong>//P2</strong>

<strong> dispatch_async(dispatch_get_main_queue(), ^{</strong>

//P1

cell.imageView.image = [UIImage imageWithData:imageData];

//P2

[self setImage:cell.imageView.image forKey:cell.textLabel.text];

<strong>[cell setNeedsLayout];</strong>

<strong> });</strong>

<strong> });</strong>

return cell;

}

The lines in bold are the ones we added. Notice how we simply wrapped our original call around a dispatch_async to kfetchQueue which sends a shout out to a special thread to perform that dataWithContentsOfURL call and then it returns to the main queue or main thread via the dispatch_async dispatch_get_main_queue(). Finally once we get back to the main queue we call cell setNeedsLayout to redraw the tableview cell with the new image data.

To make this work we have to add this import and this define to our .m file:

#import <dispatch/dispatch.h>

#define kfetchQueue dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0)

Fetching data on a separate thread is better, but fetching only the images you need to fetch is better still!

Enter Caches

A cache is just a fancy name for a repository for already used stuff. Anything that you use at one point and want to discard when not in current use but might need later, you want to store in a cache. We will create a very simple cache here. To keep things neat we will create a Cache Class. Let’s call it ImageCache and make your .h file look like this:

#import <Foundation/Foundation.h>

@interface ImageCache : NSObject

@property (nonatomic, retain) NSCache *imgCache;

+ (ImageCache*)sharedImageCache;

- (void)addImage:(NSString *)imageURL: (UIImage *)image;

- (UIImage*)getImage:(NSString *)imageURL;

- (BOOL)doesExist:(NSString *)imageURL;

@end

Don’t be intimidated by the Class method. Such a method is typical of a class which will take data temporarily and do something to it, without ever really storing any data of its own. These are sometimes called Helper Classes.

The methods declared are sharedImageCache which as you will see basically creates one instance of itself and no more. The addImage method takes a URL and an image and stores it in the cache. The getImage returns an image based on the passed URL and finally a method that returns YES or NO based on if the passed URL returns an existing image.

Let’s look at the implementation of this simple class:

#import "ImageCache.h"

@implementation ImageCache

@synthesize imgCache;

static ImageCache* sharedImageCache = nil;

+(ImageCache*)sharedImageCache{

@synchronized([ImageCache class]) {

//If there is no instance, create one and return it

if (!sharedImageCache)

sharedImageCache= [[self alloc] init];

return sharedImageCache;

}

//Otherwise return nil (Only a SINGLE instance can exist)

return nil;

}

+(id)alloc{

@synchronized([ImageCache class]) {

NSAssert(sharedImageCache == nil, @"Attempted to allocate a second instance of a singleton.");

sharedImageCache = [super alloc];

return sharedImageCache;

}

return nil;

}

-(id)init{

self = [super init];

if (self != nil) {

imgCache = [[NSCache alloc] init];

}

return self;

}

- (void)addImage:(NSString *)imageURL: (UIImage *)image{

//Take a URL and an image and store it in a cache

[imgCache setObject:image forKey:imageURL];

}

- (UIImage*)getImage:(NSString *)imageURL{

//Take a passed URL and return an image

return [imgCache objectForKey:imageURL];

}

- (BOOL)doesExist:(NSString *)imageURL{

//If image doesn't exist, return false

if ([imgCache objectForKey:imageURL] == nil){

return false;

}

//Otherwise, return true

return true;

}

@end

Note the comments in the code. The first three methods take care of creating what is called a Singleton Class. This is a class which can only have one instance of itself, otherwise it returns nil and a log. The last few methods are pretty simple to understand. They handle the storing and fetching of images in a cache. Now let’s put it to the test. Modify your cellForRowAtIndexPath to look like this:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath{

//P1

UITableViewCell *cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:@"Cell Identifier"] autorelease];

cell.textLabel.text = [photoNames objectAtIndex:indexPath.row];

//If image exists then get it from the cache

if ([[ImageCache sharedImageCache] DoesExist:[photoNames objectAtIndex:indexPath.row]] == true) {

cell.imageView.image = [[ImageCache sharedImageCache] GetImage:[photoNames objectAtIndex:indexPath.row]];

} else {

//Otherwise fetch the imageData

dispatch_async(kfetchQueue, ^{

//P1

NSData *imageData = [NSData dataWithContentsOfURL:[photoURLs objectAtIndex:indexPath.row]];

dispatch_async(dispatch_get_main_queue(), ^{

cell.imageView.image = [UIImage imageWithData:imageData];

// Add the image to the cache

[[ImageCache sharedImageCache] AddImage:[photoURLs objectAtIndex:indexPath.row] :cell.imageView.image];

[cell setNeedsLayout];

});

});

}

return cell;

}

First we check to see if the image already exists in the cache. If it exists then we use it, otherwise we fetch it. Whenever we fetch it, we set the image and immediately afterwards we fill the cache containing the image data object with its key for each image we set. Thus our cache is built. This way we save valuable bandwidth and battery power along with it.

We have now taken our Flickr app and really tuned it up. Once again, drop us a line if you have any questions.

---

Voeg animaties toe aan je app, afkomstig van Techrepublic

Nothing says “class” like an app that has great visual appeal. Good artwork is of course very important, but adding even the simplest of animations can give your app that extra dose of “wow.” Best of all, it’s very easy to accomplish. In Part 1, we’ll build a project to learn a simple technique that you can use to give your app a more polished look and feel by showing how to fade views in and out. Then in Part 2 we’ll use motion to recreate a common iPhone visual effect.

New project

Open Xcode and from the File menu, select New, and then New Project. A new workspace window will appear, and you will be presented with several application templates to choose from. On the left-hand side, select Application from the iOS section. Select Single View Application and click the Next button. (Figure A)

Figure A

[4][img]http://i.techrepublic.com.com/blogs/a_skantner_simple_animation.png[/img]

On the next pane, enter Animations for the Product Name and com.myappcompany as the Company Identifier. (Feel free to substitute your own product name and company identifier).

Leave the Class Prefix as is. It should be blank - XYZ is just a placeholder hint.

Make sure Use Automatic Reference Counting is checked and uncheck the others.

Set Device Family to iPhone, and click Next. (Figure B)

Figure B

[5][img]http://i.techrepublic.com.com/blogs/b_skantner_simple_animation.png[/img]

A new pane will appear asking you where you would like to save the project. XCode will create an Animations project folder inside the directory you select.

Once the project is created, Xcode will open a workspace window with your new project.

Setting up the user interface

In the Files and Groups pane, click on ViewController.xib. After it opens in Interface Builder, select the View object, click on the Attributes Inspector and then change the view’s background color to a color of your choosing.

Next go to the Object Library located on the lower right-hand side of the workspace and drag a UILabel onto the view. Drag it’s resize handles to make it approximately two-thirds the width of the view, and change both its background and text color. Figure C summaries the situation so far.

Figure C

<a href="http://i.techrepublic.com.com/blogs/c_skantner_simple_animation.png"><img class="alignnone size-full wp-image-502" title="c_skantner_simple_animation" src="http://i.techrepublic.com.com/blogs/c_skantner_simple_animation.png" alt="" width="620" height="684"></a>

Next, click on the Assistant Editor in the upper right corner of the Xcode Interface. (Figure D)

Figure D

[6][img]http://i.techrepublic.com.com/blogs/d_skantner_simple_animation.png[/img]

The Assistant Editor will display ViewController.h in an adjacent pane as shown in Figure E. Click on the label to select it, then press the Control key and drag from the label to just under the word “@interface” in ViewController.h. When you release your finger from the mouse, the Connection dialog will appear. Type “myLabel” into the Name field and press Enter.

You have now created an outlet named myLabel and connected it to the UILabel in the xib file. For more information on outlets, see Getting started with iOS Views and View Controllers: Part 1. Click on the Standard Editor button to remove the Assistant Editor window from the screen.

Figure E

[7][img]http://i.techrepublic.com.com/blogs/e_skantner_simple_animation.png[/img]

Build and run the app. Notice how abruptly the view snaps on to the screen. Our objective will be to improve this default visual behavior by replacing it with a nice gradual fade-in effect.

Click on ViewController.m in the Files and Groups pane and add the code below just under the viewDidLoad: method.

- (void)viewWillAppear:(BOOL)animated

{

[super viewWillAppear:animated];

self.view.alpha = 0.0;

[UIView animateWithDuration:0.5

animations:^{

self.view.alpha = 1.0;

}];

}

Every UIView has a floating point property named alpha that controls the view’s transparency. Its value ranges from 0.0 to 1.0, where 0.0 represents totally transparent and 1.0 represents totally opaque. Since viewWillAppear: is called before the view is drawn on the screen, setting its alpha value to 0.0 effectively causes it to become invisible before it is even displayed.

The call to UIView’s built in animateWithDuration: method is where the magic happens. Changing the value of certain properties of views can be animated using this method, and by animating the change of alpha, we can gradually alter its value from 0.0 to 1.0 over a defined amount of time.

The first parameter to animateWithDuration: is the amount of time in seconds that the animation will last. By setting this to 0.5, the value of alpha will reach 1.0 in half a second. To speed up or slow down how quickly the view comes into view, we simply specify a smaller or larger duration.

The messy looking syntax being passed to the animations: parameter is called a block. It is simply a chunk of code that we want to have executed. In this, we just have one line of code that sets self.view.alpha to 1.0. Simply put, we are telling UIView to change the value to 1.0, but to do it gradually over 0.5 seconds.

Build and run the app again. Experiment with different values for the duration until you find something pleasing. You’ve no doubt seen this effect dozens of times in other apps, and now you know how it’s done!

Now add the following code to viewWillAppear directly after the code you entered above.

[UIView animateWithDuration:1.5

animations:^{

self.myLabel.alpha = 0.0;

}

completion:^(BOOL success){

[UIView animateWithDuration:3.0 animations:^{

self.myLabel.alpha = 1.0;

}];

}];

Here we’re using another one of UIView’s animation methods that lets us to run one animation, wait for it to complete, and then run a second animation. Using the alpha property as we did with the main view, we cause the label to disappear over the course of 1.5 seconds, and then reappear over the next 3 seconds.

Build and run the app and experiment with different duration values as before. No doubt your mind is already full of new ideas for using this cool effect in your own apps! For example, by repeating this effect with short durations, you can create slowing blinking text to draw the user’s attention to something they’ve overlooked or entered incorrectly.

In Part 2 we’ll see how to achieve a very common effect Apple uses in its own apps by animating the label to different positions on the screen.

---

Juiste on-screen toetsenbord instellen, afkomstig van Techrepublic

When it comes to discussions surrounding hardware versus software keyboards, there is no shortage of soapboxes within the opinion-riddled mobile device user community. It has been nearly six years since the introduction of the iPhone (July 29, 2007) and its controversial software keyboard. As with most trail-blazing innovations, the value is theoretical - at first. As time goes by, however, trendy innovations become part of everyday life. On-screen keyboards have become the norm, and certainly the only choice for iOS devices.

There are many benefits of an on-screen keyboard. One benefit is based on the concept of a “situation-specific” keyboard changing to be relevant to the current needs of the iOS app. When the user is attempting to enter a URL into the address bar of a browser, why not have a single button for typing “.com?” Moreover, a space is not allowed in web addresses, so why include a spacebar on the keyboard layout? Customizing the keyboard to match certain situations eliminates input errors. It is important for iOS developers to use the appropriate keyboard layout for any given situation.

iOS keyboards types

The four most common keyboard types are (1) the default keyboard, (2) the URL keyboard, (3) the e-mail keyboard, and (4) phone keyboard. Each of the keyboard types is designed for specific situations and should be used in accordance with Apple’s Design Guidelines. The full list of keyboards available for use within an iOS app includes:

• Default
• ASCII Capable
• URL
• Number Pad
• Phone Pad
• Name Phone Pad
• E-mail Address
• Decimal Pad
• Twitter

Every input object within an iOS app where a keyboard or number pad would typically be used has a specific keyboard type assigned. If the developer does not select a keyboard type, the default keyboard is used (Figure A).

Figure A

[8][img]http://i.techrepublic.com.com/blogs/a_gdean_iosdevices_keyboards.png[/img]

There are two keyboard layouts, and the keyboard type is a parameter controlling the keys within each layout. The default keyboard, for example, contains all of the basic input keys that would be used for general text input. This keyboard layout includes several views allowing the user to toggle between the initial alphabetical keyboard to the numeric and punctuation views. The language preferences for the iOS device controls the characters mapped to each layout as well as the input method or flow.

Here is a breakdown of iOS 6 keyboard types: UIKeyboardType

1. Keyboard Type: Default

• Constant: UIKeyboardTypeDefault
• Description: A basic QUERTY keyboard with additional views for punctuation and numbers (Figure B).

Figure B

[9][img]http://i.techrepublic.com.com/blogs/b_gdean_iosdevices_keyboards.png[/img]

2. Keyboard Type: ASCII Capable

• Constant: UIKeyboardTypeASCIICapable
• Description: A standard keyboard layout displaying standard ASCII characters.

3. Keyboard Type: Numbers and Punctuation

• Constant: UIKeyboardNumbersAndPunctuation
• Description: Use the alternate numbers and punctuation view of the default keyboard.

4. Keyboard Type: URL

• Constant: UIKeyboardTypeURL
• Description: Includes URL-friendly keys - such as a “.com” and “.” key - and does not include the spacebar (Figure C).

Figure C

[10][img]http://i.techrepublic.com.com/blogs/c_gdean_iosdevices_keyboards.png[/img]

5. Keyboard Type: Number Pad

• Constant: UIKeyboardTypeNumberPad
• Description: Standard numeric keypad.

6. Keyboard Type: Phone Pad

• Constant: UIKeyboardTypePhonePad
• Description: Layout similar to the number pad, but keys arranged for dialing a phone number (Figure D).

Figure D

[11][img]http://i.techrepublic.com.com/blogs/d_gdean_iosdevices_keyboards.png[/img]

7. Keyboard Type: Name Phone Pad

• Constant: UIKeyboardNamePhonePad
• Description: Keyboard layout for entering an individual’s name or phone number.

8. Keyboard Type: E-mail Address

• Constant: UIKeyboardEmailAddress
• Description: Layout for entering an email address. Includes the “@” symbol as well as a “.” character (Figure E).

Figure E

[12][img]http://i.techrepublic.com.com/blogs/e_gdean_iosdevices_keyboards.png[/img]

9. Keyboard Type: Decimal Pad

• Constant: UIKeyboardDecimalPad
• Description: Similar to a standard number pad. Includes numbers and a decimal point.

10. Keyboard Type: Twitter

• Constant: UIKeyboardTwitter
• Description: Keyboard with easy access to the “#” and “@” characters for composing tweets.

With so many options available, it is important to select the keyboard layout appropriate to the situation. The idea is to select a keyboard layout that:

1. Will produce the best user experience, and
2. Result in the least amount of user input mistakes.

Using the E-mail keyboard type, for example, eliminates the possibility of a user entering a non-conforming space character as part of an address. Make sure to consider all of the possible variations a user might need to enter into a given field and choose the best keyboard layout.

User interface considerations

When user input is required in an iOS app, the developer should consider all types of input controls. In other words, a keyboard may not be the best choice in a recipe app where the user is tasked with entering measurement values and units. A keyboard would allow for freeform input, whereas a UIPickerView would be a better choice. It would be easier - with consistent results - to calculate values entered from a picker control than from freeform text fields.

In the event a keyboard is the best option, make sure to review and set all of the properties for managing the keyboard behavior. Depending on the keyboard type, additional properties can be set. The non-numeric keyboard types support auto-capitalization, auto-correction, and spell checking. If the input field is to contain sensitive information - such as a PIN number or password - consider setting secureTextEntry property.

Final thoughts

On-screen keyboards have much more versatility than fixed hardware keyboards. Some users prefer hardware keyboards because they can type without looking at the keypad - a nearly impossible task on the iOS devices. However, the benefits of an on-screen keyboard outweigh the limitations. Hardware manufacturers also recognize the advantages of this technology.

An on-screen keyboard supports many languages without the need to produce language-specific hardware. Research in Motion (RIM) developed their Blackberry Z10 with a touchscreen keyboard. While you cannot “feel” the keys on this new device, the on-screen keyboard is capable of learning how you type as well as predicting the words you are entering.

Technology companies are constantly innovating and developing solutions to make their products better. The on-screen keyboard is an innovation that has gained momentum in the past few months. The Twitter keyboard layout, for example, would not have been a consideration a few years ago. Remember to take advantage of the iOS device’s capabilities, and leverage the versatility of the on-screen keyboard.