Learning iCloud Data Management (2014)

---

In practice, you almost never look at the XML representation of a property list. And, for preferences or settings, you commonly use the user defaults API described in the following section. Property lists have been a part of Cocoa from its very earliest days, which means that the code used to read and write them has been tested and optimized over time. (Yet, even today, there are some people who believe that the overhead of converting from a text-based format like XML to objects in memory adversely affects performance. Most people disagree except for very large property lists and very slow processors.)

Another consequence of the long history of property lists is that if you search for information on the web, you may get misleading results. Today, you can store property lists in XML or in binary. Many years ago, another format (ASCII) was available, but it has not been supported for years. If you consider that KVC ubiquitous storage for a single app is limited to 1 MB, you can get an idea for a reasonable upper limit of a property list’s size. Yes, not every property list needs to fit into KVC ubiquitous storage, but if you observe that limit, you won’t have to remember which of your property lists are eligible for iCloud and which aren’t.

Reading and Writing Property Lists

Because property lists are usually dictionaries or arrays (at least in terms of their root object), those are the methods you use to read and write them. Both NSDictionary and NSArray have these instance methods:

- writeToFile:atomically
- writeToURL:atomically

There are class methods to read the data back in. NSDictionary has the following class methods:

+ dictionaryWithContentsOfFile:
+ dictionaryWithContentsOfURL:

For NSArray, here are the relevant class methods:

+ arrayWithContentsOfFile:
+ arrayWithContentsOfURL:

There are other ways of accomplishing the same goal (such as alloc followed by a class init method).

Using NSData Objects in Property Lists

An NSData object can be a binary representation of anything. By using NSData objects in a property list, you can take an object in your app and serialize it for storage in a property list. Apple advises against using NSData objects in ubiquitous KVC stores because they can become quite large. If they do become large, the overhead of synchronizing them across a user’s devices can be serious.

It’s not that they don’t work, it’s that the temptation to use them may be too great. If you want to save an app’s state and synchronize it, before you use an NSData object, consider whether Core Data (the topic of Chapter 10, “Managing Persistent Storage with Core Data”) is a better solution.

Using Scalars in Property Lists

There is one further point to remember about property lists. You can store scalars in them, but you need to convert the scalar to one of the property list types—usually an NSNumber. You can use the NSNumber class methods to do this. These are the class methods to use:

+ numberWithBool:
+ numberWithChar:
+ numberWithDouble:
+ numberWithFloat:
+ numberWithInt:
+ numberWithInteger:
+ numberWithLong:
+ numberWithLongLong:
+ numberWithShort:
+ numberWithUnsignedChar:
+ numberWithUnsignedInt:
+ numberWithUnsignedInteger:
+ numberWithUnsignedLong:
+ numberWithUnsignedLongLong:
+ numberWithUnsignedShort:

Working with User Defaults

The user defaults system wraps up the technologies described earlier in this chapter so that you can manage them at a high level of abstraction. The fact that property lists and property-list objects are at the heart of the system does not normally affect the way in which you use the user defaults system as a developer (or the ways in which users use it).

As a developer, you decide what defaults you want to use. There are four key issues to consider in setting up your defaults:

Can the user set them?

How frequently are they changed?

Where should the defaults and settings be located—inside the app or in System Preferences (OS X) or Settings (iOS)?

How do you use iCloud with them?

Can the User Set Defaults?

When it comes to a default such as the default font to use for new documents (if you have such a default), you may want to make this settable by the user. The more defaults a user can set, the more the user’s experience with your app can be enhanced. On the other hand, the more customization you allow, the more complex the app can become for both the developer and user. Depending on your app, you need to find a comfort area for both yourself and your users. (You may also be thinking about the difference between a Lite and a Pro version of your app.)

In the case of a hypothetical default for a font in new documents, you have three basic choices:

You can make the default your choice and allow users to change fonts as they want, but they would always start from your choice.

You can let users set the default.

You can recast the question to provide a simpler user interface if possible. For example, in this case you could use the font of the previous document. Creating a new document and setting its font would reset the unseen preference. (For documents that allow multiple fonts, you would have to make some decisions striking the balance between ease of use and mysterious behavior.)

