CHAPTER 15: Grand Central Dispatch, Background Processing, and You

539

One complication here is that each of the calculate methods returns a value that we want to grab, so we must first create the variables using the __block storage modifier. This ensures the values set inside the blocks are made available to the code that runs later.

With this in place, build and run the app again. You’ll see that your efforts have paid off. What was once a ten-second operation now takes just seven seconds, thanks to the fact that we’re running both of the calculations simultaneously.

Obviously, our contrived example gets the maximum effect because these two “calculations” don’t actually do anything but cause the thread they’re running on to sleep. In a real application, the speedup would depend on what sort of work is being done and which resources are available. The performance of CPU-intensive calculations is helped by this technique only if multiple CPU cores are available. At the time of this writing, only the latest iOS devices—the iPhone 4S and iPad 2—have more than one CPU core. Other uses, such as fetching data from multiple network connections at once, would see a speed increase even with just one CPU.

As you can see, GCD is not a panacea. Using GCD won’t automatically speed up every application. But by carefully applying these techniques at those points in your app where speed is essential, or where you find that your application feels like it’s lagging in its responses to the user, you can easily provide a better user experience, even in situations where you can’t improve the real performance.

Background Processing

Another important addition that arrived with iOS 4 is the introduction of background processing. This allows your apps to run in the background—in some circumstances, even after the user has pressed the home button.

This functionality should not be confused with the true multitasking that modern desktop operating systems now feature, where all the programs you launch remain resident in the system RAM until you explicitly quit them. iOS devices are still too low on RAM to be able to pull that off very well. Instead, this background processing is meant to allow applications that require specific kinds of system functionality to continue to run in a constrained manner. For instance, if you have an app that plays an audio stream from an Internet radio station, iOS will let that app continue to run, even if the user switches to another app. Beyond that, it will even provide standard pause and volume controls in the iOS system taskbar (the bar that appears at the bottom when you double-tap the home button) while your app is playing audio.

www.it-ebooks.info

540	CHAPTER 15: Grand Central Dispatch, Background Processing, and You

NOTE: The background processing features are available only on devices that meet a certain minimum hardware standard. At the time of this writing, this includes the iPhone 3GS and beyond, the thirdand fourth-generation iPod touch, and the iPad. Basically, if you have any

iPhone or iPod touch that was available before mid-2009, your device isn’t welcome on the

multitasking playground. Sorry!

Specifically, if you’re creating an app that plays audio, that wants continuous location updates, or that implements Voice over IP (VoIP) to let users send and receive phone calls on the Internet, you can declare this situation in your app’s Info.plist file, and the system will treat your app in a special way. This usage, while interesting, is probably not something that most readers of this book will be tackling, so we’re not going to delve into it here.

Besides running apps in the background, iOS also includes the ability to put an app into a suspended state after the user presses the home button. This state of suspended execution is conceptually similar to putting your Mac into sleep mode. The entire working memory of the application is held in RAM; it just isn’t executed while suspended. As a result, switching back to such an application is lightning-fast. This isn’t limited to special applications. In fact, it is the default behavior of any app you compile with the iOS 5 SDK (though this can be disabled by another setting in the Info.plist file). To see this in action, open your device’s Mail application and drill down into a message. Then press the home button, open the Notes application, and select a note. Now double-tap the home button and switch back to Mail. You’ll see that there’s no perceptible lag; it just slides into place as if it had been running all along.

For most applications, this sort of automatic suspending and resuming is all you’re likely to need. However, in some situations, your app may need to know when it’s about to be suspended and when it has just been awakened. The system provides ways of notifying an app about changes to its execution state via the UIApplication class, which has a number of delegate methods and notifications for just this purpose. We’ll show you how to use them later in this chapter.

When your application is about to be suspended, one thing it can do, regardless of whether it’s one of the special backgroundable application types, is request a bit of additional time to run in the background. The idea is to make sure your app has enough time to close any open files, network resources, and so on. We’ll give you an example of this in a bit.

