Adding a Settings Bundle to Our Project

In the project navigator, click the Bridge Control folder, and then select File New File. . . or press N. In the left pane, select Resource under the iOS heading, and then select the Settings Bundle icon (see Figure 12-9). Click the Next button, leave the default name of Settings.bundle, and click Create.

You should now see a new item in the project window called Settings.bundle. Expand the Settings.bundle item, and you should see two subitems: a folder named en.lproj, containing a file named Root.strings, and an icon named Root.plist. We’ll discuss en.lproj in Chapter 22 when we talk about localizing your application into other languages. Here, we’ll concentrate on Root.plist.

Setting Up the Property List

Select Root.plist and take a look at the editor pane. You’re looking at Xcode’s property list editor (see Figure 12-10). This editor functions in the same way as the Property List Editor application in /Developer/Applications/Utilities.

Notice the organization of the items in the property list. Property lists are essentially dictionaries, storing item types and values and using a key to retrieve them, just as an NSDictionary does.

Several different types of nodes can be put into a property list. The Boolean, Data, Date, Number, and String node types are meant to hold individual pieces of data, but you also have a couple of ways to deal with whole collections of nodes, as well. In addition to Dictionary node types, which allow you to store other dictionaries, there are Array nodes, which store an ordered list of other nodes similar to an NSArray. The Dictionary and Array types are the only property list node types that can contain other nodes.

When creating a settings property list, you need to follow a very specific format. Fortunately, Root.plist, the property list that came with the settings bundle you just added to your project, follows this format exactly. Let’s take a look.

In the Root.plist editor pane, names of keys can either be displayed in their true, “raw” form or in a slightly more human-readable form. We’re big fans of seeing things as they truly are whenever possible, so right-click anywhere in the editor and make sure the Show Raw Keys/Values option in the contextual menu is checked (see Figure 12-11). The rest of our discussion here uses the real names for all the keys we’re going to talk about, so this step is important.

One of the items in the dictionary is StringsTable. A strings table is used in translating your application into another language. We’ll cover the use of strings tables in Chapter 22 when we get into localization. We won’t be using it in this chapter, but feel free to leave it in your project since it won’t do any harm.

In addition to StringsTable, the property list contains a node named PreferenceSpecifiers, which is an array. This array node is designed to hold a set of dictionary nodes, where each node represents either a single preference item that the user can modify or a single child view that the user can drill down into.

You’ll notice that Xcode’s template kindly gave us four nodes (see Figure 12-12). Those nodes aren’t likely to reflect our actual preferences, so delete Item 1, Item 2, and Item 3 (select each one and press the Delete key, one after another), leaving just Item 0 in place.

Single-click Item 0 but don’t expand it. Xcode’s property list editor lets you add rows simply by pressing the Return key. The current selection state—including which row is selected and whether it’s expanded—determines where the new row will be inserted. When an unexpanded array or dictionary is selected, pressing Return adds a sibling node after the selected row. In other words, it will add another node at the same level as the current selection. If you were to press Return (but don’t do that now), you would get a new row called Item 1 immediately after Item 0. Figure 12-13 shows an example of hitting Return to create a new row. Notice the dropdown menu that allows you to specify the kind of preference specifier this item represents—more on this in a bit.

Now expand Item 0 and see what it contains (see Figure 12-14). The editor is now ready to add child nodes to the selected item. If you were to press Return at this point (again, don’t actually press it now), you would get a new first child row inside Item 0.

One of the items inside Item 0 has a key of Type. Every property list node in the PreferenceSpecifiers array must have an entry with this key. The Type key is typically the second entry, but order doesn’t matter in a dictionary, so the Type key doesn’t need to be second. The Type key tells the Settings application what type of data is associated with this item.

In Item 0, the Type item has a value of PSGroupSpecifier. This indicates that the item represents the start of a new group. Each item that follows will be part of this group—until the next item with a Type of PSGroupSpecifier.

If you look back at Figure 12-3, you’ll see that the Settings application presents the application settings in a grouped table. Item 0 in the PreferenceSpecifiers array in a settings bundle property list should always be a PSGroupSpecifier, so that the settings start in a new group. This is important because you need at least one group in every Settings table.

The only other entry in Item 0 has a key of Title, and this is used to set an optional header just above the group that is being started.

