Dynamic Bundles
Volume Number: 17
Issue Number: 1
Column Tag: Mac OS X
Dynamic Bundles and Runtime Loading in OS X
By Andrew C. Stone
The Subtitle in Italics
As an application gets larger and more complex, the end user may perceive that the
application loads slowly. Of course one can throw faster and multiple CPUs at the
problem, but if you take advantage of dynamic bundle loading, your application can
grow in functionality, but the time to launch remains lightning quick. How is this
done? Simply by only loading the resources the user really needs at the moment. This
article will show you how to architect your application to take advantage of bundles and
late-loading.
Consider the fact that a typical application may have dozens of special panels and
facilities that are occasionally accessed by the end user. There is no reason to load
either the code or the resources for these panels until the end user actually requests
that functionality.
There are many advantages to an application that dynamically loads bundles besides
just fast launches. For example, in Stone Create, not only are all the inspectors,
panels, and editors loaded on demand, but there is also a facility to load new tools at
runtime. Any bundles found in the Tools directory are loaded and added to the tool
palette when a new document is created. For example, the "Star" and "Embed" objects
are loaded this way. New tools can be created and added without Create knowing
anything about these in advance. By creating and adhering to protocols, which are sets
of methods that must be implemented by an object, your application can deal with
brand new objects at runtime.
The CFBundle, and its Cocoa cover class, NSBundle, handle all the details of locating and
loading resources on demand. Most developers just use these for user interfaces,
images, sounds and resource files, but it's simple to also load code on demand. The
question then becomes, "how can I refer to code that is not yet loaded?" and "how can I
compile code that has unresolved symbols"?
PreferencesController Bundle Example
One feature which makes OS X applications so powerful is the ease of user
customization through the NSUserDefaults mechanism. Therefore, most applications
require a user interface for preferences, but why load this panel and the code which
controls it before it's absolutely needed if at all? We'll use the example of a
preferences panel as a likely target for "bundling". The object "PreferenceController
is an NSWindowController subclass, which knows how to return a single instance of
itself with a factory method, +sharedInstance:, because there is only one preferences
panel in any application:
+ (id)sharedInstance {
static PreferencesController *sharedPreferences = nil;
// the first time through, we get the singleton preferences
controller:
if (!sharedPreferences) {
sharedPreferences = [[PreferencesController
allocWithZone:NULL] init];
}
return sharedPreferences;
}
Our dynamic loading code will assume that every bundle responds to "+
sharedInstance" if there are only one of these objects (for example, there is only one
Color panel per application).
If PreferenceController is linked into the application, you would have a method to
bring up the panel in your application delegate object:
- (IBAction)showPreferencesPanelAction:(id)sender {
[[PreferenceController sharedInstance] showWindow:self];
}
but then, that code would be loaded at the launch of the application, because it has to be
compiled into the application's binary since it is referenced by name. The way we move
to a dynamicly loaded model is to never refer to this class, except in a string as an
argument to our dyamic loading method sharedInstanceOfClassName:, which appears
later in the article:
[[self sharedInstanceOfClassName:@"PreferencesController"]
showWindow:self];
Now, the code will compile without including the PreferencesController class. Our job
is to be sure it gets loaded when first needed. Typically, I add the bundle loading code to
the NSApplication's delegate, which can be globally accessed with:
[NSApp delegate]
Another strategy, and a topic of a later article, is to use categories, and add that
functionality right to the NSBundle class. I prefer using the NSApp's delegate because
you can add cover methods for loading panels in a single class, and then connect menu
items to the instantiated application delegate in the application's main NIB file. So, in
this example, we would:
1. add a method to the NSApp delegate class:
- (IBAction)showPreferencesPanelAction:(id)sender;
2. In InterfaceBuilder, connect the menu item "Preferences..." to the app
delegate target, with the action "showPreferencesPanelAction:". You can
quickly add actions to IB by dragging in the .h or .m file from ProjectBuilder
into the document window of your nib. This is equivalent to "Classes->Read
File...".
3. When that menu item gets triggered, the application delegate will load the
needed code. Subsequent invocations of the panel will be even swifter, but
loading a single panel and controller code is pretty fast anyway.
Bundle Integration in Project Builder
From a Project Builder standpoint, your application's project becomes an aggregate of
targets: the application target, and a target for each of the dynamically loaded bundles.
Your application should add the product of each bundle to the Copy Files phase in the
"Files and Build Phases" tab of the application target inspector.
Figure 1. Copy files phase adds bundles to the application target.
For backwards compatibility with OpenStep, I use the "Resources" directory to store
bundles. The following code assumes that you are putting your bundles into the
Resources subdirectory in .app/Contents/. You change where they
are copied to with the "Where:" pop-up in the Files & Build Phases pane of the Target
Inspector. It is probably more intuitive to place bundles in "Bundles" subdirectory,
and if you do, change the pathForResource:ofType: call to pathForBundle:ofType: in the
method -(id)instanceOfClassName:(NSString *)name shared:(BOOL)shared.
Before looking at the very simple dynamic loading code, there is one point to consider.
A Cocoa bundle has the notion of a principal class. That is the class that is both the
owner of the NIB file, and the class that needs to be accessed first when the bundle is
loaded. Many times, a bundle will only have one class in it, but its a potential gotcha to
not specify the principal class if there are more than one class in the bundle. You
assign the principal class in Project Builder - click the bundle target to load the
target inspector. Select the "Bundle Settings" tab, and under the "Cocoa Specific
settings, type in the name of the class in the Principal class field, in this example,
PreferencesController. Other fields let you assign version information, help files,
main nib files, but these are optional.
The Dynamic Loading Code
The code offers two types of dynamic code loading - both singleton class instances such
as the PreferencesController with sharedInstanceOfClassName, as well as simple new
instances for each invocation with instanceOfClassName. Both use the same core code
with a "shared" flag:
- (id)sharedInstanceOfClassName:(NSString *)name
{
return [self instanceOfClassName:name shared:YES];
}
- (id)instanceOfClassName:(NSString *)name {
return [self instanceOfClassName:name shared:NO];
}
instanceOfClassName would be used, for example, in a document-based architecture
application where each document had its own version of that bundle's nib. An example
would be a sheet that gets run on a per-document basis - because more than one
document can be in a sheet-modal state at the same time. In this case, the document
becomes responsible for freeing the bundle resources upon closing. Singleton instances
are not freed until the application quits.
- (id)instanceOfClassName:(NSString *)name shared:(BOOL)shared
{
id obj = nil;
// NSBundle does the work of finding the bundle
// pathForResource means "look into Resources folder
// use pathForBundle if you store them in the "Bundles" folder
NSString *path = [[NSBundle mainBundle]
pathForResource:name ofType:@"bundle"];
if (path) {
NSBundle *b = [[NSBundle allocWithZone:NULL]
initWithPath:path];
// the object we wish to return is an instance of the
principal class:
if ((b != nil) && ([b principalClass] !=NULL)) {
// we either grab the sharedInstance or create a new one:
if (shared) obj = [[b principalClass] sharedInstance];
else obj = [[[b principalClass] allocWithZone:NULL] init];
// provide Developer feedback if something has gone wrong:
} else NSLog(@"Can't Load %@!\n", path);
} else NSLog(@"Couldn't find %@ bundle!\n",name);
return obj;
}
Conclusion
When designing your application, it is good practice to decompose your functionality
into small, loadable pieces. By using dynamically loaded bundles, you gain launch speed
and can take advantage of runtime binding for loading new tools. Probably most
importantly, bundles create a firm foundation for future feature growth without
application bloat as well as provide a natural modularity that is easy to comprehend.
______________________________
Andrew Stone <andrew@stone.com> is CEO of www.stone.com and has been working
with Cocoa since 1989 with its introduction as NeXTStep.