The Core Application Design

Every iOS application is built using the UIKit framework and therefore has essentially the same core architecture. UIKit provides the key objects needed to run the application, to coordinate the handling of user input, and to display content on the screen. Where applications deviate from one another is in how they configure these default objects and also where they incorporate custom objects to augment their application’s user interface and behavior.

There are many interactions that occur between the system and a running application, and many of these interactions are handled automatically by the UIKit infrastructure. However, there are times when your application needs to be aware of the events coming from the system. For example, when the user quits your application, you need to save any relevant data before it goes away. For these situations, UIKit provides hooks that your custom code can use to provide the needed behavior.

Fundamental Design Patterns

The design of the UIKit framework incorporates many of the design patterns found in Cocoa applications in Mac OS X. Understanding these design patterns is crucial to creating iOS applications, so it is worth taking a few moments to learn about them. Table 2-1 provides a brief overview of these design patterns.

For a more thorough discussion of these design patterns, see Cocoa Fundamentals Guide.

The Core Application Objects

From the time your application is launched by the user, to the time it exits, the UIKit framework manages most of the application‚Äôs key infrastructure. An iOS application receives events continuously from the system and must respond to those events. Receiving the events is the job of the UIApplication object, but responding to the events is the responsibility of your custom code. To understand where you need to respond to events, though, it helps to understand a little about the overall life cycle and event cycles of an iOS application. The following sections describe these cycles and also provide a summary of some of the key design patterns used throughout the development of iOS applications.

In addition to showing the UIApplication object, Figure 2-1 shows the objects that are most commonly found in an iOS application, and Table 2-2 describes the roles of each of these types of objects.

Figure 2-1  Key objects in an iOS application

The objects in your application form a complex ecosystem, the specifics of which are what define your application. As you can see from Figure 2-1, most of the objects in an application are either partially or wholly customizable. Fortunately, an application that builds on top of existing UIKit classes receives a significant amount of infrastructure for free. All you have to do is understand the specific points where you can override or augment the default behavior to implement the customizations you need. The remainder of this chapter focuses on the override points that encompass your application’s overall behavior and interactions with the system. It also points you to additional documents where you can find out more about specific types of interactions.

The Application Life Cycle

The application life cycle constitutes the sequence of events that occurs between the launch and termination of your application. In iOS, the user launches your application by tapping its icon on the Home screen. Shortly after the tap occurs, the system displays some transitional graphics and proceeds to launch your application by calling its main function. From this point on, the bulk of the initialization work is handed over to UIKit, which loads the application‚Äôs user interface and readies its event loop.

Figure 2-2 depicts the simplified life cycle of an iOS application. This diagram shows the sequence of events that occur from the time the application starts up to the time it quits. At key points in the application’s life, UIKit sends messages to the application delegate object to let it know what is happening. During the event loop, UIKit dispatches events to your application’s custom event handlers.

Figure 2-2  Application life cycle

Prior to iOS 4, only one application at a time was ever allowed to run. As a result, before a new application could be launched, the previous application had to be terminated. This resulted in an application life cycle in which the application was always launched from scratch and then removed from memory at quit time. In iOS 4 and later, applications now remain resident in memory by default after they are quit. This means that subsequent launches of the application may not always involve starting the application from scratch. It also means that you need to design your application code to handle several different state transitions.

The Main Function

Like any C-based application, the main entry point for an iOS application at launch time is the main function. In an iOS application, the main function is used only minimally. Its main job is to hand control off to the UIKit framework. Therefore, any new project you create in Xcode comes with a default main function like the one shown in Listing 2-1. With few exceptions, you should never change the implementation of this function.

Listing 2-1  The main function of an iOS application

#import <UIKit/UIKit.h>

int main(int argc, char *argv[])

{

    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

    int retVal = UIApplicationMain(argc, argv, nil, nil);

    [pool release];

    return retVal;

}

The UIApplicationMain function at the heart of your application‚Äôs main function takes four parameters and uses them to initialize the application. Although you should never have to change the default values passed into this function, it is worth explaining their purpose in terms of starting the application.

