iOS App Programming Guide => Advanced Tricks

Configuring Your App to Support iPhone 5

To support the larger screen in your code properly, always retrieve the size of a screen, window, or view dynamically and use that size information to configure your interface.

To let the system know that your app supports the iPhone 5 screen size, include a properly named launch image in your app’s bundle. At runtime, the system looks for a launch image whose name contains the-568h modifier. If such an image is present, the system assumes that your app supports the iPhone 5 explicitly and runs it in fullscreen mode. If such an image is not present, the system runs your app with black bars above and below your app’s content on devices with the larger screen; it also reports the screen size of your app as 320 by 480 points so that your app’s screen-based calculations continue to be correct.

Creating a Universal App

Updating Your Info.plist Settings

Most of the existing keys in a universal app’s Info.plist file should remain the same. However, for any keys that require different values on iPhone versus iPad devices, you can add device modifiers to the key name. When reading the keys of your Info.plist file, the system interprets each key using the following format:

key_root-~

In this format, the key_root portion represents the original name of the key. The and portions are both optional endings that you can use for keys that are specific to a platform or device. For apps that run only on iOS, you can omit the platform string. (The iphoneos platform string is used to distinguish apps written for iOS from those written for Mac OS X.) To apply a key to a specific device, use one of the following values:

• iphone—The key applies to iPhone devices.

• ipod—The key applies to iPod touch devices.

• ipad—The key applies to iPad devices.

For example, to indicate that you want your app to launch in a portrait orientation on iPhone and iPod touch devices but in landscape-right on iPad, you would configure your Info.plist with the following keys:

UIInterfaceOrientation

UIInterfaceOrientationPortrait

UIInterfaceOrientation~ipad

UIInterfaceOrientationLandscapeRight

Implementing Your View Controllers and Views

For view controllers, follow these guidelines:

• Consider defining separate view controller classes for iPhone and iPad devices. Using separate view controllers is often easier than trying to create one view controller that supports both platforms. If there is a significant amount of shared code, you could always put the shared code in a base class and then implement custom subclasses to address device-specific issues.

• If you use a single view controller class for both platforms, your code must support both iPhone and iPad screen sizes. (For an app that uses nib files, this might mean choosing which nib file to load based on the current device idiom.) Similarly, your view controller code must be able to handle differences between the two platforms.

For views, follow these guidelines:

• Consider using separate sets of views for iPhone and iPad devices. For custom views, this means defining different versions of your class for each device.

• If you choose to use the same custom view for both devices, make sure your drawRect: andlayoutSubviews methods especially work properly on both devices.

Using Runtime Checks to Create Conditional Code Paths

If your code needs to follow a different path depending on the underlying device type, use the userInterfaceIdiom property of UIDevice to determine which path to take. This property provides an indication of the style of interface to create: iPad or iPhone. Of course, the simplest way to check this property is to use the UI_USER_INTERFACE_IDIOM macro, which performs the necessary runtime checks for you.

if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad) {
     // The device is an iPad running iOS 3.2 or later.
}

else {
     // The device is an iPhone or iPod touch.
}

Supporting Multiple Versions of iOS

Any app that supports a range of iOS versions must use runtime checks to prevent the use of newer APIs on older versions of iOS that do not support them. Runtime checks allow you to use recently introduced features when they are available and to follow alternate code paths when they are not.

There are several types of checks that you can make:

• To determine whether a method is available on an existing class, use the instancesRespondToSelector: class method or the respondsToSelector: instance method.

• Apps that link against iOS SDK 4.2 and later can use the weak linking support introduced in that version of the SDK. This support lets you check for the existence of a givenClass object to determine whether you can use that class. For example:

if ([UIPrintInteractionController class]) {
   // Create an instance of the class and use it.
}
else {
   // The print interaction controller is not available.
}

• Apps that link against iOS SDK 4.1 and earlier must use the NSClassFromString function to see whether a class is defined. If the function returns a value other thannil, you may use the class. For example:

