Reusable Obj-C Classes with Custom Values: The Right Way

Question

I am trying to reuse the Obj-C shell group between iPhone applications. Values ​​that differ from application to application have been isolated, and I'm trying to find a better way to apply these user-defined values ​​to classes based on application-by-application.

Should I store them in code?

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

Should I store them in a large 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 a small, optional n_settings.plist 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 don't think about at all that would be better?

Answer 1

I would personally consider some class of “settings” in the tradition of Objective-C data sources. Configure the class that is responsible for the "data source" for each individual application: whether it offers a set of methods for the values ​​that you need for this particular application, or one getValueForKey method that returns the corresponding value.

In any case, the solution:

• Stores values ​​in code
• Removes the overhead of one massive plist for each setting, some of which cannot be used
• Removes the work of splitting bundles of tiny plist files.
• Allows you to use other classes for your data source, wherever they are needed.
• Gives you the flexibility of OO (theoretically you could subclass a data source if a situation or need arises).
• Localizes the changes that need to be made; just include the data source class as part of the set of classes that you reuse from application to application, and configure that particular class (instead of changing things in all other classes).
• Allows you to set reasonable defaults - or even eliminate exceptions - for data values ​​that you do not expect from a particular application, without the need for an explicit backup code in each calling class (write a default or exception once to the data source class)

Answer 2

I would give the delegate member of each class the question of what small details should be. Which font should I use? I will go ask my delegate. It does not have to be the same delegate for each class or instance, but it can be. For values ​​that may have default values, use respondsToSelector: to enable additional delegate methods.

You can force the delegate to look into the xml / plist file for details, in which case you have everything in one place and you can even upload a new file to change small details.

All your classes can have the same initWithDelegate: , which makes it easy to instantiate without knowing what it is.

Answer 3

Prariedogg,

Absolutely externalize the settings to something like plist. You can even have several layers that match your specific situation (e.g. settingsMac.plist, settingsIPhone.plist).

When your application determines which environment it works in, it loads the appropriate settings through the delegate or central singleton.

By displacing it, you reduce the average cost of maintaining the application. There is less cost of managing and deploying plist updates than recompiling / repacking / repackaging / redeploying.

- Frank