How Frequently Are Defaults Changed?

Some defaults are set frequently, while others are set-and-forget defaults. Sometimes, they work in pairs. For example, in an app that presents text, movies, or music, you might want to automatically store the last location the user has visited. On the other hand, you might want to always start from a known location (the beginning, perhaps). You can have it both ways by having a user-settable default to allow users to choose which strategy they prefer. Then you can pair it, if necessary, with a default that is the last location.

Where Should the Defaults and Settings Be Located?

Should the defaults and settings be located inside the app or in System Preferences (OS X) or Settings (iOS)?

Users are used to two basic UI approaches for defaults: control from within your app or control from another app. If you implement control of defaults from within your app on OS X, users will expect to find it in a Preferences command in the app menu. What you place there is up to you.

On iOS, a common icon to open a preferences UI is the gear wheel. Again, the layout of the interface is up to you. (See “Registering Defaults” later in this chapter for the code you’ll use to implement the defaults.)

On OS X, you can add a pane to System Preferences to let users manage your app’s preferences. In a similar vein, you can use a Settings bundle on iOS so that users manage your defaults with Settings.

How Do You Use iCloud with Your User Defaults?

This section walks you through some of the synchronizing concerns that you have to consider with iCloud. This is pretty much the process you have to go through with any sync strategy. It’s a step-by-step process in which you look at every permutation and variation that you can think of. You may think you should be writing code, but without this type of painstaking analysis, your code won’t be very usable.

As you saw in Chapter 8, you can use the KVC ubiquity store to keep track of defaults. Listing 8.3 showed you how to load existing defaults on iOS, and Listing 8.4 showed you how to load existing defaults on OS X. Thereafter, you monitor changes in iCloud as shown in Listing 8.5.

Defaults that are device-specific are usually poor candidates for iCloud, but behaviors that provide a comparable user experience across devices are good candidates. What is not handled in Chapter 8 is what you do if the values are inconsistent. One approach is to load the local values as shown in Chapter 8, and then overwrite them with iCloud values if they exist. This has the virtue of getting a default value in place as quickly as possible, but the cost is that a default that has been changed on another device may take longer to be set. Furthermore, if iCloud is unavailable now or when the other device changed the default, you can wind up with a value that is not the most recent value that the user set.

If the values are inconsistent, you may be able to add logic to resolve the problem. The classic example given is a default value that represents the user’s highest score in a game that can be played on any of the devices for that iCloud account. That value should only go up over time, so the automatic choice may be the higher of two inconsistent values.

Of course, you may allow the user to reset the highest score. Factoring that issue into the mix means that the value you want would be either the highest value or zero, which would be the default value for the case in which no score has yet been achieved—the case of a reset to the highest score.

Does that sound right? Is your default synchronization strategy complete?

The flaw in the logic is that you can’t distinguish between a zero that represents a reset of the highest score and a zero that represents a new device. Sometimes with iCloud you do have to ask the user to step in. It is a best practice to minimize user intervention with iCloud synchronization, but if you can formulate a simple question to pose in an alert, let the user choose.

Registering Defaults

As you saw in Chapter 8, you typically get to your app’s defaults by using the NSUserDefaults class method:

myDefaults = [NSUserDefaults standardUserDefaults];

Once you have it, you can then set or get any individual defaults. If no default value has been set yet, zero or nil is returned when you ask for the value. This is often not the best choice. The best way to handle default defaults (that is, default values that the user has not set) is to useregisterDefaults: when your app starts up. Pass in a dictionary with keys and values to use as the defaults for unset defaults:

- (void)registerDefaults:(NSDictionary *)dictionary

Thus, in applicationDidFinishLaunchingWithOptions: (iOS) or applicationDidFinishLaunching: (OS X), you might use code such as that shown in Listing 9.2. Note that Listing 9.2 uses the literals syntax introduced in Xcode 4.4 (OS X) and Xcode 4.5 (iOS). One of the advantages of this syntax is that the order of the keys and values are reversed from the NSDictionary class method dictionaryWithObjectsAndKeys:. Now you don’t have to wonder which comes first—the key or the value. Keys come first just as they do in the name: key-value coding.

Listing 9.2 Registering Default Values