• The argc and argv parameters contain any launch-time arguments passed to the application from the system. These arguments are parsed by the UIKit infrastructure and can otherwise be ignored.

• The third parameter identifies the name of the application‚Äôs principal class. This is the class responsible for running the application. Specifying nil causes UIKit to use the UIApplication class, which is recommended.

• The fourth parameter identifies the class of the application delegate. The application delegate is responsible for managing the high-level interactions between the system and your custom code. Specifying nil tells UIKit that the application delegate object is located in the application‚Äôs main nib file (which is the case for applications built using the Xcode templates).

In addition to creating the application object and creating or loading the application delegate, the UIApplicationMain function also loads the application‚Äôs main nib file. All Xcode projects have a main nib file by default, and this file typically contains the application‚Äôs window and the application delegate object. UIKit obtains the name of the main nib file by looking at the value in the NSMainNibFile key in your application‚Äôs Info.plist file. Although you should rarely need to do so, you can designate a new main nib file for your application by changing the value of this key before building your project. For more information about the Info.plist file and how you use it to configure your application, see ‚ÄúThe Information Property List.‚Äù

The Application Delegate

Monitoring the high-level behavior of your application is the responsibility of the application delegate object, which is a custom object that you provide. Delegation is a mechanism used to avoid subclassing complex UIKit objects, such as the default UIApplication object. Instead of subclassing and overriding methods, you use the complex object unmodified and put your custom code inside the delegate object. As interesting events occur, the complex object sends messages to your delegate object. You can use these ‚Äúhooks‚Äù to execute your custom code and implement the behavior you need.

The application delegate object is responsible for handling several critical system messages and must be present in every iOS application. The object can be an instance of any class you like, as long as it adopts the UIApplicationDelegate protocol. The methods of this protocol define the hooks into the application life cycle and are your way of implementing custom behavior. Although you are not required to implement all of the methods, every application delegate should implement the methods described in Figure 7-2.

For additional information about the methods of the UIApplicationDelegate protocol, see UIApplicationDelegate Protocol Reference.

Understanding an Application’s States and Transitions

Applications running in iOS 4 and later can be in one of several different states at any given time. Table 2-3 lists the potential runtime states of an application in iOS 4 and later.

The following sections describe the key state transitions in more detail and call out the typical behaviors your application should observe during the transition.

Launching the Application

At launch time, an application moves from the not running state to either the active or the background state. A launching application has to prepare itself to run and then check to see if the system has launched it in order to perform a specific task. During the initial startup sequence, the application calls its delegate‚Äôs application:didFinishLaunchingWithOptions: method followed by either the applicationDidBecomeActive: or applicationDidEnterBackground: method (depending on whether it is transitioning to the foreground or background).

Figure 2-3 shows the sequence of steps that occur when launching into the foreground. The sequence for launching into the background is the same except that the applicationDidBecomeActive: method is replaced by the applicationDidEnterBackground: method.

Figure 2-3  Launching into the active state

The application delegate‚Äôs application:didFinishLaunchingWithOptions: method is responsible for doing most of the work at launch time and has the following responsibilities:

• Initialize the application‚Äôs data structures.

• Load or create the application‚Äôs initial window and views in a portrait orientation.

  If the device is in a non-portrait orientation at launch time, you should still create your interface in a portrait orientation initially. After the application:didFinishLaunchingWithOptions: method returns, the application tells the window to rotate its contents to the correct orientation. The window then uses the normal orientation-change mechanism of its view controllers to make the rotation happen prior to becoming visible. Information about how interface orientation changes work is described in ‚ÄúCustom View Controllers‚Äù in View Controller Programming Guide for iOS.

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

• Use any saved preferences or state information to restore the application to its previous runtime state.

