Threading Basics

Before we start implementing solutions, let’s go over some concurrency basics. This is far from a complete description of threading in iOS or threading in general. I just want to explain enough for you to understand what we’re doing in this chapter. Most modern operating systems (including, of course, iOS) support the notion of threads of execution. Each process can contain multiple threads, which all run concurrently. If there’s just one processor core, the operating system will switch between all executing threads, much like it switches between all executing processes. If more than one core is available, the threads will be distributed among them, just as processes are.

All threads in a process share the same executable program code and the same global data. Each thread can also have some data that is exclusive to the thread. Threads can make use of a special structure called a mutex (short for mutual exclusion) or a lock, which can ensure that a particular chunk of code can’t be run by multiple threads at once. This is useful for ensuring correct outcomes when multiple threads access the same data simultaneously, by locking out other threads when one thread is updating a value (in what’s called a critical sectionof your code).

A common concern when dealing with threads is the idea of code being thread-safe. Some software libraries are written with thread concurrency in mind and have all their critical sections properly protected with mutexes. Some code libraries aren’t thread-safe. For example, in Cocoa Touch, the Foundation framework is generally considered to be thread-safe. However, the UIKit framework (containing the classes specific to building GUI applications , such as UIApplication, UIView and all its subclasses, and so on) is, for the most part, not thread-safe. (Some UIKit functionality such as drawing is considered thread-safe however.) This means that in a running an iOS application, all method calls that deal with any UIKit objects should be executed from within the same thread, which is commonly known as the main thread. If you access UIKit objects from another thread, all bets are off. You are likely to encounter seemingly inexplicable bugs (or, even worse, you won’t experience any problems, but some of your users will be affected by them after you ship your app).

Units of Work

The problem with the threading model described earlier is that, for the average programmer, writing error-free, multithreaded code is nearly impossible. This is not meant as a critique of our industry or of the average programmer’s abilities; it’s simply an observation. The complex interactions you must account for in your code when synchronizing data and actions across multiple threads are really just too much for most people to tackle. Imagine that 5% of all people have the capacity to write software at all. Only a small fraction of those 5% are really up to the task of writing heavy-duty multithreaded applications. Even people who have done it successfully will often advise others to not follow their example.

Fortunately, there are alternatives. It is possible to implement some concurrency without too much low-level detailed work. Just as we have the ability to display data on the screen without directly poking bits into video RAM and to read data from disk without interfacing directly with disk controllers, we can also leverage software abstractions that let us run our code on multiple threads without requiring us to do much directly with the threads.

The solutions Apple encourages us to use center around the idea of splitting up long-running tasks into units of work and putting those units into queues for execution. The system manages the queues for us, executing units of work on multiple threads. We don’t need to start or manage the background threads directly, and we are freed from much of the bookkeeping that’s usually involved in implementing multithreaded applications; the system takes care of that for us.

GCD: Low-Level Queuing

This idea of putting units of work into queues that can be executed in the background, with the system managing the threads for you, provides power and greatly simplifies many development situations where concurrency is needed. GCD made its debut on OS X (now macOS) several years ago, providing the infrastructure to do just that. A couple of years later, this technology came to the iOS platform as well. GCD puts some great concepts—units of work, painless background processing, and automatic thread management—into a C interface that can be used not only with Objective-C, but also with C , C++, and, of course, Swift. To top things off, Apple has made its implementation of GCD open source, so it can be ported to other Unix-like operating systems, as well.

One of the key concepts of GCD is the queue. The system provides a number of predefined queues, including a queue that’s guaranteed to always do its work on the main thread. It’s perfect for the non-thread-safe UIKit. You can also create your own queues—as many as you like. GCD queues are strictly first-in, first-out (FIFO) . Units of work added to a GCD queue will always be started in the order they were placed in the queue. That said, they may not always finish in the same order, since a GCD queue will automatically distribute its work among multiple threads, if possible.

GCD accesses a pool of threads that are reused throughout the lifetime of the application. It tries to maintain a number of threads appropriate for the machine’s architecture. It automatically takes advantage of a more powerful machine by utilizing more processor cores when it has work to do. Until a few years ago, iOS devices were all single-core, so this wasn’t much of an issue. But now that all iOS devices released in the past few years feature multicore processors, GCD has become truly useful.

