A Bundle is an object that corresponds to a directory where related resources-including executable code-are stored. The directory, in essence, "bundles" a set of resources used by an application into convenient chunks, and the Bundle object makes those resources available to the application. Bundle can find requested resources in the directory and can dynamically load executable code. The term bundle refers both to the object and to the directory it represents.
Bundles are useful in a variety of contexts. Since bundles combine executable code with the resources used by that code, they facilitate installation and localization. Bundles are also used to locate specific resources, to obtain localized strings, to load code dynamically, and to determine which classes are loaded.
Each resource in a bundle usually resides in its own file. Bundled resources include such things as:
You shouldn't attempt subclassing Bundle since during initialization the bundle might substitute another Bundle for self.
The major advantage of bundles is application extensibility. A set of bundled classes often supports a small collection of objects that can be integrated into the larger object network already in place. (NEXTSTEP Preferences is one example of this.) The linkage is established through an instance of the principal class. This object might have methods to return other objects that the application can talk to, but typically all messages from the application to the subnetwork are funneled through the one instance.
Since each bundle can have only one executable file, that file should be kept free of localizable content. Anything that needs to be localized should be segregated into separate resource files and stored in localized-resource subdirectories.
To create a loadable bundle-a bundle with dynamically loadable code-without using Project Builder, use the ld(1) -bundle flag on the cc command line.
Resource files specific to a particular language are grouped together in a subdirectory of the bundle directory. The subdirectory has the name of the language (in English) followed by a ".lproj" extension (for "language project"). The application mentioned above, for example, would have Japanese.lproj, English.lproj, French.lproj, Hindi.lproj, and Swedish.lproj subdirectories. Each ".lproj" subdirectory in a bundle has the same set of files; all versions of a resource file must have the same name. Thus, Hello.snd in French.lproj should be the French counterpart to the Swedish Hello.snd in Swedish.lproj, and so on. If a resource doesn't need to be localized at all, it's stored in the bundle directory itself, not in the ".lproj" subdirectories.
The user determines which set of localized resources will actually be used by the application. Bundle objects rely on the language preferences set by the user in the Preferences application. Preferences lets users order a list of available languages so thatthe most preferred language is first, the second most preferred language is second, and so on.
When a Bundle is asked for a resource file, it provides the path to the resource that best matches the user's language preferences. For details, see the descriptions of pathForResource and pathForResourceInDirectory.