You should strive to make your application:didFinishLaunchingWithOptions: method as lightweight as possible. Although there are any number of custom initialization tasks you could perform in this method, if this method takes too long to complete those tasks, the system might terminate the application for being unresponsive. One way to make the method lightweight is to initiate tasks asynchronously or move any long-running tasks to secondary threads. This is especially important for network-based operations that could take an indeterminate amount of time to complete.

When your application:didFinishLaunchingWithOptions: method is called, the applicationState property of the UIApplication object is already set to the appropriate state for your application. If the property is set to UIApplicationStateInactive, your application is in the inactive state and is about to be moved to the foreground. If it is set to UIApplicationStateBackground, the application is about to be moved to the background. In either case, you can use this information to prepare your application appropriate for running.

Applications are launched into the background only as needed to handle an incoming background event. When launched into the background, an application generally has a limited amount of execution time and should therefore avoid doing work that is not immediately relevant to processing the background event. For example, you should avoid setting up your application’s user interface. Instead, you should make a note that the interface needs to be configured and do that work when moving to the foreground later. For additional guidance about how to configure your application for background execution, see “Being a Responsible, Multitasking-Aware Application.”

Moving to the Background

When the user presses the Home button or the system launches another application, the foreground application transitions first to the inactive state and then to the background state. This results in calls to the application delegate‚Äôs applicationWillResignActive: and applicationDidEnterBackground: methods, as shown in Figure 2-4. Most background applications move to the suspended state shortly after returning from the applicationDidEnterBackground: method. If your application requests more execution time or declares itself to support background execution, it is allowed to continue running after this method returns.

Figure 2-4  Moving from the foreground to the background

When your delegate‚Äôs applicationDidEnterBackground: is called, your application has approximately five seconds to finish any lingering tasks and return. If the method does not return before time runs out (or request more execution time from the system), your application is terminated and purged from memory.

The UIApplicationDidEnterBackgroundNotification notification is also sent to notify interested parts of your application that it is entering the background. Objects in your application can use the default notification center to register for this notification.

You should use the applicationDidEnterBackground: method to save user data and any state information needed to restore your application in the event that it is subsequently purged from memory. When an application enters the background state, there is no guarantee that it will remain there indefinitely. If the device‚Äôs memory continues to be constrained, the system purges background applications to make more room. If your application is suspended when that happens, it receives no notice that it is removed from memory. Thus, you need to save any data beforehand.

When an application moves to the background, all of your core application objects remain in memory and are available for use while in the background. These objects include your custom objects and data structures plus your application’s controller objects, windows, and views. However, the system does release many of the objects used behind-the-scenes to support your application. Specifically, the system does the following for background applications:

• It releases the backing store for all Core Animation layers, which prevents the contents of those layers from appearing onscreen but does not change the current layer properties.

• It releases any references to cached images. (If your application does not retain the images, they are subsequently removed from memory.)

• It releases some other system-managed data caches.

If the application is running in iOS 3.x and earlier or on a device that does not support multitasking, the application is terminated instead of being moved to the background. For more information about how to respond to the termination of your application, see “Responding to Application Termination.”

Responding to Interruptions

When the application is interrupted by an incoming phone call, SMS, or calendar notification, the application moves to the inactive state temporarily. It remains in this state until the user decides whether to accept or ignore the interruption. If the user ignores the interruption, the application is reactivated, at which time it can resume any services it stopped when it moved into the inactive state. If the user accepts the interruption, the application moves into the suspended state. Figure 2-5 shows the set of steps this process follows. The steps that follow describe this process in more detail.

Figure 2-5  Handling application interruptions

1. The system detects an incoming phone call or SMS message, or a calendar event occurs.

2. The system calls your application delegate‚ÄôsapplicationWillResignActive: 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 your application is in the inactive state, it 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 applicationDidBecomeActive: 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 applicationDidEnterBackground: method. Your application should move to the background as usual, saving any user data or contextual information needed to restore your application to its current state later.

   If the application is running in iOS 3.x or earlier or on a device that does not support multitasking, the application delegate‚Äôs applicationWillTerminate: method is called instead of the applicationDidEnterBackground: method.