GCD uses closures to encapsulate the code to be added to a queue. Closures are first-class language citizens in Swift—you can assign a closure to a variable, pass one to a method, or return one as the result of a method call. Closures are the equivalent of Objective-C’s blocks and similar features, sometimes referred to using the term lambdas, in other programming languages, such as Python. Much like a method or function, a closure can take one or more parameters and specify a return value, although closures used with GCD can neither accept arguments nor return a value. To declare a closure variable, you simply assign to it some code wrapped in curly braces, optionally with arguments:

// Declare a closure variable "loggerClosure" with no parameters
// and no return value.
let loggerClosure = {
    print("I'm just glad they didn't call it a lambda")
}

You can execute the closure in the same way as you call a function :

// Execute the closure, producing some output in the console.
loggerClosure()

Improving SlowWorker

To see how to use closures with GCD, let’s revisit SlowWorker’s doWork() method. It currently looks like this:

    @IBAction func doWork(_ sender: AnyObject) {
            let startTime = NSDate()
            self.resultsTextView.text = ""
            let fetchedData = self.fetchSomethingFromServer()
            let processedData = self.processData(fetchedData)
            let firstResult = self.calculateFirstResult(processedData)
            let secondResult = self.calculateSecondResult(processedData)
            let resultsSummary =
                "First: [(firstResult)]
Second: [(secondResult)]"
            self.resultsTextView.text = resultsSummary
            let endTime = NSDate()
            print("Completed in (endTime.timeIntervalSince(startTime as Date)) seconds")
    }

We can make this method run entirely in the background by wrapping all the code in a closure and passing it to a GCD function called DispatchQueue. This function takes two parameters : a GCD queue and the closure to assign to the queue. Make the changes in Listing 15-2 to your copy of doWork().

Listing 15-2. Modifications to the doWork Method to Use GCD

    @IBAction func doWork(sender: AnyObject) {
        let startTime = NSDate()
        resultsTextView.text = ""
        let queue = DispatchQueue.global(qos: .default)
        queue.async {
            let fetchedData = self.fetchSomethingFromServer()
            let processedData = self.processData(fetchedData)
            let firstResult = self.calculateFirstResult(processedData)
            let secondResult = self.calculateSecondResult(processedData)
            let resultsSummary =
                "First: [(firstResult)]
Second: [(secondResult)]"
            self.resultsTextView.text = resultsSummary
            let endTime = NSDate()
            print("Completed in (endTime.timeIntervalSince(startTime as Date)) seconds")
        }
    }

The first changed line grabs a preexisting global queue that’s always available, using the DispatchQueue.global() function. That function takes one arguments letting you specify a priority. If you specify a different priority in the argument you will actually get a different global queue, which the system will prioritize differently. For now, we’ll stick with the default global queue.

The queue is then passed to the queue.async() function, along with the closure. GCD takes the closure and puts it on the queue, from where it will be scheduled to run on a background thread and executed one step at a time, just as when it was running in the main thread.