www.it-ebooks.info

CHAPTER 15: Grand Central Dispatch, Background Processing, and You

541

Application Life Cycle

Before we get into the specifics of how to deal with changes to your app’s execution state, let’s talk a bit about the various states:

Not Running: This is the state that all apps are in on a freshly rebooted device. An application that has been launched at any point after the device is turned on will return to this state only under specific conditions:

If its Info.plist includes the UIApplicationExitsOnSuspend key (with its value set to YES)

If it was previously Suspended and the system needs to clear out some memory

If it crashes while running

Active: This is the normal running state of an application when it’s displayed on the screen. It can receive user input and update the display.

Background: In this state, an app is given some time to execute some code but can’t directly access the screen or get any user input. All apps enter this state briefly when the user presses the home button; most of them quickly move on to the Suspended state. Apps that want to run in the background stay here until they’re made Active again.

Suspended: A Suspended app is frozen. This is what happens to normal apps after their brief stint in the Background state. All the memory the app was using while it was active is held just as it was. If the user brings the app back to the Active state, it will pick up right where it left off. On the other hand, if the system needs more memory for whichever app is currently Active, any Suspended apps may be terminated (and placed back into the Not Running state) and their memory freed for other use.

Inactive: An app enters the Inactive state only as a temporary rest stop between two other states. The only way an app can stay Inactive for any length of time is if the user is dealing with a system prompt (such as those shown for an incoming call or SMS message) or if the user has locked the screen. This state is basically a sort of limbo.

State-Change Notifications

To manage changes between these states, UIApplication defines a number of methods that its delegate can implement. In addition to the delegate methods, UIApplication also defines a matching set of notification names (see Table 15–1). This allows other

www.it-ebooks.info

542	CHAPTER 15: Grand Central Dispatch, Background Processing, and You

objects besides the app delegate to register for notifications when the application’s state changes.

Table 15–1. Delegate Methods for Tracking Your Application’s Execution State and Their Corresponding Notification Names

Delegate Method	Notification Name

application:didFinishLaunchingWithOptions: UIApplicationDidFinishLaunchingNotification

applicationWillResignActive: UIApplicationWillResignActiveNotification

applicationDidBecomeActive: UIApplicationDidBecomeActiveNotification

applicationDidEnterBackground: UIApplicationDidEnterBackgroundNotification

applicationWillEnterForeground: UIApplicationWillEnterForegroundNotification

applicationWillTerminate: UIApplicationWillTerminateNotification

Note that each of these methods is directly related to one of the running states: Active, Inactive, and Background. Each delegate method is called (and each notification posted) in only one of those states. The most important state transitions are between Active and other states. Some transitions, like from Background to Suspended, occur without any notice whatsoever. Let’s go through these methods and discuss how they’re meant to be used.

The first of these, application:didFinishLaunchingWithOptions:, is one you’ve already seen many times in this book. It’s the primary way of doing application-level coding directly after the app has launched.

The next two methods, applicationWillResignActive: and applicationDidBecomeActive:, are both used in a number of circumstances. If the user presses the home button, applicationWillResignActive: will be called. If the user later brings the app back to the foreground, applicationDidBecomeActive: will be called. The same sequence of events occurs if the user receives a phone call. To top it all off, applicationDidBecomeActive: is also called when the application launches for the first time! In general, this pair of methods brackets the movement of an application from the Active state to the Inactive state. They are good places to enable and disable any animations, in-app audio, or other items that deal with the app’s presentation to the user. Because of the multiple situations where applicationDidBecomeActive: is used, you may want to put some of your app initialization code there instead of in application:didFinishLaunchingWithOptions:. Note that you should not assume in applicationWillResignActive: that the application is about to be sent to the background, because it may just be a temporary change that ends up with a move back to the Active state.

After those methods come applicationDidEnterBackground: and applicationWillEnterForeground:, which have a slightly different usage area: dealing with an app that is definitely being sent to the background.

www.it-ebooks.info