Depending on what the user does while responding to an interruption, the system may return to your application 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 return to your application.

If the user presses the Sleep/Wake button on a device while running your application, the system calls your application delegate‚Äôs applicationWillResignActive: 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 applicationDidBecomeActive: method and begins delivering events to the application again. While the device is asleep, foreground and background applications continue to run, but those applications should do as little work as possible in order to preserve battery life.

Resuming Foreground Execution

When the user launches an application that currently resides in the background, the system moves it to the inactive state and then to the active state. This results in calls to the applicationWillEnterForeground: and applicationDidBecomeActive: methods of the application delegate, as shown in Figure 2-6.

Figure 2-6  Transitioning from the background to the foreground

When moving to the foreground, your application should restart any services it stopped and generally prepare itself for handling events again.

While an application is suspended, the system tracks and coalesces events that might have an impact on that application when it relaunches. As soon as your application is up and running again, the system delivers those events to it. For most of these events, your application’s existing infrastructure should just respond appropriately. For example, if the device orientation changed, your application’s view controllers would automatically update the interface orientation in an appropriate way. For more information about the types of events that are tracked by the system while your application is in the background, and the appropriate way to handle those events, see “Responding to System Changes While in the Background.”

Responding to Application Termination

Although applications are generally moved to the background and suspended, if any of the following conditions are true, your application is terminated and purged from memory instead of being moved to the background:

• The application is linked against iPhone SDK 3.x or earlier.

• The application is deployed on a device running iOS 3.x or earlier.

• The current device does not support multitasking; see ‚ÄúDetermining Whether Multitasking Support is Available.‚Äù

• The application includes the UIApplicationExitsOnSuspend key in its Info.plist file; see ‚ÄúOpting Out of Background Execution.‚Äù

If your application is running (either in the foreground or background) at termination time, the system calls your application delegate‚Äôs applicationWillTerminate: method so that you can perform any required cleanup. You can use this method to save user data or application state information that you would use to restore your application to its current state on a subsequent launch. Your method implementation has approximately five seconds to perform any tasks and return. If it does not return in time, the application is forcibly terminated and removed from memory. The applicationWillTerminate: method is not called if your application is currently suspended.

Even if you develop your application using iPhone SDK 4 and later, you must still be prepared for your application to be terminated. The user can terminate applications explicitly using the multitasking UI. In addition, if memory becomes constrained, the system might remove applications from memory in order to make more room. If your application is currently suspended, the system removes your application from memory without any notice. However, if your application is currently running in the background state (in other words, not suspended), the system calls the applicationWillTerminate: method of your application delegate. Your application cannot request additional background execution time from this method.

Multitasking

In iOS 4 and later, multiple applications may reside in memory and run simultaneously. Only one application runs in the foreground while all other applications reside in the background. Applications running in this environment must be designed to handle transitions between the foreground and background.

Checklist for Supporting Multitasking

Applications that support multitasking in iOS 4 and later should do the following:

• (Required) Respond appropriately to the state transitions that occur while running under multitasking. Applications need to observe these transitions in order to save state and tailor their behavior for foreground or background execution. Not handling these transitions properly could lead to data loss or improper behavior. For more information about the states and transitions, see ‚ÄúUnderstanding an Application‚Äôs States and Transitions.‚Äù

• (Required) Follow the guidelines for behavior when moving to the background. These guidelines are there to help your application behave correctly while in the background and in situations where your application might need to be terminated. For information about these guidelines, see ‚ÄúBeing a Responsible, Multitasking-Aware Application.‚Äù

• (Recommended) Register for any notifications that report system changes your application needs. The system queues notifications while an application is suspended and delivers them once the application resumes execution so that it can make a smooth transition back to execution. For more information, see ‚ÄúResponding to System Changes While in the Background.‚Äù

• (Optional) If you want to do actual work while in the background, you need to request permission to continue running. For more information about the types of work you can perform, and how to request permission to do that work, see ‚ÄúExecuting Code in the Background.‚Äù

