iOS App Development For Dummies (2014)

Part IV. The Model and the App Structure

Visit www.dummies.com/extras/iosappdevelopment for more on how to use frameworks in iOS app development.

In this part …

· Implementing the Master View Controller

· Working with split view controllers and the master view

· Finishing the basic app structure

Chapter 11. The Trip Model

In This Chapter

Recognizing the importance of models

Working with property lists

Starting the Trip class implementation

Displaying variable content in the debugger

It’s time to add some content to RoadTrip. The owner of RoadTrip’s data is the model, so I start this chapter with a look at the data you’ll need and how the model will manage it. Then I show you how to add a Trip class that will serve as the interface to the model. Finally, you see how to add the Destination class — which is one of the objects that will be used by the model but is hidden behind the Trip interface.

What the Model Contains

In the Model-View-Controller (MVC) design pattern that is the basis for all iOS apps, the model owns the app content logic and data. Therefore, to design your model, the best place to start is with the app design I present in Chapter 4 and consider what will be displayed in the views.

In this first version of RoadTrip, the model needs to provide, for each destination, the following:

· The destination name

· A background image for the destination

· The destination latitude and longitude, along with a title and subtitle to be displayed in the annotation on a map

· Events that the user might be interested in

· Titles and subtitles of sights or places of interest to be displayed in the annotation on a map

· Weather information

I’ve made the point (several times) that the model is about the data, so where does the data come from? The easy answer is … any place you’d like. Given the iOS model, however, you can take several approaches:

· Option 1: Download the data from a web service (or FTP site) and have the model control it in a file or have Core Data (an iOS object persistence mechanism outside the scope of this book) manage it.

· Option 2: Have a web service manage your data and get what you need as you need it.

· Option 3: Include the data as an app resource.

· Option 4: Access the data on the web as an HTML page.

Although I really like Option 1 (and explain that in my book Sams Teach Yourself Core Data for Mac and iOS in 24 Hours), it's beyond the scope of this book, so the Trip model uses both Options 3 and 4.

Although the preceding answers most of the model’s “Show me the data” responsibility, yet another question still has to be answered: How does the model know where the data is? The answer to that question lies in a very useful structure that's used extensively by not only iOS but also Cocoa apps: property lists (more commonly known as plists). The RoadTrip plist that you are about to create will have both data used by the Trip model object (Option 3) as well as the URLs for the data you download as HTML pages (Option 4).

Adding the Model Data

For situations in which you need to store relatively small amounts of persistent data — say, less than a megabyte — a property list offers a uniform and convenient means of organizing, storing, and accessing the data.

Using property lists

A property list (or plist) is perfect for storing small amounts of data that consist primarily of strings and numbers. What adds to its appeal is the capability to easily read it into your program, use the data, and (although you won’t be doing it in the RoadTrip app) modify the data and then write the property list back out again (see the “Using plists to store data” sidebar, later in this chapter). That’s because iOS provides a small set of objects that have that behavior built right in.

Apps and other system software in OS X and iOS use property lists extensively. For example, the OS X Finder stores file and directory attributes in a property list, and iOS uses them for user defaults. You also get a Property List editor with Xcode, which makes property list files easy to create and maintain in your own programs.

Figure 11-1 shows a property list that I show you how to build — one that contains the data necessary for the RoadTrip app.

After you figure out how to work with property lists, it’s actually easy, but like most things, getting there is half the fun.

Property lists hold serializable objects. A serializable object can convert itself into a stream of bits so that it can be stored in a file; it can then reconstitute itself into the object it once was when it's read back in.

These objects, called property list objects, that you have to work with are as follows, and you find two types (which I explain in an upcoming paragraph):

Basic Classes:

· NSData and NSMutableData

· NSDate

· NSNumber

· NSString and NSMutableString

Figure 11-1: The RoadTrip plist.

Containers:

· NSArray and NSMutableArray

· NSDictionary and NSMutableDictionary

As previously shown in Figure 11-1, the RoadTrip plist is actually an NSDictionary named Root (this is true of all property list unless you change it). Root has one entry — DestinationData, which is an array of dictionaries — and the data for each one of the destinations is held in a dictionary in that array (Item 0 and Item 1).

Now for that explanation of two kinds of property list objects:

· Basic classes: The term basic classes describes the simplest kind of object. They are what they are.

· Containers: Containers can hold primitives as well as other containers.

One important feature of property list object containers (such as NSArray and NSDictionary), besides their ability to hold other objects, is that they both have a writeToFile: method that writes the object to a file, and a corresponding initWithContentsOfFile:, which initializes the object with the contents of a file. So if I create an array or dictionary and fill it chock-full of objects of the property list type, all I have to do to save that array or dictionary to a file is tell it to go save itself — or create an array or dictionary and then tell it to initialize itself from a file.

Primitives NSString and NSData and their mutable counterparts also can write and read themselves to and from a file.

NSData and NSMutableData are wrappers (a wrapper is an object whose basic purpose is to turn something into an object) in which you can dump any kind of digital data and then have that data act as an object.