Now take a closer look at the Item 0 row itself, and you’ll see that it’s actually shown as Item 0 (Group – Group). The values in parentheses represent the value of the Type item (the first Group) and the Title item (the second Group). This is a nice shortcut that Xcode gives you so that you can visually scan the contents of a settings bundle.

As shown back in Figure 12-3, we called our first group General Info. Double-click the value next to Title, and change it from Group to General Info (see Figure 12-15). When you enter the new title, you may notice a slight change to Item 0. It’s now shown as Item 0 (Group – General Info) to reflect the new title.

Adding a Text Field Setting

We now need to add a second item in this array, which will represent the first actual preference field. We’re going to start with a simple text field.

If you single-click the PreferenceSpecifiers row in the editor pane (don’t do this, just keep reading) and press Return to add a child, the new row will be inserted at the beginning of the list, which is not what we want. We want to add a row at the end of the array.

To add the row, click the disclosure triangle to the left of Item 0 to close it, and then select Item 0 and press Return. This gives you a new sibling row after the current row (see Figure 12-16). As usual, when the item is added, a dropdown menu appears, showing the default value of Text Field.

Click somewhere outside the dropdown menu to make it go away, and then click the disclosure triangle next to Item 1 to expand it. You’ll see that it contains a Type row set to PSTextFieldSpecifier. This is the Type value used to tell the Settings application that we want the user to edit this setting in a text field. It also contains two empty rows for Title and Key (see Figure 12-17).

Select the Title row, and then double-click in the whitespace of the Value column. Type in Commanding Officer to set the Title value. This is the text that will appear in the Settings app.

Now do the same for the Key row (no, that’s not a misprint, you’re really looking at a key called Key). For a value, type in officer (note the lowercase first letter). Remember that user defaults work like a dictionary. This entry tells the Settings application which key to use when it stores the value entered in this text field.

Recall what we said about NSUserDefaults? It lets you store values using a key, similarly to an NSDictionary. Well, the Settings application will do the same thing for each of the preferences it saves on your behalf. If you give it a key value of foo, then, later in your application, you can request the value for foo, and it will give you the value the user entered for that preference. We will use this same key value later to retrieve this setting from the user defaults in our application.

Now select the last of the three Item 1 rows (the one with a Key of Key) and press Return to add another entry to the Item 1 dictionary, giving this one a key of AutocapitalizationType. Note that, as soon as you start typing AutocapitalizationType, Xcode presents you with a list of matching choices, so you can simply pick one from the list instead of typing the whole name. After you’ve entered AutocapitalizationType, a popup appears in the Value column, where you can select from the available options. Choose Words. This specifies that the text field should automatically capitalize each word that the user types in this field.

Create one last new row and give it a key of AutocorrectionType and a value of No. This will tell the Settings application not to autocorrect values entered into this text field. In any situation where you do want the text field to use autocorrection, you would set the value in this row to Yes. Again, Xcode presents you with a list of matching choices as you begin entering AutocorrectionType, and it shows you a list of valid options in a popup.

When you’re finished, your property list should look like the one shown in Figure 12-18.

Adding an Application Icon

Before we try our new setting, let’s add an application icon to the project. You’ve done this before.

Save Root.plist, the property file you just edited. Next, use the project navigator to select the Images.xcassets item, and then select the AppIcon item it contains. There, you’ll find a set of drop targets where icons can be placed.

In the Finder, navigate first to the source code archive, and then into the 12 – Bridge Control folder. Drag the file Icon.png into your project’s configuration editor, dropping it onto the app icon drop target on the left.

That’s it. Now compile and run the application by selecting Product Run. You haven’t built any sort of GUI for the app yet, so you’ll see a pretty boring start screen consisting of a dark grey background with a small blue info icon in one corner. Press the home button, and then tap the icon for the Settings application. You will find an entry for your application, which uses the application icon added earlier (see Figure 12-2). Click the Bridge Control row, and you will be presented with a simple settings view with a single text field, as shown in Figure 12-19.

Quit the simulator and go back to Xcode. We’re not finished yet, but you should now have a sense of how easy it is to add preferences to your application. Let’s add the rest of the fields for our root settings view. The first one we’ll add is a secure text field for the user’s authorization code.

Adding a Secure Text Field Setting