If you do not want to support multitasking at all, you can opt out and elect to always have your application terminated and purged from memory at quit time. For information on how to do this, see “Opting Out of Background Execution.”

Responding to System Changes While in the Background

While an application is in the suspended state, it does not receive system-related events that might be of interest. However, the most relevant events are captured by the system and queued for later delivery to your application. To prevent your application from becoming overloaded with notifications when it resumes, the system coalesces events and delivers a single event (of each relevant type) corresponding to the net change since your application was suspended.

To understand how this might work in your application, consider an example. Suppose that at the time when your application is suspended, the device is in a portrait orientation. While the application is suspended, the user rotates the device to landscape left, upside down, and finally landscape right orientations before launching your application again. Upon resumption, your application would receive a single device orientation event indicating that the device changed to a landscape-right orientation. Of course, if your application uses view controllers, the orientation of those view controllers would be updated automatically by UIKit. Your application would need to respond only if it tracked device orientation changes explicitly.

Table 2-4 lists the events that are coalesced and delivered to your application. In most cases, the events are delivered in the form of a notification object. However, some events may be intercepted by a system framework and delivered to your application by another means. Unless otherwise noted, all events are delivered regardless of whether your application resumes in the foreground or background.

When your application resumes, any queued events are delivered via your application’s main run loop. Because these events are queued right away, they are typically delivered before any touch events or other user input. Most applications should be able to handle these events quickly enough that they would not cause any noticeable lag when resumed. However, if your application appears sluggish in responding to user input when it is woken up, you might want to analyze your application using Instruments and see if your handler code is causing the delay.

Handling Locale Changes Gracefully

If the user changes the language or locale of the device while your application is suspended, the system notifies you of that change using the NSCurrentLocaleDidChangeNotification notification. You can use this notification to force updates to any views containing locale-sensitive information, such as dates, times, and numbers. Of course, you should also be careful to write your code in ways that might make it easy to update things easily:

• Use the autoupdatingCurrentLocale class method when retrieving NSLocale objects. This method returns a locale object that updates itself automatically in response to changes, so you never need to recreate it.

• Avoid caching NSFormatter objects. Date and number formatters must be recreated whenever the current locale information changes.

Responding to Changes in Your Application’s Settings

If your application has settings that are managed by the Settings application, it should observe the NSUserDefaultsDidChangeNotification notification. Because the user can modify settings while your application is in the background, you can use this notification to respond to any important changes in those settings. For example, an email program would need to respond to changes in the user‚Äôs mail account information. Failure to do so could have serious privacy and security implications. Specifically, the user might still be able to send email using the old account information, even if the account did not belong to that person.

Upon receiving the NSUserDefaultsDidChangeNotification notification, your application should reload any relevant settings and, if necessary, reset its user interface appropriately. In cases where passwords or other security-related information has changed, you should also hide any previously displayed information and force the user to enter the new password.

Opting Out of Background Execution

If you do not want your application to remain in the background when it is quit, you can explicitly opt out of the background execution model by adding the UIApplicationExitsOnSuspend key to your application‚Äôs Info.plist file and setting its value to YES. When an application opts out, it cycles between the not running, inactive, and active states and never enters the background or suspended states. When the user taps the Home button to quit the application, the applicationWillTerminate: method of the application delegate is called and the application has approximately five seconds to clean up and exit before it is terminated and moved back to the not running state.

Opting out of background execution is strongly discouraged but may be preferable under certain conditions. Specifically, if coding for the background requires adding significant complexity to your application, terminating the application may be a simpler solution. Also, if your application consumes a large amount of memory and cannot easily release any of it, the system might need to terminate your application quickly anyway to make room for other applications. Thus, opting to terminate, instead of switching to the background, might yield the same results and save you development time and effort.

For more information about the keys you can include in your application‚Äôs Info.plist file, see Information Property List Key Reference.

Windows, Views, and View Controllers