Class splitVCClass = NSClassFromString(@"UISplitViewController");

if (splitVCClass)
{
   UISplitViewController* mySplitViewController = [[splitVCClass alloc] init];
   // Configure the split view controller.
}

• To determine whether a C-based function is available, perform a Boolean comparison of the function name toNULL. If the symbol is not NULL, you can use the function. For example:

if (UIGraphicsBeginPDFPage != NULL)
{
    UIGraphicsBeginPDFPage();
}

SDK Compatibility Guide

Launching in Landscape Mode

If, however, your app supports landscape but not portrait orientations, perform the following tasks to make it launch in landscape mode initially:

• Add the UIInterfaceOrientation key to your app’s Info.plist file and set the value of this key to eitherUIInterfaceOrientationLandscapeLeft or UIInterfaceOrientationLandscapeRight.

• Lay out your views in landscape mode and make sure that their layout or autosizing options are set correctly.

• Override your view controller’s shouldAutorotateToInterfaceOrientation: method and return YES for the left or right landscape orientations andNO for portrait orientations.

Tips for Developing a VoIP App

A Voice over Internet Protocol (VoIP) app allows the user to make phone calls using an Internet connection instead of the device’s cellular service. Such an app needs to maintain a persistent network connection to its associated service so that it can receive incoming calls and other relevant data.

Communicating with Other Apps

Apps that support custom URL schemes can use those schemes to receive messages. Some apps use URL schemes to initiate specific requests.

Apple provides built-in support for the http, mailto,tel, and sms URL schemes. It also supports http–based URLs targeted at the Maps, YouTube, and iPod apps. The handlers for these schemes are fixed and cannot be changed. If your URL type includes a scheme that is identical to one defined by Apple, the Apple-provided app is launched instead of your app.

To communicate with an app using a custom URL, create an NSURL object with some properly formatted content and pass that object to the openURL: method of the shared UIApplication object. The openURL: method launches the app that registered to receive URLs of that type and passes it the URL. At that point, control passes to the new app.

The following code fragment illustrates how one app can request the services of another app (“todolist” in this example is a hypothetical custom scheme registered by an app):

NSURL *myURL = [NSURL URLWithString:@"todolist://www.acme.com?Quarterly%20Report#200806231300"];

[[UIApplication sharedApplication] openURL:myURL];

If your app defines a custom URL scheme, it should implement a handler for that scheme as described in “Implementing Custom URL Schemes.” For more information about the system-supported URL schemes, including information about how to format the URLs, see Apple URL Scheme Reference.

Implementing Custom URL Schemes

If your app can receive specially formatted URLs, you should register the corresponding URL schemes with the system. A custom URL scheme is a mechanism through which third-party apps can communicate with each other. Apps often use custom URL schemes to vend services to other apps. For example, the Maps app supports URLs for displaying specific map locations.

Handling URL Requests

Launching an app to open a URL

Waking a background app to open a URL:

Apple URL Scheme Reference

Showing and Hiding the Keyboard

The appearance of the keyboard is tied to the responder status of views. If a view is able to become the first responder, the system shows the keyboard whenever that view actually becomes the first responder. When the user taps another view that does not support becoming the first responder, the system hides the keyboard if it is currently visible. In UIKit, only views that support text entry can become the first responder by default. Other views must override the canBecomeFirstResponder method and return YES if they want the keyboard to be shown.

Normally, user taps dictate which view becomes the first responder in your app, but you can force a view to become the first responder too. Calling the becomeFirstResponder method any responder object causes that object to try to become the first responder. If that responder object is able to become the first responder, the custom input view (or the standard keyboard) is shown automatically.

Text Programming Guide for iOS

Turning Off Screen Locking

To disable screen locking, set the idleTimerDisabled property of the shared UIApplication object to YES. Be sure to reset this property to NO when your app does not need to prevent screen locking.