Click Root.plist to return to your setting specifiers (don’t forget to turn on Show Raw Keys/Values, assuming Xcode’s editing area has reset this). Collapse Item 0 and Item 1, and then select Item 1. Press C to copy it to the clipboard, and then press V to paste it back. This will create a new Item 2 that is identical to Item 1. Expand the new item and change the Title to Authorization Code and the Key to authorizationCode. Remember that the Title is what’s shown in an on-screen label, and the Key is what’s used for saving the value.

Next, add one more child to the new item. Remember that the order of items does not matter, so feel free to place it directly below the Key item you just edited. To do this, select the Key/authorizationCode row, and then hit Return.

Give the new item a Key of IsSecure (note the leading uppercase I), and you’ll see that Xcode automatically changes the Type to Boolean. Now change its Value from NO to YES, which tells the Settings application that this field needs to hide the user’s input like a password field, rather than behaving like an ordinary text field. Finally, change AutocapitalizationType to None. Our finished Item 2 is shown in Figure 12-20.

Adding a Multivalue Field

The next item we’re going to add is a multivalue field. This type of field will automatically generate a row with a disclosure indicator. Clicking it will let users drill down to another table, where they can select one of several rows.

Collapse Item 2, select the row, and then press Return to add Item 3. Use the pop-up attached to the Key field to select Multi Value, and then expand Item 3 by clicking the disclosure triangle.

The expanded Item 3 already contains a few rows. One of them, the Type row, is set to PSMultiValueSpecifier. Look for the Title row and set its value to Rank. Then find the Key row and give it a value of rank. The next part is a little tricky, so let’s talk about it before we do it.

We’re going to add two more children to Item 3, but they will be Array type nodes, not String type nodes, as follows:

• One array, called Titles, will hold a list of the values from which the user can select.
• The other array, called Values, will hold a list of the values that are stored in the user defaults.

So, if the user selects the first item in the list, which corresponds to the first item in the Titles array, the Settings application will actually store the first value from the Values array. This pairing of Titles and Values lets you present user-friendly text to the user, but actually stores something else, like a number, date, or different string.

Both of these arrays are required. If you want them to be the same, you can create one array, copy it, paste it back in, and then change the key so that you have two arrays with the same content, but stored under different keys. We’ll actually do just that.

Select Item 3 (leave it open) and press Return to add a new child. You’ll see that, once again, Xcode is aware of the type of file we’re editing and even seems to anticipate what we want to do: the new child row already has its Key set to Titles and is configured to be an Array, which is just what we wanted! Expand the Titles row and hit Return to add a child node. Repeat this five more times, so you have a total of six child nodes. All six nodes should be String type and should be given the following values: Ensign, Lieutenant, Lieutenant Commander, Commander, Captain, and Commodore.

Once you’ve created all six nodes and entered their values, collapse Titles and select it. Next, press C to copy it and press V to paste it back. This will create a new item with a key of Titles - 2. Double-click Titles - 2 and change it to Values.

We’re almost finished with our multivalue field. There’s just one more required value in the dictionary, which is the default value. Multivalue fields must have one—and only one—row selected. So, we need to specify the default value to be used if none has yet been selected, and it needs to correspond to one of the items in the Values array (not the Titles array, if they are different). Xcode already added a DefaultValue row when we created this item, so all we need to do now is give it a value of Ensign. Figure 12-21 shows our version of Item 3.

Let’s check our work. Save the property list, and build and run the application again. When your application starts, press the home button and launch the Settings application. When you select Bridge Control, you should see three fields on your root-level view (see Figure 12-22). Go ahead and play with your creation, and then let’s move on.

Adding a Toggle Switch Setting

The next item we need to get from the user is a Boolean value that indicates whether our warp engines are turned on. To capture a Boolean value in our preferences, we are going to tell the Settings application to use a UISwitch by adding another item to our PreferenceSpecifiers array with a type of PSToggleSwitchSpecifier.

Collapse Item 3 if it’s currently expanded, and then single-click it to select it. Press Return to create Item 4. Use the dropdown menu to select Toggle Switch, and then click the disclosure triangle to expand Item 4. You’ll see there’s already a child row with a Key of Type and a Value of PSToggleSwitchSpecifier. Give the empty Title row a value of Warp Drive and set the value of the Key row to warp.

We have one more required item in this dictionary, which is the default value. Just as with the Multi Value setup, here Xcode has already created a DefaultValue row for us. Let’s turn on our warp engines by default by giving the DefaultValue row a value of YES. Figure 12-23 shows our completed Item 4.