You use windows and views to present your application‚Äôs visual content on the screen and to manage the immediate interactions with that content. A window is an instance of the UIWindow class. All iOS applications have at least one window, and some applications may have additional windows to manage specific types of content. An application‚Äôs main window fills the entire main screen and has no visual adornments such as a title bar or close box. A window is simply a blank canvas that you use to host one or more views. Therefore, all manipulations to windows must occur through the programmatic interfaces of the UIWindow class.

A view, an instance of the UIView class, defines a rectangular region inside a window. Views are the primary mechanism for interacting with the user in your application. Views have several responsibilities in your application, including:

• Drawing and animation support

  • Views draw content in their rectangular area.

  • Some view properties can be animated to new values.

• Layout and subview management

  • Views manage a list of subviews, allowing you to create arbitrary hierarchies.

  • Views define their own resizing behaviors in relation to their parent view.

  • Views can change the size and position of their subviews automatically or using custom algorithms you define.

• Event handling

  • Views receive touch events.

  • Views forward events to other objects when appropriate.

View controllers play an important part of your application‚Äôs overall design and structure. Applications running on iOS-based devices have a limited amount of screen space in which to display content. To better manage that screen space, an application uses view controller objects to coordinate the presentation of self-contained view hierarchies. When you want to make significant changes to your application‚Äôs content, rather than change the underlying view objects manually, which is tedious and error prone, you simply present the contents of a new view controller. View controller objects are descendants of the UIViewController class, which is defined in the UIKit framework.

Each view controller object can be thought of as an island unto itself. It manages the presentation of its views, handles their creation and destruction, and facilitates the interactions between those views and other objects in your application. The view controller manages a single top-level view directly and may manage all or some of that view’s subviews. For simple user interfaces, a view controller typically manages all of the views in its view hierarchy. However, for more complex interfaces comprised of several distinct pieces, a view controller may manage a subset of views and rely on one or more custom controller objects to manage other groups of views in the view hierarchy.

Understanding view controllers, and the infrastructure they provide, is important to developing iOS applications. For more information about this infrastructure and how you use view controllers to manage your application’s user interface, see View Controller Programming Guide for iOS. For more information about implementing windows and views, see View Programming Guide for iOS.

The Event-Handling System

The iOS event-handling system is responsible for tracking touch and motion events and delivering them to your application. All events are delivered to the application through the UIApplication object, which manages the queue of incoming events and distributes them to other parts of the application. For most applications, touches are the most significant type of event you can receive. Other types of events may also be generated and delivered, but touches reflect direct interactions with your application‚Äôs views.

When it launches an application, the system creates both a process and a single thread for the application. This initial thread becomes the application‚Äôs main thread. This is where the UIApplication object sets up the main run loop and configures its event-handling code, as shown in Figure 2-7. As touch events come into the application, they are queued until the application is ready to process them. The application processes events in the main run loop to ensure that they are handled sequentially as they arrive. The actual handling of a given event usually occurs in other objects, such as your application‚Äôs views and view controllers.

Figure 2-7  Processing events in the main run loop

Every event sent to an application is encapsulated in a single event object (UIEvent). In the case of touch-related events, the event object contains one or more touch objects (UITouch) representing the fingers that are touching the screen. As the user places fingers on the screen, moves them around, and finally removes them from the screen, the system reports the changes for each finger in the corresponding touch object.

Distributing and handling events is the job of responder objects, which are instances of the UIResponder class. The UIApplication, UIViewController, UIWindow, and UIView classes are all descendants of UIResponder. After pulling an event off the event queue, the application dispatches that event to the UIWindow object where it occurred. The window object, in turn, forwards the event to its first responder. In the case of touch events, the first responder is typically the view object (UIView) in which the touch took place. For example, a touch event occurring in a button is delivered to the corresponding button object.

If the first responder is unable to handle an event, it forwards the event to its next responder, which is typically a parent view or view controller. If that object is unable to handle the event, it forwards it to its next responder, and so on until the event is handled. This series of linked responder objects is known as the responder chain. Messages continue traveling up the responder chain—toward higher-level responder objects such as the window, the application, and the application’s delegate—until the event is handled. If the event isn't handled, it is discarded.

