iOS App Life Cycle

iOS applications don’t always live in the foreground. Applications can be foreground, background, suspended, and active or inactive, depending on the circumstances. UIApplication object uses different methods in its delegate to provide information about when important changes in application’s state occur or is about to occur. Implementing delegate methods helps the application avoid crashing and gives it the ability to continue where it stopped.

Imagine that you are asked to develop a first-person shooter 3D game for iOS in OpenGL (an open standard for 3D graphics written in C). The game has levels, multiplayer capabilities, and a global leaderboard (connected through the Internet). The aim here is to create a diagram that explains what work your game will do when transitioning between each of the application’s states. The diagram must cover at least the following possibilities:

• User receives a text message in the middle of a single player game (iOS4).
• User receives a phone call in the middle of a multiplayer game and decides to answer the call.
• User closes the app with the home button in the middle of a single player game.
• User presses the lock button while on the Main Menu of the application, outside of a game.

Attention should be paid to iOS requirements (e.g. iOS apps that use OpenGL in the background will be terminated by iOS!).

In the first-person shooter 3D game for iOS example, when playing a single player, after an interruption like receiving an SMS or user pressing home button, user data including which level, points and generally current circumstances should be saved. If Internet connection is in use for global leaderboard, it should be cancelled otherwise the connection object attempts to call its delegate, which does not exist anymore, when it is finished. For the same reason, any timers in use should be invalidated and finally OpenGL frames must stop working as the program is about to enter background as any OpenGL operation will cause the application to be closed by iOS.

Similar scenario is true when a multiplayer game is in progress and an interruption such as a phone call happens. Except that in a multiplayer game there is less or no user data to be saved and of course internet connection may not be an issue. However, the connectivity among the device and other pairs should be cancelled.

When a game is not in progress and the application is in the menu and an interruption occurs, there is still OpenGL operation which needs to be stopped. Furthermore, the application may already have an internet connection in use, which should be terminated, for instance, in case user have checked the global leaderboard.

The application should be able to recover its last state if necessary. This can happen when for instance user ends a phone call or decides not to open an SMS. In that case, user wants to be able to continue the game where it was paused. This reversal operation could take place in delegate methods that are indicating the application is about to go back to the foreground.

In the end, it is a plus for an application to handle these situations properly. However, some of the processes discussed above, both in moving to background and recovering from a halt, take a lot of time to be completed which can be frustrating for users if they happen many times. For example, 3D graphical objects consume a lot of resources to be created and eliminated. Moreover, not all the conditions are recoverable. For example when playing a multiplayer game, previous state is not achievable and user must re-join the game and start from the beginning.

Diagram