Handling Critical Application Tasks IPHONE APPS

This section describes the handful of tasks that every iPhone application should perform. These tasks are part of the overall life cycle of the application and are therefore part of the key ways your application integrates with iPhone OS. In the worst case, failure to handle some of these tasks could even lead to the termination of your application by the operating system.

Initialization and Termination

During initialization and termination, the UIApplication class sends appropriate messages to the application delegate to let it perform any necessary tasks. Although your application is not required to respond to these messages, nearly all iPhone applications should handle them. Initialization time is where you prepare your application’s user interface and put the application into its initial running state. Similarly, termination is the time when you should be writing unsaved data and key application state to disk.

Because one iPhone application must quit before another can be launched, the time it takes to execute your initialization and termination code should be as small as possible. Initialization time is not the time to start loading large data structures that you do not intend to use right away. Your goal during startup should be to present your application’s user interface as quickly as possible, preferably in the state it was in when your application last quit. If your application requires additional time at launch to load data from the network or do other tasks that might be slow, you should get your interface up and running first and then launch the slow task on a background thread. Doing so gives you the opportunity to display a progress indicator or other feedback to the user to indicate that your application is loading the necessary data or doing something important.

Table lists the methods of the UIApplicationDelegate protocol that you implement in your application delegate to handle initialization and termination chores. This table also lists some of the key chores you should perform in each method.

Responsibilities of the application delegate

Responsibilities of the application delegate

Responding to Interruptions

Besides the Home button, which terminates your application, the system can interrupt your application temporarily to let the user respond to important events. For example, an application can be interrupted by an incoming phone call, an SMS message, a calendar alert, or by the user pressing the Sleep button on a device. Whereas a press of the Home button terminates your application, these interruptions may be only temporary. If the user ignores the interruption, your application continues running as before. If the user decides to take a call or reply to an SMS message, however, the system does proceed to terminate your application.

Figure shows the sequence of events that occurs during the arrival of a phone call, SMS message, or calendar alert. The steps that immediately follow describe the key points in the sequence in more detail, including some of the things your application should do in response to each event. This sequence does not reflect what happens when the user pushes the Sleep/Wake button; that sequence is described after the steps below.

The flow of events during an interruption

The flow of events during an interruption

  1. The system detects an incoming phone call or SMS message, or a calendar event occurs.
  2. The system calls your application delegate’s applicationWillResignActive: method. The system also disables the delivery of touch events to your application.Interruptions amount to a temporary loss of control by your application. If such a loss of control might affect your application’s behavior or cause a negative user experience, you should take appropriate steps in your delegate method to prevent that from happening. For example, if your application is a game, you should pause the game. You should also disable timers, throttle back your OpenGL frame rates (if using OpenGL), and generally put your application into a sleep state. While in the resigned state, your application continues to run but should not do any significant work.
  3. The system displays an alert panel with information about the event. The user can choose to ignore the event or respond to it.
  4. If the user ignores the event, the system calls your application delegate’s application Did Become Active: method and resumes the delivery of touch events to your application. You can use this delegate method to reenable timers, throttle up your OpenGL frame rates, and generally wake up your application from its sleep state. For games that are in a paused state, you should consider leaving the game in that state until the user is ready to resume play. For example, you might display an alert panel with controls to resume play.
  5. If the user responds to the event, instead of ignoring it, the system calls your application delegate’s applicationWillTerminate: method. Your application should terminate as usual, saving any needed contextual information to return the user to the same place in your application upon your next launch. After terminating your application, the system proceeds to launch the application responsible for the interruption.

Depending on what the user does while responding to an interruption, the system may launch your application again when that interruption ends. For example, if the user takes a phone call and then hangs up, the system relaunches your application. If, while on the call, the user goes back to the Home screen or launches another application, the system does not relaunch your application.

If the user presses the Sleep/Wake button on a device while running your application, the system calls your application delegate’s application Will Resign Active: method, stops the delivery of touch events, and then puts the device to sleep. When the user wakes the device later, the system calls your application delegate’s application Did Become Active: method and begins delivering events to the application again.

As you do with other interruptions, you should use these methods to put your application into a sleep state (or pause the game) and wake it up again. While in the sleep state, your application should use as little power as possible.

Observing Low-Memory Warnings

When the system dispatches a low-memory warning to your application, heed it. iPhone OS notifies the frontmost application whenever the amount of free memory dips below a safe threshold. If your application receives this warning, it must free up as much memory as it can by releasing objects it does not need or clearing out memory caches that it can easily recreate later.

UIKit provides several ways to receive low-memory warnings, including the following:

  • Implement the application Did Receive Memory Warning: method of your application delegate.
  • Override the did Receive Memory Warning method in your custom UI View Controller subclass.
  • Register to receive the UI Application Did Receive Memory Warning Notification notification.

Upon receiving any of these warnings, your handler method should respond by immediately freeing up any unneeded memory. View controllers should purge any views that are currently offscreen, and your application delegate should release any data structures it can or notify other application objects to release memory they own.

If your custom objects have known purgeable resources, you can have those objects register for the UI Application Did Receive Memory Warning Notification notification and release their purgeable resources directly. Have these objects register if you have a few objects that manage most of your purgeable resources and it is appropriate to purge all of those resources. If you have many purgeable objects or want to coordinate the release of only a subset of those objects, however, you might want to use your application delegate to release the desired objects.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status