All You Need to Know About the iOS App Lifecycle (Part 2)

As an iOS developer, the iOS app lifecycle is an area you can't skip out on. Knowing how to hook into the individual state changes is just as important. Therefore, let's get familiar with implementing lifecycle hooks in your apps.

Written by 

This is part 2 in this short series on the iOS app lifecycle. In the first part, we looked at the different states as well as hooks for the app lifecycle. In this post, we'll dig deeper and touch upon the mechanics of state changes. This involves taking a close look at UIApplication as well as NotificationCenter which both play a role for notifying you as a developer whenever your app changes state.

To give you an overview of the different interactions between the objects commonly found in most apps, check out the figure below.

You may have seen it from the official iOS documentation. I won't go into details with this one, but what's worth noting is UIApplication and which role it plays in the app.

UIApplication

There is a single shared UIApplication instance in every iOS app. Mostly it delegates behavior to its delegate, AppDelegate. You have probably noticed that the AppDelegate.swift file contains different methods to be implemented. All of these originate from the UIApplication object.

This object is the all-knowing being that notifies us of any state changes in the lifespan of our apps. It does this in two ways:

  1. By calling the delegate methods in AppDelegate.swift which we can implement.
  2. By posting notifications using NotificationCenter which we can listen for.

The first way is fairly straightforward as you might imagine. The file already exists and the methods are just waiting for implementation. The second way, however, requires its own section in this post.

We can access the shared UIApplication in our app by writing the following:

let app = UIApplication.shared

UIApplication also has some useful methods that we can take advantage of. Just to name a few, one method allows you to schedule local notifications inside your app. You can even find a method to ask for more time when your app gets backgrounded. It also provides us with some getter methods such as:

var backgroundTimeRemaining: TimeInterval { get }

This one tells us how much time our app has left in the backgrounded state before it gets suspended. We also have this method:

var applicationState: UIApplication.State { get }

This will let you know of the current state that your app resides in. It is a useful method that may come in handy during debugging.

NotificationCenter

As previously mentioned, the UIApplication will broadcast a notification, whenever your app's state changes. The NotificationCenter class is the key player involved in this process. Let's look at how you can listen for notifications in your code.

Listening for a notification
Listening for notifications is quite simple. First, we get an instance of NotificationCenter by writing:

let center = NotificationCenter.default

This is the default NotificationCenter. Now, you can register an observer of a given notification. This is done by using the following method:

You provide this method with the following arguments:

  • The unnamed argument observer is the observer object of the notification. This is often self.
  • The argument aSelector is the function that gets executed, whenever the notification is received.
  • The argument aName is the name of the notification for which you register.
  • The argument anObject is the broadcaster object you're interested in receiving notifications from. By providing nil, you listen to anyone broadcasting a notification with the given name.

Let's look at an example of this method in use:

Our selector onNotificationReceived gets called with a notification of type Notification. It encapsulates the data coming across in the broadcast. Using this, we can fetch the property userInfo. This is a dictionary of notification-specific information. In that dictionary is any information that the broadcaster wants us to have. Beforehand, anyone broadcasting notifications will have to let you know of the notification name as well as the keys inside the userInfo dictionary.

Posting a notification
We've seen how simple it is to listen for notifications. Luckily, it is even simpler to post notifications that can be listened for. This is done in two steps. First, we create an instance of Notification. Afterward, we call post on our NotificationCenter object. This method looks like this:

You provide this method with the following arguments:

  • The argument aName is the name of the notification of type Notification.Name.
  • The argument anObject is the sender of the notification. Usually, we'll provide it with self.
  • The argument userInfo is the dictionary that contains the notification data.

An example of this is seen below:

That's it! This should seem fairly straightforward because it is. This is exactly what UIApplication does whenever it notify you of state changes, which we can easily listen for.

Wrapping up

This was part 2 of 2 in this short series of posts about the iOS app lifecycle. We touched upon the mechanics of state changes which involves the UIApplication that uses NotificationCenter to notify whenever a state change happens.

Thanks for reading. Remember to leave a comment and share with your fellow developers.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.