iOS App Programming Guide => App States

iOS App Programming Guide

App States and Multitasking

Managing App State Changes

App states

State	Description
Not running	The app has not been launched or was running but was terminated by the system.
Inactive	The app is running in the foreground but is currently not receiving events. (It may be executing other code though.) An app usually stays in this state only briefly as it transitions to a different state.
Active	The app is running in the foreground and is receiving events. This is the normal mode for foreground apps.
Background	The app is in the background and executing code. Most apps enter this state briefly on their way to being suspended. However, an app that requests extra execution time may remain in this state for a period of time. In addition, an app being launched directly into the background enters this state instead of the inactive state.
Suspended	The app is in the background but is not executing code. The system moves apps to this state automatically and does not notify them before doing so. While suspended, an app remains in memory but does not execute any code. When a low-memory condition occurs, the system may purge suspended apps without notice to make more space for the foreground app.

Most state transitions are accompanied by a corresponding call to the methods of your appdelegate object(e.g.application:willFinishLaunchingWithOptions: ).

The App Launch Cycle

As part of the launch cycle, the system creates a process and main thread for your app and calls your app’s main function on that main thread.

If your app is launched into the background, the main difference is that instead of your app being made active, it enters the background state to handle the event and then is suspended shortly afterward:

To determine whether your app is launching into the foreground or background, check theapplicationState property of the shared UIApplication object.

About the main Function

#import <UIKit/UIKit.h>

int main(int argc, char *argv[])
{
    @autoreleasepool {
        return UIApplicationMain(argc, argv, nil, NSStringFromClass([MyAppDelegate class]));
    }
}

UIApplicationMain parameters:

• The third parameter identifies the name of the principal app class. This is the class responsible for running the app. It is recommend that you specifynil for this parameter, which causes UIKit to use theUIApplication class.

• The fourth parameter identifies the class of your custom app delegate.

UIApplication is also responsible to load the app's main user interface file(The storyboard file or nib file).

What to Do at Launch Time

• Check the contents of the launch options dictionary for information about why the app was launched, and respond appropriately.

• Initialize the app’s critical data structures.

• Prepare your app’s window and views for display.

  • If your app does not automatically load a main storyboard or nib file at launch time, you can use theapplication:willFinishLaunchingWithOptions: method to prepare your app’s window for display.

pps are expected to launch and initialize themselves and start handling events in less than 5 seconds. If an app does not finish its launch cycle in a timely manner, the system kills it for being unresponsive.

Responding to Interruptions

Moving to the Background

What to Do When Moving to the Background

• Prepare to have their picture taken. When the applicationDidEnterBackground: method returns, the system takes a picture of your app’s user interface and uses the resulting image for transition animations. If any views in your interface contain sensitive information, you should hide or modify those views before theapplicationDidEnterBackground: method returns.

• Save user data and app state information. All unsaved changes should be written to disk when entering the background.
  

• Free up as much memory as possible.

Your app delegate’s applicationDidEnterBackground: method has approximately 5 seconds to finish any tasks and return. If the method does not return before time runs out, your app is killed and purged from memory.

Memory Usage for Background Apps

Apps that consume large amounts of memory while in the background are the first apps to be terminated.

Returning to the Foreground

Processing Queued Notifications at Wakeup Time

A suspended app does not execute any code and therefore cannot process notifications related to orientation changes, time changes, preferences changes, and many others that would affect the app’s appearance or state. To prevent your app from becoming overloaded with notifications when it resumes, the system coalesces events and delivers a single notification (of each relevant type) that reflects the net change since your app was suspended.

Notifications delivered to waking apps    =>    Table 3-2

App Termination

If your app is running (either in the foreground or background) at termination time, the system calls your app delegate’sapplicationWillTerminate: method so that you can perform any required cleanup.

The applicationWillTerminate: method is not called if your app is currently suspended.

The Main Run Loop

The main run loop of your app is responsible for processing all user-related events. The UIApplication object sets up the main run loop at launch time and uses it to process events and handle updates to view-based interfaces. As the name suggests, the main run loop executes on the app’s main thread. This behavior ensures that user-related events are processed serially in the order in which they were received.

As the user interacts with a device, events related to those interactions are generated by the system and delivered to the app via a special port set up by UIKit. Events are queued internally by the app and dispatched one-by-one to the main run loop for execution. The UIApplication object is the first object to receive the event and make the decision about what needs to be done. A touch event is usually dispatched to the main window object, which in turn dispatches it to the view in which the touch occurred:

Common types of events for iOS apps   ---   Table 3-3       (Event Handling Guide for iOS)

Background Execution and Multitasking

If you find you need to perform background tasks, here are some guidelines for when that is appropriate:

• You need to implement at least one of several specific user services.

• You need to perform a single finite-length task.

• You need to use notifications to alert the user to some relevant piece of information when your app is not running.

Background modes for apps   ---   Table 3-4

Concurrency and Secondary Threads

The system creates your app’s main thread but your app can create additional threads, as needed, to perform other tasks. The preferred way to create threads is to let the system do it for you by using Grand Central Dispatch queues and operation queues. Both types of queue provide an asynchronous execution model for tasks that you define.

Concurrency Programming Guide.