Bleeding Edge Press Developing an iOS 7 Edge (2013)

4. Multitasking in iOS 7

IN THIS CHAPTER

· Examples of the Background Fetch and Background Transfer Service APIs

· A discussion of fetch intervals and app usage pattern observations

· Tips for getting started with the Remote Notification API

So far we've discussed migrating the look and feel of your app from iOS 6 to iOS 7 and shown how to use the new Dynamic Text and Text to Speech APIs to design for accessibility. In this chapter we introduce the new multitasking APIs and illustrate how we can build an app that refreshes its content before the user opens it.

Keeping users engaged with an app is critical to the success of many businesses. Its often cheaper to up-sell or cross-sell to the existing user base than acquire new users. Without an engaging app, the acquisition costs will be lost as will the opportunity to up-sell or cross-sell that user on other paid products. One of the best strategies for ensuring a loyal user base is to feature fresh, relevant content and a snappy, easy-to-use interface.

Apple's iOS has long supported multitasking for specific background tasks, such as playing music and sending email, which were exclusive to applications developed by Apple and partners. The introduction of iOS 6 brought background tasks that allowed third-party developers to keep an application alive long enough to finish a database transaction, upload a file, or encode a short video. However, these tasks prevented the device from sleeping, adding unnecessary strain to the user's battery, and were difficult to recover from errors in the case of low battery or intermittent network connection. Fortunately, iOS 7 has introduced several new multitasking APIs that makes building such apps easier than ever before.

In iOS 7, Apple introduced new APIs that allow developers to perform more tasks in the background with less strain on the user's battery, including Background Fetch, Remote Notifications, and Background Transfer Service.

We'll explore these new APIs in the context of building an application that displays a random image of an animal to the user. Think of it like "Hot or Not" but with animals instead of people and no voting. Before we can delve into the new APIs, however, we first need to understand the changes to how iOS handles background tasks that make them possible.

Background Task Changes

In iOS 6, background tasks keep the device awake until the task has completed, even if the device is locked. Over the course of a day, the number of applications and tasks doing this causes severe strain on the user's battery.

The background task model has been changed to improve battery life in iOS 7. Unlike in previous versions of iOS, apps will not keep a device awake; the device goes to sleep shortly after a user locks their phone. Instead of a single app or background task keeping the phone awake, iOS now coalesces requests for background processing from multiple apps into shared, opportunistic time slices. These times are opportunistic in the sense that the requesting apps are allowed to process when the phone is already awake to check mail, receive a text message or push notification.

Its important to note that the amount of time available for an app to execute a background task isn't necessarily reduced, its just not guaranteed to be contiguous. This increases the complexity of developing background tasks that can handle errors, device restarts, and other unexpected conditions. For this reason, Apple provided the Background Transfer API to simplify the most common long-running background task: enqueuing large uploads and downloads.

In addition to the changes to the background task model, Apple also expanded user's ability to control which applications are allowed to run in the background. The user can swipe up to remove an app from App Switcher as in iOS 6; however, in iOS 7 this also stops the application from running in the background. Applications won't be launched in the background if the user has removed the app from App Switcher. There's also a new "Background App Refresh" settings dialog under "Settings > General Settings" which gives the user explicit control over which applications are granted the ability to be launched and resumed in the background.

Background Fetch

With Background Fetch, an application can refresh its content before the user opens it. In iOS 6 and earlier, the typical experience of a user launching an application is to immediately wait several seconds for the app to refresh its content. Background fetch enables the iOS 7 experience of allowing the user to instead start using the app immediately.

An application using the Background Fetch API will be launched in the background periodically based upon the user's actual usage patterns for the app. The goal of the iOS scheduler is for an app to complete a background fetch immediately prior to the user launching it to give the app the opportunity to have the freshest content possible. For example, if a user typically uses app XYZ at noon and app ABC at 6pm, then iOS will instruct XYZ to perform a background fetch just before noon and app ABC just before 6pm.

Apple gives developers a small bit of control over timing when the background fetch will be initiated. This control comes in the form of background fetch intervals. Before we delve into the details of implementing background fetch in an app, we must first understand the various background fetch intervals available in iOS 7.

Background Fetch Intervals

There are three background fetch intervals available:

1. UIApplicationBackgroundFetchIntervalNever

2. UIApplicationBackgroundFetchIntervalMinimum

3. Custom background fetch interval specified in seconds

The default interval is UIApplicationBackgroundFetchIntervalNever, which instructs iOS to never launch the app to perform a background fetch. In the majority case where the content is tailored for the user (requiring a user login), this default makes the most sense. Once the user has authenticated, the app should update the fetch interval to one of the other two options. Conversely, when the user logs out of the app, the fetch interval should be restored such that it doesn't perform anymore background fetches.

The second option, UIApplicationBackgroundFetchIntervalMinimum, allows iOS to make an intelligent decision about when to launch or resume the app for performing a background fetch. This is the primary mechanism by which iOS coalesces background task requirements and applies its knowledge about the user's application usage patterns. It is the recommended fetch interval in most cases.

