By Andrew C. Stone
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"?
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:
- (IBAction)showPreferencesPanelAction:(id)sender;
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 <YOUR_APP_NAME>.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 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;
}
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.
