Defining a Custom Data Model

When defining a custom data model, create custom objects to represent any high-level constructs, but take advantage of the system-supplied objects for simpler data types. The Foundation framework provides many objects (most of which are listed in Table 2) for managing strings, numbers, and other types of simple data in an object-oriented way. Using these objects is preferable to defining new objects both because it saves time and because many other system routines expect you to use the built-in objects.

In addition to data-related objects, there are some other data types that are commonly used by the iOS frameworks to manage familiar types of data. You are encouraged to use these data types in your own custom objects to represent similar types of data.

• NSInteger/NSUInteger—Abstractions for scalar signed and unsigned integers that define the integer size based on the architecture.

• NSRange—A structure used to define a contiguous portion of a series. For example, you can use ranges to define the selected characters in a string.

• NSTimeInterval—The number of seconds (whole and partial) in a given time interval.

• CGPoint—An x and y coordinate value that defines a location.

• CGSize—Coordinate values that define a set of horizontal and vertical extents.

• CGRect—Coordinate values that define a rectangular region.

Of course, when defining custom objects, you can always incorporate scalar values directly into your class implementations. In fact, a custom data object can include a mixture of scalar and object types for its member variables. Listing 1 shows a sample class definition for a collection of pictures. The class in this instance contains an array of images and a list of the indexes into that array representing the selected items. The class also contains a string for the collection’s title and a scalar Boolean variable indicating whether the collection is currently editable.

Listing 1  Definition of a custom data object

@interface PictureCollection : NSObject

@property (nonatomic, copy) NSString * title;

@property (nonatomic) BOOL editable;

@property (nonatomic, readonly) NSOrderedSet* pictures;

@property (nonatomic) NSMutableIndexSet *selection;

// Method definitions...

@end

Consider how undo operations on your custom objects might be handled. Supporting undo means being able to reverse changes made to your objects cleanly. If your objects incorporate complex business logic, you need to factor that logic in a way that can be undone easily. Here are some tips for implementing undo support in your custom objects:

• Define the methods you need to make sure that changes to your object are symmetrical. For example, if you define a method to add an item, make sure you have a method for removing an item in a similar way.

• Factor out your business logic from the code you use to change the values of member variables.

• For multistep actions, use the current NSUndoManager object to group the steps together.

Defining a Structured Data Model Using Core Data

Core Data is a schema-driven object graph management and persistence framework. Fundamentally, Core Data helps you to save model objects (in the sense of the Model-View-Controller design pattern) to a file and get them back again. This is similar to archiving, but Core Data offers much more than that.

• Core Data provides an infrastructure for managing all the changes to your model objects. It gives you automatic support for undo and redo, and for maintaining reciprocal relationships between objects.

• It allows you to keep just a subset of your model objects in memory at any given time, which is very important for iOS apps.

• It uses a schema to describe the model objects. You define the principal features of your model classes—including the relationships between them—in a GUI-based editor. This schema provides a wealth of basic functionality “for free,” including setting of default values and attribute value validation.

• It allows you to maintain disjoint sets of edits of your objects. Disjoint sets are useful if you want to, for example, allow the user to make edits in one view that may be discarded without affecting data displayed in another view.

• It has an infrastructure for data store versioning and migration. Versioning lets you easily upgrade an old version of the user’s file to the current version.

• It allows you to store your data in iCloud and access it from multiple devices.

Defining a Document-Based Data Model

A document-based data model is a convenient way to manage the files your app writes to disk. In this type of data model, you use a document object to represent the contents of a single file (or file package) on disk. That document object is responsible for reading and writing the contents of the file and working with your app’s view controllers to present the document’s contents on screen. The traditional use for document objects is to manage files containing user data. For example, an app that creates and manages text files would use a separate document object to manage each text file. However, you can use document objects for private app data that is also backed by a file.

Figure 2 illustrates the typical relationships between documents, files, and the objects in your app’s data model. With few exceptions, each document is self-contained and does not interact directly with other documents. The document manages a single file (or file package) and creates the in-memory representation of any data found in that file. Because the contents of each file are unique, the data structures associated with each document are also unique.

You use the UIDocument class to implement document objects in your iOS app. This class provides the basic infrastructure needed to handle the file management aspects of the document. Other benefits of UIDocument include:

• It provides support for autosaving the document contents at appropriate times.

• It handles the required file coordination for documents stored in iCloud. It also provides hooks for resolving version conflicts.

• It provides support for undoing actions.

You must subclass UIDocument in order to implement the specific behavior required by your app’s documents.

Building an Interface Using UIKit Views

Apps that use UIKit views for drawing are easy to create because you can assemble a basic interface quickly. The UIKit framework provides many types of views to help present and organize data. Controls—a special type of view—provide a built-in mechanism for executing custom code whenever the user performs appropriate actions. For example, clicking a button causes the button’s associated action method to be called.

The advantage of interfaces based on UIKit views is that you can assemble them graphically using Interface Builder—the visual interface editor built in to Xcode. Interface Builder provides a library of the standard views, controls, and other objects that you need to build your interface. After dragging these objects from the library, you drop them onto the work surface and arrange them in any way you want. You then use inspectors to configure those objects before saving them in a storyboard or nib file. The process of assembling your interface graphically is much faster than writing the equivalent code and allows you to see the results immediately, without the need to build and run your app.

Figure 3 shows the basic structure of an app whose interface is constructed using only view objects. In this instance, the main view spans the visible area of the window (minus the status bar) and provides a simple white background. The main view also contains three subviews: an image view, a text view, and a button. Those subviews are what the app uses to present content to the user and respond to interactions. All of the views in the hierarchy are managed by a single view controller object.

In a typical view-based app, you coordinate the onscreen views using your view controller objects. An app always has one view controller that is responsible for presenting all of the content on the screen. That view controller has a content view, which itself may contain other views. Some view controllers can also act as containers for content provided by other view controllers. For example, a split view controller displays the content from two view controllers side by side.

Building an Interface Using Views and OpenGL ES

Games and other apps that need high frame rates or sophisticated drawing capabilities can add views specifically designed for OpenGL ES drawing to their view hierarchies. The simplest type of OpenGL ES app is one that has a window object and a single view for OpenGL ES drawing and a view controller to manage the presentation and rotation of that content. More sophisticated applications can use a mixture of OpenGL ES views and UIKit views to implement their interfaces.

Figure 4 shows the configuration of an app that uses a single OpenGL ES view to draw its interface. Unlike a UIKit view, the OpenGL ES view is backed by a different type of layer object (a CAEAGLLayer object) instead of the standard layer used for view-based apps. The CAEAGLLayer object provides the drawing surface that OpenGL ES can render into. To manage the drawing environment, the app also creates an EAGLContext object and stores that object with the view to make it easy to retrieve.