The last option allows application developers to specify a minimum fixed time during which a background fetch will not be performed. If the value is set to 60, then its guaranteed that a background fetch will not be performed for the next hour. However, the fetch may take place at any time after that. This option is not so much of an "interval" as a hint to iOS about the application's data constraints. During the launch at WWDC, Apple gave the example of a weather application that polls personal weather stations. Because polling these stations is an expensive operation, the backend server was configured to only poll once per hour. Thus, fetching more frequently than once per hour would be a waste of user battery life and server resources.

Implementing Background Fetch

There are three steps to using the Background Fetch API in an application.

1. Enable the Background Fetch background mode capability.

2. Enable fetching by configuring a fetch interval

3. Implement the new UIApplicationDelegate application:performFetchWithCompletionHandler: callback

Apple launched Xcode 5 along with iOS 7 at WWDC 2013, which makes the first step trivial. Go to the new Capabilities pane for your project, enable "Background Modes" and check the box next to "Background fetch". As you can see from the note in the image below, this automatically completes the step of adding the required background modes to the info plist file for you.

The step to enable fetching is equally easy, requiring only a single line of code. Now that we understand the various background fetch intervals, we can select the recommended interval of UIApplicationBackgroundFetchIntervalMinimum for our example BepBop app. Because our demo won't be displaying content tailored for users, we simply set the fetch interval in the standard application:didFinishLaunchingWithOptions: delegate callback.

0001:- (BOOL)application:(UIApplication*)application didFinishLaunchingWithOptions:(NSDictionary*)launchOptions
0002:{
0003: if (IS_IOS_7) {
0004: [[UIApplication sharedApplication] setMinimumBackgroundFetchInterval:UIApplicationBackgroundFetchIntervalMinimum];
0005: // other iOS 7 specific setup ...
0006: }
0007: // more setup ...
0008: return YES;
0009:}

Note that we've made this call behind a simple IS_IOS_7 macro, defined as:

#define IS_IOS_7 ([[[UIDevice currentDevice] systemVersion] floatValue] > 6.10001:

This allows us to support both iOS 7 and lesser versions. And yes, we mean that in a derogatory manner. Alternatively, you could check for the existence of the setMinimumBackgroundFetchInterval method on the UIApplicationclass.

The final step is to actually implement the background fetch. Recall that the demo app that we're developing simply displays images of random animals. Its Hot-or-Not Animal Farm Edition. We start by implementing the UIApplicationDelegate application:performFetchWithCompletionHandler: callback.

0001:-(void)application:(UIApplication *)application performFetchWithCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler
0002:{
0003: [[BEPBackgroundDownloadHandler sharedInstance] refreshWithCompletionHandler:^(BOOL didReceiveNewImage, NSError *error) {
0004: if (error) {
0005: completionHandler(UIBackgroundFetchResultFailed);
0006: } else if (didReceiveNewImage) {
0007: [UIApplication sharedApplication].applicationIconBadgeNumber++;
0008: completionHandler(UIBackgroundFetchResultNewData);
0009: } else {
0010: completionHandler(UIBackgroundFetchResultNoData);
0011: }
0012: }];
0013:}

Its critically important to always call the background fetch completion handler. iOS will terminate any app which fails to do so. This is also the opportunity to update the snapshot for presentation in the App Switcher and to setup the state for next launch by the user. iOS saves the state restoration archive immediately after the completion handler is called.

An easy rule to ensure that the completion handler is invoked for each performFetchWithCompletionHandler operation is to never store the completion handler; pass it down the call stack to the location at which it will be invoked. If the completion handler is stored and another path also requests a refresh before the first is complete, the original completion listener may be overwritten and thus never called. So just don't store it.

There are three possible completion handler statuses: UIBackgroundFetchResultNewData, UIBackgroundFetchResultNoData, and UIBackgroundResultFailed. The completion handler should always be called with the proper status. This gives iOS information about the operation of the app. This is presumably used in deciding the next interval in which to perform a background fetch.

That's all that is required for enabling an app to perform background fetches. We can now see the application icon badge increment as background fetches occur and new content is accumulated.

However, testing requires two different mechanisms because there are two scenarios under which performFetchWithCompletionHandler may be called depending on whether the application is already running. If the application is not running, it will be launched. Otherwise, iOS will simply resume the inactive application. Each of these scenarios is tested differently.

The easiest way to test the launch case is to create a new scheme. Go to manage schemes:

Then duplicate the existing scheme:

And now enable the "Launch due to a background fetch event" option under the Options panel:

When this scheme is activated and run, it will launch a new instance of the app.

For testing the resume case, Apple has added a new menu option to Xcode 5: "Simulate Background Fetch". It can be found under the Debug menu.

When the application is running, selecting this menu option will put the app into the background and then trigger the background fetch. In our testing, we've found a few bugs in the interaction between Background Fetch and the Background Transfer Service when this option is used and the app is not in the foreground. This will be further discussed below.

Remote Notifications