I've just released version 2.3 of the Sites module, which has been quietly under off-and-on development for a couple of months now here at EchoDitto Labs. Sites was originally conceived as a way to make it easy to create multi-site Drupal configurations without the problems and complexities incurred by using Domain Access. Sites is a less-articulated solution than Domain Access: it has fewer features at present, and does not integrate as deeply into the Drupal access stack, but is consequently more stable. Most importantly, it avoids rebuilds of the node_access table, which can be slow (and, in the case of very large sites, can even cause your servers to grind to a halt).

There are several considerations that came into play in the decision to write the module. First, we wanted to be able to create multi-site installs of Drupal wherein some views could show content existing across sites, while others could discriminate between those sites and show only content from the current site. If we simply created a new folder under /sites, there would be no clean way to know at the level of the controller (nodeapi, Views, etc) what site was being used to access content. Furthermore, if we decided to segregate content into different databases, it would be difficult to share that content across sites (the easiest alternative would probably be to publish feeds, which seemed like far more trouble than should be necessary).

Time for part two of my series on iPhone development basics. Last time, I gave some tips on writing settings to a binary file using Apple's Foundation Library. This time I'll show you how to retrieve those settings -- either from a cached version of the property list or from the filesystem itself. As with the first article, let's dive in head first with some code.

First of all, you'll want to add a static NSDictionary member to your settings data controller class for storing the cached settings.

In your .h file:

NSDictionary *cachedSettings;
@property(nonatomic, retain) NSDictionary *cachedSettings;

In your .m file:

static NSDictionary *cachedSettings;
@synthesize cachedSettings;

Here's the loadSettings function. As you can see, I've implemented it as a class method -- there's really no reason to treat your settings data controller as anything other than a singleton with some class methods. Some argue against using singletons in Objective C. In most cases, I could be persuaded to agree; however, app-wide settings don't really make any sense implemented as anything except as global variables, and singletons are essentially the OOP equivalent of globals. I'd love if someone wanted to discuss this in a comment thread, however.

+ (NSDictionary *)loadSettings
{
	if (cachedSettings == nil) {
		NSArray *dirArray = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory,
			NSUserDomainMask,
			YES);
 
		NSString *path = [NSString stringWithFormat:@"%@/settings.bin", [dirArray objectAtIndex:0]];
		NSData *settings = [NSData dataWithContentsOfFile:path];
 
		if (settings != nil) {
			NSDictionary *dict = (NSDictionary *)[NSPropertyListSerialization
				propertyListFromData:settings
				mutabilityOption:0
				format:nil
				errorDescription:nil];
 
			if (dict == nil)
				NSLog(@"Error in loadSettings");
 
			cachedSettings = [dict copy];