CHAPTER 12: Application Settings and User Defaults

443

they’re no longer in use, as well as performing other cleanup tasks. The notification system is another place where you need to clean up after yourself, by telling the default NSNotificationCenter that you don’t want to listen to any more notifications. In our case, where we’ve registered each view controller to observe this notification in its viewDidLoad method, we should unregister in the matching viewDidUnload method. So, in both BIDMainViewController.m and BIDFlipsideViewController.m, put the following line at the top of the viewDidUnload method:

- (void)viewDidUnload {

[[NSNotificationCenter defaultCenter] removeObserver:self];

.

.

.

}

Note that it’s possible to unregister for specific notifications using the removeObserver:name:object: method, by passing in the same values that were used to register your observer in the first place. But the preceding line is a handy way to make sure that the notification center forgets about our observer completely, no matter how many notifications it was registered for.

With that in place, it’s time to build and run the app, and see what happens when you switch between your app and the Settings app. Changes you make in the Settings app should now be immediately reflected in your app when you switch back to it.

Beam Me Up, Scotty

At this point, you should have a very solid grasp on both the Settings application and the User Defaults mechanism. You know how to add a settings bundle to your application and how to build a hierarchy of views for your application’s preferences. You also learned how to read and write preferences using NSUserDefaults, and how to let the user change preferences from within your application. You even got a chance to use a new project template in Xcode. There really shouldn’t be much in the way of application preferences that you are not equipped to handle now.

In the next chapter, we’re going to show you how to keep your application’s data around after your application quits. Ready? Let’s go!

www.it-ebooks.info

Chapter13

Basic Data Persistence

So far, we’ve focused on the controller and view aspects of the MVC paradigm. Although several of our applications have read data out of the application bundle, none of them has saved data to any form of persistent storage—nonvolatile storage that survives a restart of the computer or device. With the exception of Application Settings (in Chapter 12), so far, every sample application either did not store data or used volatile or nonpersistent storage. Every time one of our sample applications launched, it appeared with exactly the same data it had the first time you launched it.

This approach has worked for us up to this point. But in the real world, your applications will need to persist data. When users make changes, they usually like to find those changes when they launch the program again.

A number of different mechanisms are available for persisting data on an iOS device. If you’ve programmed in Cocoa for Mac OS X, you’ve likely used some or all of these techniques.

In this chapter, we’re going to look at four different mechanisms for persisting data to the iOS file system:

Property lists

Object archives (or archiving)

SQLite3 (iOS’s embedded relational database)

Core Data (Apple’s provided persistence tool)

We will write example applications that use all four approaches.

NOTE: Property lists, object archives, SQLite3, and Core Data are not the only ways you can persist data on iOS. They are just the most common and easiest. You always have the option of using traditional C I/O calls like fopen() to read and write data. You can also use Cocoa’s lowlevel file-management tools. In almost every case, doing so will result in a lot more coding effort

and is rarely necessary, but those tools are there if you need them.

D.Mark et al., Beginning iOS 5 Development

©Dave Mark, Jack Nutting, Jeff LaMarche 2011

www.it-ebooks.info