Adding the Slider Setting

The next item we need to implement is a slider. In the Settings application, a slider can have a small image at each end, but it can’t have a label. Let’s put the slider in its own group with a header, so that the user will know what the slider does.

Start by collapsing Item 4. Now single-click Item 4 and press Return to create a new row. Use the pop-up to turn the new item into a Group, and then click the item’s disclosure triangle to expand it. You’ll see that Type is already set to PSGroupSpecifier. This will tell the Settings application to start a new group at this location. Double-click the value in the row labeled Title and change the value to Warp Factor.

Collapse Item 5 and select it, and then press Return to add a new sibling row. Use the pop-up to change the new item into a Slider, which indicates to the Settings application that it should use a UISlider to get this information from the user. Expand Item 6 and set the value of the Key row to warpFactor, so that the Settings application knows which key to use when storing this value.

We’re going to allow the user to enter a value from 1 to 10, and we’ll set the default to warp 5. Sliders need to have a minimum value, a maximum value, and a starting (or default) value; and all of these need to be stored as numbers, not strings, in your property list. Fortunately, Xcode has already created rows for all these values. Give the DefaultValue row a value of 5, the MinimumValue row a value of 1, and the MaximumValue row a value of 10.

If you want to test the slider, go ahead, but hurry back. We’re going to do just a bit more customization.

As noted, sliders can have images. You can place a small 21 × 21-pixel image at each end of the slider. Let’s provide little icons to indicate that moving the slider to the left slows us down and moving it to the right speeds us up.

Adding Icons to the Settings Bundle

In the 12 - Bridge Control folder in the project archive that accompanies this book, you’ll find two icons called rabbit.png and turtle.png. We need to add both of these to our settings bundle. Because these images need to be used by the Settings application, we can’t just put them in our Bridge Control folder; we need to put them in the settings bundle, so the Settings application can access them.

To do that, find the Settings.bundle in the project navigator. We’ll need to open this bundle in the Finder. Control-click the Settings.bundle icon in the project navigator. When the contextual menu appears, select Show in Finder (see Figure 12-24) to show the bundle in the Finder.

Remember that bundles look like files in the Finder, but they are really folders. When the Finder window opens to show the Settings.bundle file, control-click the file and select Show Package Contents from the contextual menu that appears. This will open the settings bundle in a new Finder window, and you should see the same two items that you see in Settings.bundle in Xcode. Copy the two icon files, rabbit.png and turtle.png, from the 12 - Bridge Control folder into the Settings.bundle package contents in the Finder window.

You can leave this window open in the Finder, as we’ll need to copy another file here soon. Now we’ll return to Xcode and tell the slider to use these two images.

Back in Xcode, return to Root.plist and add two more child rows under Item 6. Give one a key of MinimumValueImage and a value of turtle. Give the other a key of MaximumValueImage and a value of rabbit. Figure 12-25 shows our finished Item 6.

Save your property list, and then build and run the app to make sure everything is still hunky-dory. You should be able to navigate to the Settings application and find the slider waiting for you, with the sleepy turtle and the happy rabbit at their respective ends (see Figure 12-26).

Adding a Child Settings View

We’re going to add another preference specifier to tell the Settings application that we want it to display a child settings view. This specifier will present a row with a disclosure indicator that, when tapped, will take the user down to a whole new view full of preferences. Let’s get to it.

Since we don’t want this new preference to be grouped with the slider, first we’ll copy the group specifier in Item 0 and paste it at the end of the PreferenceSpecifiers array to create a new group for our child settings view.

In Root.plist, collapse all open items, and then single-click Item 0 to select it and press C to copy it to the clipboard. Next, select Item 6, and then press V to paste in a new Item 7. Expand Item 7 and double-click the Value column next to the key Title, changing it from General Info to Additional Info.

Now collapse Item 7 again. Select it and press Return to add Item 8, which will be our actual child view. Expand it by clicking the disclosure triangle. Find the Type row, give it a value of PSChildPaneSpecifier, and then set the value of the Title row to More Settings.

We need to add one final row to Item 8, which will tell the Settings application which property list to load for the More Settings view. Add another child row, and give it a key of File and a value of More (see Figure 12-27). The file extension .plist is assumed and must not be included (if it is, the Settings application won’t find the plist file).