The responder object that handles an event tends to set in motion a series of programmatic actions by the application. For example, a control object (that is, a subclass of UIControl) handles an event by sending an action message to another object, typically the controller that manages the current set of active views. While processing the action message, the controller might change the user interface or adjust the position of views in ways that require some of those views to redraw themselves. When this happens, the view and graphics infrastructure takes over and processes the required redraw events in the most efficient manner possible.

For more information about events, responders, and how you handle events in your own custom objects, see Event Handling Guide for iOS.

The Graphics and Drawing System

There are two basic drawing paths an application can follow in iOS:

• Use native drawing technologies (such as Core Graphics and UIKit).

• Use OpenGL ES.

The native drawing technologies rely on the infrastructure provided by views and windows to render and present custom content. When a view is first shown, the system asks it to draw its content. System views draw their contents automatically, but for custom views, the system calls the drawRect: method of the view. Inside this method, you use the native drawing technologies to draw shapes, text, images, gradients, or any other visual content you want. When you want to change the contents of the view, you do not call the drawRect: method yourself. Instead, you ask the system to redraw all or part of the view by calling the setNeedsDisplay or setNeedsDisplayInRect: method. This cycle then repeats and continues throughout the lifetime of your application.

If you are using OpenGL ES to draw your application’s content, you still create a window and view to manage your content but you use them in a different way. Instead of the view drawing your application’s content, the view simply provides the rendering surface that you then use to create an OpenGL drawing context. You then use that context and your own timing information to coordinate updates to your application’s content.

For information about how to use views and the native rendering technologies to draw your application’s content, see View Programming Guide for iOS. For detailed information about how to use OpenGL ES to draw your application’s content, see OpenGL ES Programming Guide for iOS.

The Text System

The text system in iOS provides everything you need to receive input from the user and display the resulting text in your application. On the input side, the system handles text input occurs through the system keyboard, which is tied to the first responder object. Although it is referred to as the keyboard, its appearance does not always look like a traditional keyboard. Different languages have different text input requirements, and so the keyboard adapts as needed to support different input methods. Figure 2-8 shows several different variants of the system keyboard that are presented automatically based on the user’s current language settings.

Figure 2-8  Several different keyboards and input methods

For displaying text, applications have a variety of options. For simple text display and editing, you can use UIKit classes such as UILabel, UITextField, and UITextView. You can also do simple text display using special additions to the NSString class provided by UIKit. For more sophisticated layout, you can use the Core Graphics text facilities or Core Text. Both frameworks provide drawing primitives to render strings of text. In addition, the Core Text framework provides a sophisticated layout engine for computing line positions, text runs, and page layout information that you can then use when drawing the text.

For information about how to support text input and rendering in your application, see Text and Web Programming Guide for iOS.

Audio and Video Support

Whether multimedia features are central or incidental to your application, iOS users expect high quality. When presenting video content, take advantage of the device’s high-resolution screen and high frame rates. When designing the audio portion of your application, keep in mind that compelling sound adds immeasurably to a user’s overall experience.

You can use the iOS multimedia frameworks to add features like:

• High-quality audio recording, playback, and streaming

• Immersive game sounds

• Live voice chat

• Playback of content from a user‚Äôs iPod library

• Full-screen video playback

• Video recording on devices that support it

For more information about the audio and video technologies available in iOS, see iOS Technology Overview. For information about how to use the audio and video technologies in iOS, see Multimedia Programming Guide.

Integration with the Hardware and System Applications

An iOS application does not need to be isolated from the rest of the system. In fact, the best applications take advantage of both hardware and software features on the device to provide a more intimate experience for the user. Devices contain a lot of user-specific information, much of which is accessible through the system frameworks and technologies. Table 2-5 lists a few of the features you can incorporate into your applications.

For a complete list of technologies you can incorporate into your applications, see iOS Technology Overview.