The containers can contain other containers as well as the primitive types. Thus, you might have an array of dictionaries, and each dictionary might contain other arrays and dictionaries as well as the primitive types.

Adding a property list to your project

Given the versatility of property lists, you’re sure to turn to them time and time again. Follow these steps to incorporate a plist into your Xcode project:

1. In the Project navigator, add a RoadTrip Resources group to Supporting Files. Right-click it, and then choose New File from the menu that appears to get the New File dialog.

Or select the RoadTrip Resources group and choose File⇒New⇒New File from the main menu (or press +N).

2. In the left column of the New File dialog, select Resource under the iOS heading, select the Property List template in the top-right pane, and then click Next.

A Save sheet appears.

3. Enter Destinations in the Save As field.

4. Click Create (and make sure that the Target field has the RoadTrip check box selected).

A property list will be created with a single element called Root; it is a dictionary, but you can change it to be an array if you want.

5. Right-click in the Root row to show the context-sensitive menu; then choose Add Row, as shown in Figure 11-2.

You can also choose Editor⇒Add Item to add a row.

A new row appears, as shown in Figure 11-3.

Figure 11-2: Add a row to the new plist file.

Figure 11-3: A new row.

6. Enter DestinationData in the Key field, replacing New Item (which should be highlighted).

7. Click in the up and down arrows in the Type field and then choose Array from the pop-up menu that appears, as shown in Figure 11-4.

Figure 11-4: Change the New Item to Array.

8. Click the disclosure triangle in front of the DestinationData key so it is pointing down and click the + (plus) button, as shown in Figure 11-5. A new entry appears.

DestinationData is an array of dictionaries that will hold all your destination-specific information, with Item 0 being the first one.

In Figure 11-5, I've added the row, and you can see the + (plus) button in the new row.

Figure 11-5: Add an entry.

9. Make Item 0 a dictionary by selecting Dictionary in the Type pop-up menu (in the same way you select Array in Step 7).

Your new entry is made into a dictionary, as shown in Figure 11-6.

10. Click the disclosure triangle in front of the Item 0 key so that it points down, and click the + (plus) button as you did in Step 7 to add a new entry to the dictionary.

You see a new entry under the dictionary like the one in Figure 11-7.

These disclosure triangles work the same way as those in the Finder and the Xcode editor. The Property List editor interprets what you want to add based on the triangle. So if the items are revealed (that is, the triangle is pointing down), the editor assumes that you want to add a sub item or child. If the sub items are not revealed (that is, the triangle is pointing sideways), the editor assumes that you want to add an item at that level (sibling). In this case, with the arrow pointing down, you add a new entry — a sub item — to the dictionary. If the triangle were pointing sideways, you would be entering a new entry under the root.

Only arrays and dictionaries have children.

Figure 11-6: A dictionary entry.

Figure 11-7: A new entry in the dictionary.

11. In the Key field of your newest entry, enter DestinationName, leave the Type as String, and then double-click (or tab to) the Value field and enter New York City, as shown in Figure 11-8.

12. Click the + button in the row you just entered, and you get a new entry (a sibling of the previous row). In the Key field, enter DestinationImage, leave the Type as String, and then double-click (or tab to) the Value field and enter NYCImage.

Figure 11-8: A dictionary entry.

13. Click the + button in the row you just entered, and you get a new entry (a sibling of the previous row). In the Key field, enter DestinationLocation and select Dictionary in the Type pop-up menu.

14. Click the disclosure triangle in front of the DestinationLocation key so it's facing down, and click the + button.

You see a new entry under the dictionary, as you can see in Figure 11-9.

Figure 11-9: A new dictionary with another entry.

15. In the Key field, enter Title, and enter New York City in the Value field.

16. Add these three keys with their corresponding type and value:

17. When you're done, your plist should look like Figure 11-10.

18. Click the disclosure triangle to hide theDestinationLocation dictionary entries, and add a new array named Events as a sibling of theDestinationLocation, as shown in Figure 11-11.

As explained previously, when the disclosure triangle is closed, you add a sibling entry.

19. Continue filling out the plist to make it match Figure 11-12 and Table 11-1.

Figure 11-10: The ­Desti-
nation
Loca­tion entries.

Figure 11-11: The Events dictionary entry is an array.

Figure 11-12: The New York City destination entry.

Table 11-1 New York City plist Keys and Values

After you finish entering these items, close Item 0 under DestinationData and go through Steps 8 through 18 again to add the San Francisco entry using the keys and values in Table11-2. If you want to save some typing, you can copy and paste Item 0 and then expand the new Item 1 and simply replace the values. (That’s what I did.)

Table 11-2 San Francisco plist Keys and Values

Make sure that you spell the entries exactly as specified or else you won’t be able to access them using the examples in this book. Be especially careful of trailing spaces.

When you’re done, refer to Figure 11-1 to see how your plist should look.

You may wonder why you’re using this specific data (title and subtitle, for example). You’ll understand that when you explore maps in Chapter 17.