We are adding a child view to our main preference view. The settings in that child view are specified in the More.plist file. We need to copy More.plist into the settings bundle. We can’t add new files to the bundle in Xcode, and the Property List Editor’s Save dialog will not let us save into a bundle. So, we need to create a new property list, save it somewhere else, and then drag it into the Settings.bundle window using the Finder.

You’ve now seen all the different types of preference fields that you can use in a settings bundle plist file. To save yourself some typing, you can grab More.plist out of the 12 - Bridge Control folder in the project archive that accompanies this book, and then drag it into that Settings.bundle window we left open earlier.

We’re finished with our settings bundle. Feel free to compile, run, and test the Settings application. You should be able to reach the child view and set values for all the other fields. Go ahead and play with it, and make changes to the property list if you want.

Before continuing, select the Image.xcasset item in Xcode’s project navigator, and then copy the rabbit.png and turtle.png icons from the 12 - Bridge Control folder in the project archive into the left side of the editor area. This will add these icons to the project as new images resources, ready for use. We’ll use them in our application to show the value of the current settings.

You might have noticed that the two icons you just added are exactly the same ones you added to your settings bundle earlier, and you might be wondering why. Remember that iOS applications can’t read files out of other applications’ sandboxes. The settings bundle doesn’t become part of our application’s sandbox; it becomes part of the Settings application’s sandbox. Since we also want to use those icons in our application, we need to add them separately to our Bridge Control folder, so they are copied into our application’s sandbox, as well.

Retrieving User Settings

We’ll use a class called NSUserDefaults to access the user’s settings. NSUserDefaults is implemented as a singleton, which means there is only one instance of NSUserDefaults running in our application. To get access to that one instance, we call the class method standardUserDefaults, like so:

NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];

Once we have a pointer to the standard user defaults, we use it much like an NSDictionary. To get a value from it, we can call objectForKey:, which will return an Objective-C object, such as an NSString, NSDate, or NSNumber. If we want to retrieve the value as a scalar—like an int, float, or BOOL—we can use another method, such as intForKey:, floatForKey:, or boolForKey:.

When you were creating the property list for this application, you added an array of PreferenceSpecifiers inside a plist file. Within the Settings application, some of those specifiers were used to create groups, while others were used to create interface objects for user interaction. Those are the specifiers we are really interested in because they hold the keys the real settings data. Every specifier that was tied to a user setting has a Key named Key. Take a minute to go back and check. For example, the Key for our slider has a value of warpFactor. The Key for our Authorization Code field is authorizationCode. We’ll use those keys to retrieve the user settings.

Instead of using strings for each key directly in our methods, we’ll use some precompiler #define statements for the values. That way we can use these makeshift constants in our code instead of inline strings, where we would run the risk of mistyping something. We’ll set these up in a header file, since we’re going to use some of them in more than just this class later on. So, open up BIDMainViewController.h and add these bold lines near the top of the file:

#import "BIDFlipsideViewController.h"
 
#define kOfficerKey                    @"officer"
#define kAuthorizationCodeKey          @"authorizationCode"
#define kRankKey                       @"rank"
#define kWarpDriveKey                  @"warp"
#define kWarpFactorKey                 @"warpFactor"
#define kFavoriteTeaKey                @"favoriteTea"
#define kFavoriteCaptainKey            @"favoriteCaptain"
#define kFavoriteGadgetKey             @"favoriteGadget"
#define kFavoriteAlienKey              @"favoriteAlien"

These constants are the keys that we used in our plist file for the different preference fields. Now that we have a place to display the settings, let’s quickly set up our main view with a bunch of labels. Before going over to Interface Builder, let’s create outlets for all the labels we’ll need. Single-click BIDMainViewController.m, and make the following changes:

#import "BIDMainViewController.h"
 
@interface BIDMainViewController ()
 
@property (weak, nonatomic) IBOutlet UILabel *officerLabel;
@property (weak, nonatomic) IBOutlet UILabel *authorizationCodeLabel;
@property (weak, nonatomic) IBOutlet UILabel *rankLabel;
@property (weak, nonatomic) IBOutlet UILabel *warpDriveLabel;
@property (weak, nonatomic) IBOutlet UILabel *warpFactorLabel;
@property (weak, nonatomic) IBOutlet UILabel *favoriteTeaLabel;
@property (weak, nonatomic) IBOutlet UILabel *favoriteCaptainLabel;
@property (weak, nonatomic) IBOutlet UILabel *favoriteGadgetLabel;
@property (weak, nonatomic) IBOutlet UILabel *favoriteAlienLabel;
 
