01.02.2014 Views

Objective-C Fundamentals

Objective-C Fundamentals

Objective-C Fundamentals

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Practical uses of runtime type introspection<br />

175<br />

It’s now common to want to develop an application that can use features specific to<br />

a newer version of the iOS operating system yet still be able to run the application on a<br />

device with an older version of the operating system that doesn’t provide the feature.<br />

Using a number of techniques discussed in this chapter, this goal can often be achieved.<br />

The first technique to be aware of is the macro UI_USER_INTERFACE_IDIOM, which<br />

can be used as follows:<br />

if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad) {<br />

... this code will only execute if the device is an iPad ...<br />

}<br />

The UI_USER_INTERFACE_IDIOM macro can be used to determine if the current device<br />

is an iPad or iPhone and to conditionally change the behavior of an application to<br />

make sure the look and feel integrates well with the slightly different usage model of<br />

both platforms.<br />

In other cases, a class may exist in multiple versions of the iOS software development<br />

kit (SDK), yet have new properties or methods added to it. In these scenarios,<br />

you can use the respondsToSelector: message to determine if the device the application<br />

is currently running on provides the specified property or method.<br />

As an example, the version of iOS that introduced multitasking capabilities introduced<br />

a property named isMultitaskingSupported on the UIDevice class to determine<br />

if the current device supports multitasking (devices such as the iPhone 3G can’t<br />

multitask even though they can run the latest version of iOS). If, however, an iPhone<br />

owner hasn’t updated the device to the newest iOS version, it’s possible that attempting<br />

to access this property will cause an exception due to the class not responding to<br />

the selector. The workaround is as follows:<br />

UIDevice *device = [UIDevice currentDevice];<br />

BOOL backgroundSupported = NO;<br />

if ([device respondsToSelector:@selector(isMultitaskingSupported)])<br />

backgroundSupported = device.multitaskingSupported;<br />

In this scenario, the device is assumed not to support background processing, but if<br />

the UIDevice object indicates it responds to the isMultitaskingSupported property,<br />

you query it for the final answer.<br />

In cases in which an entire class has been introduced in a new version of iOS, you can<br />

check for the availability of the class by using a code sample similar to the following:<br />

if ([UIPrintInteractionController class]) {<br />

... make use of the UIPrintInteractionController class ...<br />

} else {<br />

... do something if the UIPrintInteractionController isn't available ...<br />

}<br />

If the UIPrintInteractionController (or any other class placed in a similar code<br />

snippet) isn’t available, the class message responds with nil, which evaluates to false.<br />

Otherwise, it returns a non-nil value and proceeds to execute the code in the first<br />

block of the if statement.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!