It’s been a while since I’ve described the structure of the Fort Collins for Kids editor. I’ll break down the class descriptions along the traditional View-Model-Controller lines, and I don’t have any custom Views
Two classes make up the model. The first couldn’t be simpler- it’s the Attraction class, now managed with Core Data, Apple’s wrapper around the SQLite database. Here’s the implementation, in it’s entirety:
@implementation Attraction @dynamic attractionDescription; @dynamic attractionName; @dynamic attractionType; @dynamic attractionWebsite; @dynamic orderingValue; @end
AttractionDataController handles the management of the attraction list. countOfList: and ObjectInListAtIndex: wrap the internal NSArray used to store the list. addAttraction: and addAttractionWithName:type:description:website are used to create attractions, while removeAttractionAtIndex: and moveAttractionAtIndex:toIndex are used to remove attractions and reorder the list, respectively. A saveChanges: routine wraps up the functionality of this class.
As with most iOS apps, the view controllers are the heart of the application.
The diagram looks pretty complicated, but when you take out the classes provided by Cocoa Touch, there are really only 4 classes.
This class is the real heart of the program. It inherits from UITableViewController and contains a list of all the attractions in the database. It contains but a single public property- an instance of an AttractionDataController. Internally, it overrides the appropriate UITableViewController methods and implements AddAttractionViewControllerDelegate. This delegate is provided by the AddAttractionViewController, which creates new attractions. The callback implements …DidCancel and …DidFinish methods to handle the transitions between views and perform the database insertion if successful.
As mentioned above, this class lets the user create new attractions. It also inherits from UITableViewController, using a static list of rows to form an editing grid for the attributes in an attraction. This provided a simple start, but I doubt this user interface will hold up over time. When complete, this class calls back to the AddAttractionViewControllerDelegate described above.
The AttractionDetailViewController is yet another UITableViewController. It displays the attributes of an attraction in a grid. Again, I don’t think this UI will last over time. I want to be able to wrap the display (and editing) of an attraction in a single view controller- having 3 different grids (see below) is clearly not the most elegant solution. This class also implements the EditAttractionViewControllerDelegate. This serves a similar purpose to AddAttractionViewControllerDelegate– it provides callback routines for …DidCancel and …DidFinish to handle any needed view transition and database modifications.
The EditAttractionViewController is, you guessed it, another UITableViewController. I use it for editing attractions. You will recognize the pattern here- it calls back to an EditAttractionViewControllerDelegate to handle view transition and database modifications.
Finally, the AttractionAppDelegate ties the app together. It sets up the view controller structure, creates the AttractionDataController and listens to application events. When the application terminates or enters the background, it tells the AttractionDataController to commit any outstanding changes to the database.
In my next post, I’ll discuss my plans for continuing the development of Fort Collins for Kids in the next iteration.