Note that we defined a variable called startTime just before the closure is created, and then use its value at the end of the closure. Intuitively, this doesn’t seem to make sense because, by the time the closure is executed, the doWork() method has returned, so the NSDate instance that the startTime variable is pointing to should already be released! This is a crucial point to understand about closures: if a closure accesses any variables from “the outside” during its execution, then some special setup happens when the closure is created, allowing it to continue to access to them. All of this is done automatically by the Swift compiler and runtime—you don’t need to do anything special to make it happen.

    @IBAction func doWork(sender: AnyObject) {
        let startTime = NSDate()
        resultsTextView.text = ""
        let queue = DispatchQueue.global(attributes: DispatchQueue.GlobalAttributes.qosDefault)
        queue.async {
            let fetchedData = self.fetchSomethingFromServer()
            let processedData = self.processData(fetchedData)
            let firstResult = self.calculateFirstResult(processedData)
            let secondResult = self.calculateSecondResult(processedData)
            let resultsSummary =
                "First: [(firstResult)]
Second: [(secondResult)]"
            DispatchQueue.main.async {
                self.resultsTextView.text = resultsSummary
            }
            let endTime = NSDate()
            print("Completed in (endTime.timeIntervalSince(startTime as Date)) seconds")

        }
    }

    @IBOutlet var spinner : UIActivityIndicatorView!              

    @IBAction func doWork(sender: AnyObject) {
        let startTime = NSDate()
        resultsTextView.text = ""
        startButton.isEnabled = false
        spinner.startAnimating()
        let queue = DispatchQueue.global(qos: .default)
        queue.async {
            let fetchedData = self.fetchSomethingFromServer()
            let processedData = self.processData(fetchedData)
            let firstResult = self.calculateFirstResult(processedData)
            let secondResult = self.calculateSecondResult(processedData)
            let resultsSummary =
                "First: [(firstResult)]
Second: [(secondResult)]"
            DispatchQueue.main.async {
                self.resultsTextView.text = resultsSummary
                self.startButton.isEnabled = true
                self.spinner.stopAnimating()
            }
            let endTime = NSDate()
            print("Completed in (endTime.timeIntervalSince(startTime as Date)) seconds")

        }
    }

    @IBAction func doWork(_ sender: AnyObject) {
        let startTime = Date()
        self.resultsTextView.text = ""
        startButton.isEnabled = false
        spinner.startAnimating()
        let queue = DispatchQueue.global(qos: .default)
        queue.async {
            let fetchedData = self.fetchSomethingFromServer()
            let processedData = self.processData(fetchedData)
            var firstResult: String!
            var secondResult: String!
            let group = DispatchGroup()

            queue.async(group: group) {
                firstResult = self.calculateFirstResult(processedData)
            }
            queue.async(group: group) {
                secondResult = self.calculateSecondResult(processedData)
            }

            group.notify(queue: queue) {
                let resultsSummary = "First: [(firstResult!)]
Second: [(secondResult!)]"
                DispatchQueue.main.async {
                    self.resultsTextView.text = resultsSummary
                    self.startButton.isEnabled = true
                    self.spinner.stopAnimating()
                }
                let endTime = Date()                                                                                      
                print("Completed in (endTime.timeIntervalSince(startTime)) seconds")
            }
        }
    }

var firstResult: String
var secondResult: String

var firstResult: String!              
var secondResult: String!              

Creating State Lab

In Xcode, create a new project based on the Single View Application template and name it State Lab. Initially at least, this app won’t display anything but the default white screen it’s born with. Later, we’ll make it do something more interesting, but for now, all the output it’s going to generate will end up in the Xcode console. The AppDelegate.swift file already contains all the methods we’re interested in. We just need to add some logging, as shown in bold. Note that we’ve also removed the comments from these methods, as shown in Listing 15-6, just for the sake of brevity.

