¬ RaceDay - a shareware example of Flying Monkey Software's FmsDefaultController

Copyright  ã1994 by Flying Monkey Software.  All Rights Reserved.

The Files in this directory when compiled in Project Builder will build a small demonstration to showcase the FmsDefaultController. The example isn't much, basically allowing a user to configure some details about a racing car and track in a racing simulator. Sorry, no racing simulator is provided. :O)

There are three shareware classes enclosed:

FmsDefaultController (Object) - manages "class" defaults by converting, registering, setting, and revealing defaults in a consistent framework,

FmsPointerPair (Object) - provides set and reveal access to paired pointers, and

FmsStringPair (FmsPointerPair) - provides set and reveal access to shared strings.

Each is provided with NeXT-style documentation, suitable for inclusion and indexing in documentation directories if you choose to use them in your own work. If you do choose to use them, or if you derive any other benefit from them, be sure and read the note in the class code, and please send the suggested amount (more or less as you see fit) to

	Flying Monkey Software
	8424 Todd Creek Circle
	WestChester OH 45069.

In addition to the shareware classes, there are three other classes which constitute the "guts" of the example:

RaceDayController (Object) - starts up the app and bridges between the control panel and the default mechanism,

RaceDayControlPanelController (Object) - provides set and reveal access to the active controls in the application, and provides change notification when they are modified, and

RaceDayDefaultController (FmsDefaultController) - initializes and accesses the applications defaults.

The RaceDay.nib file contains the interface and the connections used in the example.

The nice part of all this is that the details of storing and recovering defaults from their native types are hidden, and the access to defaults by users of the RaceDayDefaultController is directly by method, not by a default name. Adding a new default of an existing type means building an entry in the default loader (loadDefaults in RaceDayController in the example), the default registration (registerDefaults in RaceDayDefaultController in the example), the bulk default setter (setAll in RaceDayDefaultController in the example), and adding a direct reveal method (also located in RaceDayDefaultController in the example). Note that the LoadDefaults method could have been placed in the RaceDayDefaultController, but a level of generality would have been lost. If a new type or class is to be defaulted, the FmsDefaultController can be easily enhanced by categories to extend the framework. The technique is described in the documentation for FmsDefaultController.

The example is more complicatedly constructed than some would have built, with three separate controllers instead of two, or possibly one. We have used many, many more than three before in a complex MVC objective-c frameworks though, as they serve to separate behaviors nicely in complex situations. They also tend to be directly reusable in most cases. But this does cost a small amount of overhead. In this example, for instance, pushing the "Save Defaults" button causes messages to cascade through each of the "RaceDay" controllers, but in the general case, the message could have been acted upon at each reception. In an application where reusability was less of a concern, and performance was super-critical, direct connections would have been favored.

If you have any questions regarding this shareware, of Flying Monkey Software, do not hesitate to get in touch with us.