< Previous PageNext Page > Hide TOC

About Resources

There are several reasons to use resources in your application:

The following sections describe the types of resources typically found in applications and how you use them.

In this section:

Nib Files
String Resources
Image, Sound, and Multimedia Resources
Property Lists
Other Resource Files
Legacy Resource Files


Nib Files

Nib files are the quintessential resource type used to create graphical applications. A nib file is a data archive describing the objects, configuration, and layout information associated with an application’s user interface. You create nib files using the Interface Builder application, which provides a graphical assembly area for the windows and menus that comprise applications. You assemble windows and menus in Interface Builder by dragging and dropping custom views, controls, and other components from the provided library of objects. In addition to positioning items inside a window or view, you can configure the properties of those items as well so that they have the custom look and behavior you want for your application. In Cocoa applications, you can also create connections between objects to facilitate the passing of messages between them.

When you load a nib file, the nib-loading code recreates your objects exactly as they were when you designed them, including any custom configuration or connection information. Because the objects are given to you fully configured, it is possible to create complex user interfaces (see Figure 1-1) with very little code.


Figure 1-1  User interface resources

User interface resources

Nib files are supported widely by both Mac OS X and iPhone OS, although there are some subtle differences in how nib files are supported from environment to environment. Mac OS X and iPhone OS both provide the same basic level of support for loading nib files and using their contents. For example, both provide nib-loading support through the NSBundle class and automated support for loading the application’s main nib file. In Mac OS X, Cocoa provides additional support for loading nib files associated with documents and for using the NSNib class to load nibs. The Carbon environment also supports the use of nib files, although the semantics for using them are different. For Carbon applications, nib files are a repository of user interface items that can be loaded one-by-one, instead of all at once.

Note: The term “nib” and the corresponding file extension are an acronym for “NeXT Interface Builder.” The Interface Builder application was originally developed at NeXT Computer, whose OPENSTEP operating system was used as the basis for creating Mac OS X.

For general information on how to use nib files in Cocoa-based applications (including iPhone applications), see “Nib Files.” For information on how to use nib files in Carbon applications, see “Carbon Resources.” For information on how to create nib files, see Interface Builder User Guide.

String Resources

Text strings are a prominent part of most user interfaces. Text strings are commonly found in an application’s nib files but may also be found in other places as well. For example, if an error occurs, an application might load a string corresponding to that error and display the string in an alert panel. Instead of hard-coding such strings inside source files, which would make localization much more difficult, an application can instead load them from a strings resource file.

A strings resource file (also known as a strings file because its file extension is .strings) is a human-readable text file (in the UTF-16 encoding) containing a set of string resources for an application. The purpose of strings files is to provide an external repository for an application’s localizable text. An application can have any number of strings files and each strings file can contain any number of strings. Each entry in a strings file consists of a key-value pair where both the key and value are themselves strings. The key portion never changes and represents the identifier that your application uses to retrieve the string; however, the value for that key is typically translated to one of the languages your application supports.

Mac OS X provides tools to help you automatically generate strings files for your application. The tools search your code for any usage of specific string-loading routines and use that code to generate strings files for you. For more information about loading string resources and generating strings files, see “String Resources.”

Image, Sound, and Multimedia Resources

Mac OS X and iPhone OS make extensive use of image resources (and to a lesser extent sound and multimedia resources) to create a unique visual style for the entire system. Some of these image resources are used to implement the glossy, three-dimensional texture commonly found in system components, such as the Aqua controls. Apple applications make extensive use of high-quality images to create the look and feel typically associated with the underlying system. Developers are similarly encouraged to use high-quality images to create beautiful and easy-to-use interfaces for their applications. The use of images can not only simplify your drawing code but for complex visual elements can improve performance by providing a prerendered version that can be cached and reused.

Because images are such an important part of graphical user interfaces in general, and Mac OS X and iPhone OS in particular, each system provides extensive support for loading and drawing image resource files. Both Mac OS X and iPhone OS provide support for loading and decoding image files saved in a variety of different formats. For resource files, however, the most commonly used formats include PNG, TIFF, PDF, GIF, and JPEG.

Just as you use images, you can use sound and multimedia resources to create a unique presentation style for your application. Although used less frequently than images, sounds can be used to provide feedback or to alert the user to special events. Audio support is provided by the Core Audio family of frameworks and also by custom classes in the AppKit framework. Similarly, you can use movie clips to present video-based content. Mac OS X also provides extensive use for video and multimedia resources through the QuickTime and QuickTime Kit frameworks. In iPhone OS, similar support is provided by the Media Player framework.

For information about how to use image, sound, and video resources in your applications, see “Image, Sound, and Video Resources.”

Property Lists

Property list files are a way to store custom configuration data outside of your application code. Mac OS X and iPhone OS use property lists extensively to implement features such as user preferences and information property list files for bundles. You can similarly use property lists to store private (or public) configuration data for your applications.

A property-list file is essentially a set of structured data values. You can create and edit property lists either programmatically or using the Property List Editor application (located in /Developer/Applications/Utilities). The structure of of custom property-list files is completely up to you. You can use property lists to store string, number, Boolean, date, and raw data values. By default, a property list stores data in a single dictionary structure, but you can assign additional dictionaries and arrays as values to create a more hierarchical data set.

For information about using property lists, see Property List Programming Guide and Property List Programming Topics for Core Foundation.

Other Resource Files

In addition to the resource types listed in the preceding sections, Table 1-1 lists some additional resource file types you might find in an application bundle.

Table 1-1  Other resource types

Resource Type

Description

AppleScript files

In Mac OS X, AppleScript terminology and suite files contain information about the scriptability of an application. These files can use the file extensions .sdef, .scriptSuite, or .scriptTerminology. Because the actual AppleScript commands used to script an application are visible in user scripts and the Script Editor application, these resources need to be localized. For information on supporting AppleScript, see AppleScript Overview.

Help files

In Mac OS X, help content typically consists of a set of HTML files created using a standard text-editing program and registered with the Help Viewer application. (For information on how to register with Help Viewer, see Apple Help Programming Guide.) It is also possible to embed PDF files, RTF files, HTML files or other custom documents in your bundle and open them using an external application, such as Preview or Safari. For information on how to open files, see Launch Services Programming Guide.

Custom files

Your application can put custom data files or templates inside the appropriate bundle directories.

Legacy Resource Files

In earlier versions of Mac OS, resources were stored in files that used a .rsrc extension. These files were capable of storing multiple resources, including images, sounds, user-interface content, configuration data, and many others. Although support for these files is still available in Mac OS X through the Resource Manager routines, their use is deprecated and strongly discouraged. Old-style resource files are usually holdovers from Carbon applications that were ported from Mac OS 9. Even if you are just now porting such an application to Mac OS X, it still makes much more sense to replace your old resources with new ones. Improvements in Mac OS X, particularly in the area of high-resolution graphics, mean that graphics resources found in these files would look out of place in the current system. In addition, most of the other resource types are obsolete or can be easily replaced by property lists and other resource types.

If you have legacy code and need to know how to access old-style resource files, see Resource Manager Reference.



< Previous PageNext Page > Hide TOC


© 2009 Apple Inc. All Rights Reserved. (Last updated: 2009-01-06)


Did this document help you?
Yes: Tell us what works for you.
It’s good, but: Report typos, inaccuracies, and so forth.
It wasn’t helpful: Tell us what would have helped.