@end

There’s nothing new here. Next, we declare nine properties, all of them labels, and all of them with the IBOutlet keyword to make them connectable in Interface Builder.

Save your changes. Now that we have our outlets declared, let’s head over to the storyboard file to create the GUI.

Creating the Main View

Select MainStoryboard.storyboard to edit it in Interface Builder. When it comes up, you’ll see the main view on the left and the flipside view on the right, connected by a segue. Notice that the background of the main view is dark gray. Let’s change it to white.

Single-click the View belonging to the Main View Controller, and bring up the attributes inspector. Use the color well labeled Background to change the background to white. Note that the color well also functions as a pop-up menu if you click on the right edge. If you prefer, use that menu to select White Color.

Now we’re going to add a bunch of labels to the View, so it looks like the one shown in Figure 12-28. We’ll need a grand total of 18 labels. Half of them, on the left side of the screen, will be right-aligned and bold; the other half, on the right side of the screen, will be used to display the actual values retrieved from the user defaults and will have outlets pointing to them.

Use Figure 12-28 as your guide to build this view. You don’t need to match the appearance exactly, but you must have one label on the view for each of the declared outlets. Go ahead and design the view. You don’t need any help for this. When you’re finished and have it looking the way you like, come back, and we’ll continue. Just so you know, all our labels used 15-point System Font (or System Font Bold), but feel free to go wild with your own design.

The next thing we need to do is control-drag from the Main View Controller icon to each of the labels intended to display a settings value. You will control-drag a total of nine times, setting each label to a different outlet. Once you have all nine outlets connected to labels, save your changes.

Updating the Main View Controller

In Xcode, select BIDMainViewController.m, and add the following code to the class’s @implementation section:

@implementation BIDMainViewController
 
- (void)refreshFields {
    NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
    self.officerLabel.text = [defaults objectForKey:kOfficerKey];
    self.authorizationCodeLabel.text = [defaults
                                        objectForKey:kAuthorizationCodeKey];
    self.rankLabel.text = [defaults objectForKey:kRankKey];
    self.warpDriveLabel.text = [defaults boolForKey:kWarpDriveKey]
                                ? @"Engaged" : @"Disabled";
    self.warpFactorLabel.text = [[defaults objectForKey:kWarpFactorKey]
                                 stringValue];
    self.favoriteTeaLabel.text = [defaults objectForKey:kFavoriteTeaKey];
    self.favoriteCaptainLabel.text = [defaults
                                      objectForKey:kFavoriteCaptainKey];
    self.favoriteGadgetLabel.text = [defaults objectForKey:kFavoriteGadgetKey];
    self.favoriteAlienLabel.text = [defaults objectForKey:kFavoriteAlienKey];
}
 
- (void)viewDidAppear:(BOOL)animated {
    [super viewDidAppear:animated];
    [self refreshFields];
}
.
.
.

There’s not really much here that should throw you. The refreshFields method does two things. First, it grabs the standard user defaults. Second, it sets the text property of all the labels to the appropriate object from the user defaults using the same key values that we put in our plist file. Notice that for warpFactorLabel, we’re calling stringValue on the object returned. Most of our other preferences are strings, which come back from the user defaults as NSString objects. The preference stored by the slider, however, comes back as an NSNumber, so we call stringValue on it to get a string representation of the value it holds.

After that, we overrode our superclass’s viewDidAppear: method, and there we called our refreshFields method.

What we want to do now is call refreshFields again when we are notified that the flipside controller is being dismissed. Because the flipside view is handled modally, with the main view as its modal parent, the BIDMainViewController’s viewDidAppear: method will not be called when the flipside view is dismissed. Fortunately, the Utility Application template we chose has very kindly provided us with a delegate method we can use for exactly that purpose. Add the following line of code to the existing flipsideViewControllerDidFinish: method:

- (void)flipsideViewControllerDidFinish:
        (BIDFlipsideViewController *)controller
{
    [self refreshFields];
    [self dismissViewControllerAnimated:YES completion:nil];
}

With this in place, our displayed fields will be set to the appropriate preference values both when the view loads and when the flipside view is swapped out.