Question

I’m trying to reuse a group of Obj-C clases between iPhone applications. The values that differ from app to app have been isolated and I’m trying to figure out the best way to apply these custom values to the classes on an app-to-app basis.

Should I hold them in code?

// I might have 10 customizable values for each class, that's a long signature!
CarController *controller = [[CarController alloc] initWithFontName:@"Vroom" engine:@"Diesel" color:@"Red" number:11];

Should I store them in a big settings.plist?

// Wasteful!  I sometimes only use 2-3 of 50 settings!
AllMyAppSettings *settings = [[AllMyAppSettings alloc] initFromDisk:@"settings.plist"];
CarController *controller = [[CarController alloc] initWithSettings:settings];
[settings release];

Should I have little, optional n_settings.plists for each class?

// Sometimes I customize
CarControllerSettings *carSettings = [[CarControllerSettings alloc] initFromDisk:@"car_settings.plist"];
CarController *controller = [[CarController alloc] initWithSettings:carSettings];
[carSettings release];

// Sometimes I don't, and CarController falls back to internally stored, reasonable defaults.
CarController *controller = [[CarController alloc] initWithSettings:nil];

Or is there an OO solution that I’m not thinking of at all that would be better?

Answer 1

I would personally consider some kind of “settings” class, in the tradition of Objective-C data sources. Set up a class that’s responsible for being a “data source” for each individual app: have it provide either a set of methods for the values you need for that particular app, or a single “getValueForKey”-style method that returns the appropriate value.

Either way, the solution:

• Keeps values in code
• Removes the overhead of one massive plist for every setting, some of which may not be used
• Removes the work of splitting out bunches of tiny plist files
• Allows you to have other classes call your data source wherever they need it
• Gives you the flexibility of OO (you could, in theory, subclass your data source should the situation or need arise)
• Localizes the changes you need to make; just include the data source class as part of the set of classes you’re reusing from app to app, and tweak just that class as appropriate (rather than having to change things throughout other classes)
• Lets you set reasonable defaults – or even throw exceptions – for data values you don’t expect to be needed in a particular application, without the need for explicit fallback code in every calling class (write the default or exception once in the data source class)