Listing 15-6. The AppDelegate.swift Logging Methods

    func application(_ application: UIApplication,
                     didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
        print(#function)
        return true
    }

    func applicationWillResignActive(_ application: UIApplication) {
        print(#function)
    }

    func applicationDidEnterBackground(_ application: UIApplication) {
        print(#function)
    }

    func applicationWillEnterForeground(_ application: UIApplication) {
        print(#function)
    }

    func applicationDidBecomeActive(_ application: UIApplication) {
        print(#function)
    }

    func applicationWillTerminate(_ application: UIApplication) {
        print(#function)
    }

You may be wondering about the value that’s being passed to the print() function in each of these methods: the literal expression #function evaluates to the name of the method in which it appears. Here, we are using it to get the current method name without needing to retype it or copy and paste it into each of the lifecycle methods.

Exploring Execution States

Now build and run the app and take a look at the console (View ➤ Debug Area ➤ Activate Console), where you should see something like this:

application(_:didFinishLaunchingWithOptions:)
applicationDidBecomeActive

among a number of other messages. You can use the search field below the console output to filter what you observe.

Here, you can see that the application has successfully launched and been moved into the Active state. Now press the home button (if you’re using the simulator, you’ll have to do this by selecting Hardware ➤ Home from the simulator’s menu or ⇧⌘H on the keyboard). You should see the following in the console:

applicationWillResignActive
applicationDidEnterBackground

These two lines show the app actually transitioning between two states: it first becomes Inactive, and then goes to Background. What you can’t see here is that the app also switches to a third state: Suspended. Remember that you do not get any notification that this has happened; it’s completely outside your control. Note that the app is still live in some sense, and Xcode is still connected to it, even though it’s not actually getting any CPU time. Verify this by tapping the app’s icon to relaunch it, which should produce this output:

applicationWillEnterForeground
applicationDidBecomeActive

There you are, back in business. The app was previously Suspended, is woken up to Inactive, and then ends up Active again. So, what happens when the app is really terminated? Tap the home button again and you’ll see this:

applicationWillResignActive
applicationDidEnterBackground

Now double-tap the home button (or on the simulator, press ⇧⌘HH—you need to press the H key twice). The sideways-scrolling screen of apps should appear. Press and swipe upward on the State Lab screenshot until it flies offscreen, killing the application. You should see something like:

2016-07-21 10:15:40.201746 temp[2825:864732] [Common] <FBSUIApplicationWorkspaceClient [0x6080000f8700]>: Received exit event
applicationDidEnterBackground
applicationWillTerminate

There’s one more interesting interaction to examine here. It’s what happens when the system shows an alert dialog, temporarily taking over the input stream from the app and putting it into an Inactive state. This state can be readily triggered only when running on a real device instead of the simulator, using the built-in Messages app. Messages, like many other apps, can receive messages from the outside and display them in several ways.

To see how these are set up, run the Settings app on your device, choose Notifications from the list, and then select the Messages app from the list of apps. The hot “new” way to show messages, which debuted way back in iOS 5, is called Banners. This works by showing a small banner overlaid at the top of the screen, which doesn’t need to interrupt whatever app is currently running. What we want to show is the bad old Alerts method, which makes a modal panel appear in front of the current app, requiring a user action. Under the heading ALERT STYLE WHEN UNLOCKED, select Alerts so that the Messages app turns back into the kind of pushy jerk that users of iOS 4 and earlier always had to deal with.

Now back to your computer. In Xcode, use the pop-up at the upper left to switch from the simulator to your device, and then hit the Run button to build and run the app on your device. Now all you need to do is send a message to your device from the outside. If your device is an iPhone, you can send it an SMS message from another phone. If it’s an iPod touch or an iPad, you’re limited to Apple’s own iMessage communication, which works on all iOS devices, as well as OS X in the Messages app. Figure out what works for your setup, and send your device a message via SMS or iMessage. When your device displays the system alert showing the incoming message, this will appear in the Xcode console:

applicationWillResignActive

Note that our app didn’t get sent to the background. It’s in the Inactive state and can still be seen behind the system alert. If this app were a game or had any video, audio, or animations running, this is where we would probably want to pause them.

Press the Close button on the alert, and you’ll get this:

applicationDidBecomeActive

Now let’s see what happens if you decide to reply to the message instead. Send another message to your device, generating this:

applicationWillResignActive

This time, hit Reply, which switches you over to the Messages app. You should see the following flurry of activity:

applicationDidBecomeActive
applicationWillResignActive
applicationDidEnterBackground

Our app quickly becomes Active , becomes Inactive again, and finally goes to Background (and then, silently, Suspended).

Using Execution State Changes

So, what should we make of all this? Based on what was just demonstrated, it seems like there’s a clear strategy to follow when dealing with these state changes:

Handling the Inactive State

The simplest state change your app is likely to encounter is from Active to Inactive, and then back to Active. You may recall that this is what happens if your iPhone receives an SMS message while your app is running and displays it for the user. In this section, we’re going to make State Lab do something visually interesting so that you can see what happens if you ignore that state change. Next, I’ll show you how to fix it.

We’ll also add a UILabelto our display and make it move using Core Animation, which is a really nice way of animating objects in iOS.

Start by adding a UILabel in ViewController.swift:

class ViewController: UIViewController {
    private var label:UILabel!

Now let’s set up the label when the view loads. Modify the viewDidLoad() method as shown in Listing 15-7.

Listing 15-7. Our Modified viewDidLoad Method

    override func viewDidLoad() {
        super.viewDidLoad()
        // Do any additional setup after loading the view, typically from a nib.
        let bounds = view.bounds

        let labelFrame = CGRect(origin: CGPoint(x: bounds.origin.x, y: bounds.midY - 50) , size: CGSize(width:  bounds.size.width, height: 100))
        label = UILabel(frame: labelFrame)
        label.font = UIFont(name: "Helvetica", size:70)
        label.text = "Bazinga!"
        label.textAlignment = NSTextAlignment.center
        label.backgroundColor = UIColor.clear()
        view.addSubview(label)                                                                                                    
    }

This vertically centers the label in its parent view and makes it stretch across the full width of its parent. Next, let’s set up some animation. We’ll define two methods: one to rotate the label to an upside-down position :

    func rotateLabelDown() {
        UIView.animate(withDuration: 0.5, animations: {
                self.label.transform = CGAffineTransform(rotationAngle: CGFloat(M_PI))
            },
            completion: {(Bool) -> Void in
                self.rotateLabelUp()
            }
        )
    }

This one rotates it back to normal:

    func rotateLabelUp() {
        UIView.animate(withDuration: 0.5, animations: {
                self.label.transform = CGAffineTransform(rotationAngle: 0)
            },
            completion: {(Bool) -> Void in
                    self.rotateLabelDown()
            }
        )
    }

This deserves a bit of explanation. UIView defines a class method called animate(withDuration: completion:), which sets up an animation. Attributes that can be animated, which we set within the animations closure, don’t have an immediate effect on the receiver. Instead, Core Animation will smoothly transition that attribute from its current value to the new value we specify. This is what’s called an implicit animation, which is one of the main features of Core Animation. The completion closure lets us specify what will happen after the animation is complete. Note carefully the syntax of this closure:

            completion: {(Bool) -> Void in
                if self.animate {
                    self.rotateLabelDown()
                }
            }

The code in bold is the signature of the closure—it says that the closure is called with a single Boolean argument and returns nothing. The argument has a value of true if the animation completed normally, false if it was cancelled. In this example, we don’t make any use of this argument.

So, each of these methods sets the label’s transform property to a particular rotation angle, specified in radians, and uses the completion closure to call the other method, so the text will continue to animate back and forth forever.

Finally, we need to set up a way to kick-start the animation. For now, we’ll do this by adding this line at the end of viewDidLoad():

    rotateLabelDown();

Build and run the app. You should see the Bazinga! label rotate back and forth, as shown in Figure 15-4.

Figure 15-4. The State Lab application rotating the label

To test the Active ➤ Inactive transition , you really need to once again run this on an actual iPhone and send an SMS message to it from elsewhere. Build and run the app on an iPhone, and see that the animation is running along. Now send an SMS message to the device. When the system alert comes up to show the message, you’ll see that the animation keeps on running. That may be slightly comical, but it’s probably irritating for a user. We will use application state transition notifications to stop our animation when this occurs.

Our controller class will need to have some internal state to keep track of whether it should be animating at any given time. For this purpose, let’s add a property to the ViewController class :

class ViewController: UIViewController {
    private var label:UILabel!
    private var animate = false            

As you’ve seen, changes in the application state are notified to the application delegate, but since our class isn’t the application delegate, we can’t just implement the delegate methods and expect them to work. Instead, we sign up to receive notifications from the application when its execution state changes. Do this by adding the following code to the end of the viewDidLoad method in ViewController.swift :

        let center = NotificationCenter.default
        center.addObserver(self, selector: #selector(ViewController.applicationWillResignActive),
               name: Notification.Name.UIApplicationWillResignActive, object: nil)
         center.addObserver(self, selector: #selector(ViewController.applicationDidBecomeActive),
               name: NSNotification.Name.UIApplicationDidBecomeActive, object: nil)

This sets up the notifications so that each will call a method in our class at the appropriate time. Add the following methods to the ViewController class :

    func applicationWillResignActive() {
        print("VC: (#function)")
        animate = false
    }

    func applicationDidBecomeActive() {
        print("VC: (#function)")
        animate = true
        rotateLabelDown()
    }

These methods include the same method logging as before, just so you can see where the methods occur in the Xcode console . We added the preface "VC: " to distinguish this call from the similar calls in the delegate (VC is for view controller). The first of these methods just turns off the animate flag. The second turns the flag back on, and then actually starts up the animations again. For that first method to have any effect, we need to add some code to check the animate flag and keep on animating only if it’s enabled:

    func rotateLabelUp() {
        UIView.animate(withDuration: 0.5, animations: {
                self.label.transform = CGAffineTransform(rotationAngle: 0)
            },
            completion: {(Bool) -> Void in
                if self.animate {
                    self.rotateLabelDown()
                }
            }
        )
    }

We added this to the completion block of rotateLabelUp(), (and only there) so that our animation will stop only when the text is right-side up. Finally, since we are now starting the animation when the application becomes active, and this happens right after it is launched, we no longer need the call rotateLabelDown() in viewDidLoad(), so delete it:

override func viewDidLoad() {

    rotateLabelDown();              

    let center = NSNotificationCenter.default

Now build and run the app again, and you should see that it’s animating as before. Once again, send an SMS message to your iPhone. This time, when the system alert appears, you’ll see that the animation in the background stops as soon as the text is right-side up. Tap the Close button, and the animation starts back up.

Now you’ve seen what to do for the simple case of switching from Active to Inactive and back. The bigger task, and perhaps the more important one, is dealing with a switch to the background and then back to foreground.

Handling the Background State

As mentioned earlier, switching to the Background state is pretty important to ensure the best possible user experience. This is the spot where you’ll want to discard any resources that can easily be reacquired (or will be lost anyway when your app goes silent) and save information about your app’s current state, all without occupying the main thread for more than five seconds.

To demonstrate some of these behaviors, we’re going to extend State Lab in a few ways. First, we’re going to add an image to the display so that I can later show you how to get rid of the in-memory image. Then I’m going to show you how to save some information about the app’s state, so we can easily restore it later. Finally, I’ll show you how to make sure these activities aren’t taking up too much main thread time by putting all this work into a background queue.

Removing Resources When Entering the Background

Start by adding smiley.png from the 15 - Image folder in the book’s source archive to your project’s State Lab folder. Be sure to enable the check box that tells Xcode to copy the file to your project directory. Don’t add it to the Assets.xcassets asset catalog because that would provide automatic caching, which would interfere with the specific resource management we’re going to implement.

Now let’s add properties for both the image and an image view to ViewController.swift :

class ViewController: UIViewController {
    private var label:UILabel!
    private var smiley:UIImage!              
    private var smileyView:UIImageView!              
    private var animate = false

Next, set up the image view and put it on the screen by modifying the viewDidLoad() method , as shown in Listing 15-7.

Listing 15-7. Modified viewDidLoad Methods

    override func viewDidLoad() {
        super.viewDidLoad()
        // Do any additional setup after loading the view, typically from a nib.

        let bounds = view.bounds
        let labelFrame = CGRect(origin: CGPoint(x: bounds.origin.x, y: bounds.midY - 50) , size: CGSize(width:  bounds.size.width, height: 100))
        label = UILabel(frame:labelFrame)
        label.font = UIFont(name:"Helvetica", size:70)
        label.text = "Bazinga!"
        label.textAlignment = NSTextAlignment.center
        label.backgroundColor = UIColor.clear()

        // smiley.png is 84 x 84
        let smileyFrame = CGRect(x: bounds.midX - 42,
            y: bounds.midY/2 - 42, width: 84, height: 84)

        smileyView = UIImageView(frame:smileyFrame)
        smileyView.contentMode = UIViewContentMode.center
        let smileyPath =
            Bundle.main.pathForResource("smiley", ofType: "png")!
        smiley = UIImage(contentsOfFile: smileyPath)
        smileyView.image = smiley
        view.addSubview(smileyView)

        view.addSubview(label)

        let center = NotificationCenter.default
        center.addObserver(self, selector: #selector(ViewController.applicationWillResignActive),
                name: NSNotification.Name.UIApplicationWillResignActive, object: nil)
        center.addObserver(self, selector: #selector(ViewController.applicationDidBecomeActive),
                name: NSNotification.Name.UIApplicationDidBecomeActive, object: nil)
    }

Build and run the app. You’ll see the incredibly happy-looking smiley face toward the top of your screen, as shown in Figure 15-5.

Figure 15-5. The State Lab application rotating the label with the addition of a smiley icon

Next, press the home button to switch your app to the background, and then tap its icon to launch it again. You’ll see that when the app resumes, the label starts rotating again, as expected. All seems well, but in fact, we’re not yet optimizing system resources as well as we could. Remember that the fewer resources we use while our app is suspended, the lower the risk that iOS will terminate our app entirely. By clearing any easily re-created resources from memory when we can, we increase the chance that our app will stick around and therefore relaunch super-quickly.

Let’s see what we can do about that smiley face. We would really like to free up that image when going to the Background state and re-create it when coming back from the Background state. To do that, we’ll need to add two more notification registrations inside viewDidLoad():

        center.addObserver(self, selector: #selector(ViewController.applicationDidEnterBackground),
                    name: NSNotification.Name.UIApplicationDidEnterBackground, object: nil)
        center.addObserver(self, selector: #selector(ViewController.applicationWillEnterForeground),
                    name: NSNotification.Name.UIApplicationWillEnterForeground, object: nil)

And we want to implement the two new methods :

func applicationDidEnterBackground() {                  
    print("VC: (#function)")              
    self.smiley = nil;              
    self.smileyView.image = nil;              
}                  
func applicationWillEnterForeground() {                  
    print("VC: (__FUNCTION__)")              
    let smileyPath =              
        Bundle.main.path(forResource:"smiley", ofType:"png")!              
    smiley = UIImage(contentsOfFile: smileyPath)              
    smileyView.image = smiley              
}                  

Build and run the app, and repeat the same steps of backgrounding your app and switching back to it. You should see that, from the user’s standpoint, the behavior appears to be about the same. If you want to verify for yourself that this is really happening, comment out the contents of the applicationWillEnterForeground() method , and then build and run the app again. You’ll see that the image really does disappear.

Saving State When Entering the Background

Now that you’ve seen an example of how to free up some resources when entering the Background state, it’s time to think about saving state. Remember that the idea is to save information relevant to what the user is doing, so that if your application is later dumped from memory, users can still pick up right where they left off the next time they return.

The kind of state we’re talking about here is really application-specific, not view-specific. Do not confuse this with saving and restoring the locations of views or which screen of your application the user was looking at when it was last active—for that, iOS provides the state saving and restoration mechanism, which you can read about in the iOS App Programming Guide on Apple’s web site ( https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/StrategiesforImplementingYourApp/StrategiesforImplementingYourApp.html ). Here, we’re thinking about things like user preferences in applications for which you do not want to implement a separate settings bundle. Using the same UserDefaults API that we introduced you to in Chapter 12, you can quickly and easily save preferences from within the application and read them back later. Of course, if your application is not visually complex or you don’t want to use the state saving and restoration mechanism, you can save information that will allow you to restore its visual state in the user preferences, too.

The State Lab example is too simple to have real user preferences, so let’s take a shortcut and add some application-specific state to its one and only view controller. Add a property called index in ViewController.swift, along with a segmented control :

class ViewController: UIViewController {
    private var label:UILabel!
    private var smiley:UIImage!
    private var smileyView:UIImageView!
    private var segmentedControl:UISegmentedControl!
    private var index = 0
    private var animate = false

We’re going to allow the user to set the value of this property using a segmented control and we’re going to save it in the user defaults. We’re then going to terminate and relaunch the application, to demonstrate that we can recover the value of the property.

Next, move to the middle of the viewDidLoad() method, where you’ll create the segmented control, and add it to the view:

        smileyView.image = smiley
        segmentedControl =
            UISegmentedControl(items: ["One","Two", "Three", "Four"])
        segmentedControl.frame = CGRect(x: bounds.origin.x + 20, y: 50,
            width: bounds.size.width - 40, height: 30)
        segmentedControl.addTarget(self, action: #selector(ViewController.selectionChanged(_:)),
            for: UIControlEvents.valueChanged)

        view.addSubview(segmentedControl)
        view.addSubview(smileyView)

We also used the addTarget(_:action:forControlEvents) method to connect the segmented control to the selectionChanged() method, which we need to have called when the selected segment changes. Add the implementation of this method anywhere in the implementation of the ViewController class:

    func selectionChanged(_ sender:UISegmentedControl) {
            index = segmentedControl.selectedSegmentIndex;
    }

Now whenever the user changes the selected segment, the value of the index property will be updated.

Build and run the app. You should see the segmented control and be able to click its segments to select them one at a time. As you do so, the value of the index property will change, although you can’t actually see this happening. Background your app again by clicking the home button, bring up the task manager (by double-clicking the home button) and kill your app, and then relaunch it. When the application restarts, the index property will have a value of zero again and there will be no selected segment. That’s what we need to fix next.

Saving the value of the index property is simple enough; we just need one line of code to the end of the applicationDidEnterBackground() method in ViewController.swift:

func applicationDidEnterBackground() {                
    print("VC: (#function)")            
    self.smiley = nil;            
    self.smileyView.image = nil;            
    UserDefaults.standard.set(self.index,            
         forKey:"index")            
}                

But where should we restore the property value and use it to configure the segmented control? The inverse of this method, applicationWillEnterForeground(), isn’t what we want. When that method is called, the app has already been running, and the setting is still intact. Instead, we need to access this when things are being set up after a new launch, which brings us back to the viewDidLoad() method. Add the bold lines shown here to that method:

        view.addSubview(label)

        index = UserDefaults.standard.integer(forKey: "index")              
        segmentedControl.selectedSegmentIndex = index;              

When the application is being launched for the first time, there will not be a value saved in the user defaults. In this case, the integerForKey() method returns the value zero, which happens to be the correct initial value for the index property. If you wanted to use a different initial value, you could do so by registering it as the default value for the index key, as described in “Registering Default Values” in Chapter 12.

Now build and run the app. You’ll notice a difference immediately—the first segment in the segmented control is preselected, because its selected segment index was set in the viewDidLoad() method. Now touch a segment, and then do the full background-kill-restart dance. There it is—the index value has been restored and, as a result, the correct segment in the segmented control is now selected.

Obviously, what we’ve shown here is pretty minimal, but the concept can be extended to all kinds of application states. It’s up to you to decide how far you want to take it in order to maintain the illusion for the users that your app was always there, just waiting for them to come back.

    func applicationDidEnterBackground() {
        print("VC: (#function)")
        UserDefaults.standard.set(self.index,
            forKey:"index")

        let app = UIApplication.shared()
        var taskId = UIBackgroundTaskInvalid
        let id = app.beginBackgroundTask() {
            print("Background task ran out of time and was terminated.")
            app.endBackgroundTask(taskId)
        }
        taskId = id

        if taskId == UIBackgroundTaskInvalid {
            print("Failed to start background task!")
            return
        }

        DispatchQueue.global(qos: .default).async {
                print("Starting background task with " +
                      "(app.backgroundTimeRemaining) seconds remaining")

                self.smiley = nil;
                self.smileyView.image = nil;

                // simulate a lengthy (25 seconds) procedure
                Thread.sleep(forTimeInterval: 25)

                print("Finishing background task with " +
                      "(app.backgroundTimeRemaining) seconds remaining")
                app.endBackgroundTask(taskId)
            });
    }

        var taskId = UIBackgroundTaskInvalid
        let id = app.beginBackgroundTask() {
            print("Background task ran out of time and was terminated.")
            app.endBackgroundTask(taskId)
        }
        taskId = id

        if taskId == UIBackgroundTaskInvalid {
            print("Failed to start background task!")
            return
        }

        DispatchQueue.global(qos: .default).async {
                print("Starting background task with " +
                      "(app.backgroundTimeRemaining) seconds remaining")

                self.smiley = nil;
                self.smileyView.image = nil;

                // simulate a lengthy (25 seconds) procedure
                Thread.sleep(forTimeInterval: 25)

                print("Finishing background task with " +
                      "(app.backgroundTimeRemaining) seconds remaining")
                app.endBackgroundTask(taskId)
            });

application(_:didFinishLaunchingWithOptions:)
applicationDidBecomeActive
VC: applicationDidBecomeActive()
applicationWillResignActive
VC: applicationWillResignActive()
applicationDidEnterBackground
VC: applicationDidEnterBackground()
Starting background task with 179.808078499991 seconds remaining
Finishing background task with 154.796897583336 seconds remaining