Asking "Where's the beef?" in your application
Making sure your users don't hate you
Designing for perpetuity
Providing lots of functionality
While DeepThoughts is a fun little app, and debugging is well, debugging, it's time to move on to the more interesting stuff. In this chapter, I'll start you down the path to developing a more complex application. While I won't be dotting all the i's and crossing all the t's (I'll leave the memory management details for you to explore on your own, for example) I will be showing you how to use many of the technologies you need to know as you develop your own applications.
Necessity is the mother of invention, and the RoadTrip project was no exception. My daughter was about to leave on a 7,000 mile road trip around the U.S,, and, in anticipation of the Great Adventure, every square inch of surface area in her apartment was covered with maps, campground information, places to see, a schedule of who to visit where, and on and on.
"Please, Dad," she said, "you're so smart. Can't you figure out a way so that I can do all this on my iPhone." Being a sucker for the "Please, Dad" and the "you're so smart" combination, I started to give it some thought, and eventually the RoadTrip application idea was brought kicking and screaming into the world.
The purpose of the application would be to present information that's relevant to a) where you are, or b) where you plan to be. By concentrating on that kind of relevance, the app would reduce the amount of information you'd need to deal with at any one time. The application would be driven by maps and core location (the technologies that let you know where you are) and because of the need to save and manage what could be a significant amount of data, it would also use core data (the iPhone's preferred object/data management technology) to store your objects and data.
Of course, like any other self-respecting iPhone app, it also goes out onto the Web to get the latest information as well as letting you update your information requests wherever you are. (Taos not doing anything for you? Then it's time to switch gears and plan that day-trip to Sedona.)
The ultimate RoadTrip application is far more complicated than I can cover here. Even though the stripped down version I explain isn't a killer app, it is useful, and it uses a lot of the technology you need to know when you do figure out that killer app. As you can see in Figure 1-1, it allows you to do the following:
Bring up a map based on your current location. The map shows your current location, the sites you're planning to visit, and the hotels or campgrounds you're going to stay at. It also allows you to type in an address, and it will place a pin on the map.
You can see the pin business illustrated in Figure 1-2.
List the places you want to visit along the way and some information about each. Figure 1-3 gives you an idea of what I mean here.
Display your hotels or campgrounds with information about each. This feature is pretty straightforward, but pretty cool as well.
Stick around, because I also show you how easy it is to add a new hotel and have it appear on your map. Along the way, I even explain core data, the iPhone's (and Mac's) handy technology for allowing you to store and then reconstitute objects — those modules you create to carry out the work of your program. A very handy piece of technology I might add. You can see the list of hotels and the screen for adding a new hotel in Figure 1-4.
Get real-time weather access. Snow in San Anselmo? Not likely, but you never can tell. You can see real-time weather access at work in Figure 1-5.
Access your car's service records. A handy thing to know because during the course of 7,000 miles you'll probably need to get your car serviced.
Store essential data about your car. Stuff like your car's make, model, year, or vehicle identification number (VIN). This is something you may never need, but if you do, you want it easily accessible, and not in the car itself.
You can see the Service Records and Essential Car info screens in Figure 1-6. Admittedly, there's room here only for very basic information about the car; in a commercial application, you'd want to include more information of course, and some proper formatting, but in this case, barebones screens make the point. As you can see, my daughter saved all her babysitting money, and the proceeds from her lemonade stand, and bought herself a nice car to go cruising with.
So, in this minibook and as well as in the following minibooks, I dive into how to actually implement the application. I cover the major components — user interface, mapping, core location, e-mail, core data — and everything in between. And the best place to start is to come to terms with what's at the heart of many of the iPhone applications that try to do the kinds of things RoadTrip does. And what, pray tell, is at the heart? Table views, my friend, table views. (Table views are so important that I'm devoting the entire next chapter — Chapter 2 — to their idiosyncrasies.)
Note
Part of making the RoadTrip app easy to use involves giving users a way to set their preferences for how the app should work. I've included a setting for using stored data as an example of how an app can make use of preferences, but the stored data feature also lets me address an even more important issue: how to deal with limited or no connectivity. Working in stored data mode gives continuity to your app in those situations where you can't hop on the Web — basically, it lets you use previously stored data rather than the current real-time version that would require Internet access. The idea is to download the information your apps need before you venture into the Dead Zone where Internet access may be a problem. Figure 1-7 shows you what a Use Stored Data preference would look like.
Given the user interface described in the previous section, the big question is how do you get there from here?
Keeping things at a basic level — a level that will be familiar to you if you worked through the DeepThoughts application in Book III — the RoadTrip application is made up of the following:
Models: Model objects encapsulate the logic and (data) content of the application. There was no model object in DeepThoughts. In RoadTrip, I show you how to design, implement, and use model objects.
Views: Views present the user experience; you have to decide what information to display and how to display it. You have several different kinds of views — different ways of displaying both information and navigation choices to the user. There will be a Main view, several List views, and several corresponding Content views. You'll be using some of the view classes available on the iPhone to do that.
View controllers: View controllers manage the user experience. They connect the views that present the user experience with the models that provide the necessary content. In addition (as you see in section appropriately entitled "View controllers"), view controllers also manage the way the user navigates the application.
No big surprises here — especially because the MVC model (Model-View-Controller) is pretty much the basis for all iPhone application development projects. The trick here is coming up with just the right views, view controllers, and model objects to get your project off the ground.
Although you could write a book on model design (in fact, I've written a couple, not to mention an Apple video — but that's another story), I want to concentrate on a couple things now to keep you focused. I elaborate more in Chapter 4 of this minibook.
When you begin to think about all the models you'll need for the application, you may think you've opened up a very large can of worms.
To show you the proper (and far less work-intensive) way to think about it, I want to review what the model objects need to do.
The models own the data and the application logic. In the RoadTrip application, for example, the model maintains a list of hotels and information about each and allows you to add to that list. Here's where the real-world objects associated with object-oriented programming come into play. (In Book VI, I create a Hotel model object to encapsulate that information.)
Interestingly enough, the models that own the car information, car servicing information, the weather, and even information about a site, work a little differently than you might expect.
The model object doesn't have to care about the weather, for example; all it really needs to do is have the logic to go out and get the data from a file, database, or server. For my purposes, a model object that gets weather information and a model object that gets information about the car or even about the Golden Gate Bridge are pretty much the same. The logic for this object revolves around what the data is, how to access the data, and how this data may be connected to other data — the logic isn't about the content of the data. This means that I can create a single model class to handle all those requirements.
I won't be creating a single model class in this minibook, but in Book VI, I show you a couple ways to implement that yourself. All the model objects are of a subclass NSObject because NSObject provides the basic interface to the runtime system. (Interesting factoid: "NS" here illustrates that this was part of the Next Step framework that was the basis for the iPhone and Mac SDK's). NSObject already has methods for allocation; initialization; memory management; introspection ("what class am I?"); encoding and decoding (which make it quite easy to save objects as objects instead of just data); message dispatch; and a host of other equally obscure methods that I don't get into but are required for objects to be able to behave like they're expected to behave in an iPhone OS/Objective-C world.
In RoadTrip, the data will be found in one of a few places: a program resource, a Web server, a Web site, a local file, or a local object store.
In this minibook, I concentrate on showing you how to interact with both the file system to get your data and the outside world. For example, because the make, model, and VIN information about a car rarely changes, it gives me an opportunity to show you how to include a stable data set as a resource in your application.
Similarly, for car servicing information — refer to the right side of Figure 1-6 — my daughter has access to information about the last time the car was serviced and when the next service is due. Because this is the kind of information that changes regularly, I have this stored on my own Web site, where it will be easy to update. However, I do want to cache the information — that is, save the data on the iPhone as a backup — in case the Internet is not available.
Finally, because I don't have my own weather station, I use a Web site to get the weather. I show you how to download a Web site and display it in your application and even how to allow the user to navigate around that site (or even the Web) and then return to your application without ever leaving it.
There are number of view classes you'll use to implement the three (main, list, and content) different kinds of views — ways to display both information and navigation choices to the user.
This one was a no-brainer. The Main view for RoadTrip is a UITableView, no question about it.
Table views are used a lot in iPhone applications to do two things:
Display hierarchal data: Think of the iPod application, which gives you a list of albums, and if you select one, a list of songs.
Act as a table of contents (or for my purposes, contexts): Now, think of the Settings application, which gives you a list of applications that you can set preferences for. When you select one of those applications from the list, it takes you to a view that lists what preferences you're able to set as well as a way to set them.
In RoadTrip, the List views — such as the ones shown earlier in Figure 1-3 (left) and both images in Figure 1-4 — are also table views. The views that display content — such as Figure 1-3 (right), Figure 1-5, and both views in Figure 1-6 — are all Web views, for some good practical reasons.
First and foremost, some of the views must be updated regularly. Web views, in that context, are the perfect solution; they make it easy to access data from a central repository on the Internet. (Client-server is alive and well!)
As for other benefits of Web views, keep in mind that real-time access isn't always necessary — sometimes it's perfectly fine to store some data on the iPhone. It turns out that Web views can easily display formatted data that's locally stored, which is very handy.
Finally, I use Web views for the simple reason that they can access Web sites. If users want more detailed weather information, they can get to the ten-day forecast by simply touching a link.
To implement table views such as the one that displays a list of sights, I need to have the data. I use property lists (XML files, in other words) to take care of that because they're well suited for the job and (more importantly) support for them is built in to the iPhone frameworks.
I also need a way to save and restore objects, especially if I'm going to be adding data. I use core data to manage the hotels. Core data is great at managing the storing and then retrieving of your objects and their data for you. Core data has been available on the Mac for some time and is now available on the iPhone as well. Although a bit daunting at first, you'll be surprised at how easy it is to use and how much power it has, especially when you're using table views.
I tell you more about property lists, the best way (asynchronously) to download lots of data, and core data in Book VI.
View controllers are responsible not only for providing the data for a view to display, but also for responding to user input and navigation.
For the Web views you're going to focus on in this minibook, the view controllers all do pretty much the same thing. They send a message to the model to get some data and then they pass the data onto the view to display. With a bit of clever programming (and not even that clever), you can create a single view controller class that can manage each of the view classes you'll create to implement the User Content views — Weather, Car Information, and Car Servicing. (I go into great detail on all this in Chapter 4 of this minibook.) Keeping things to one view controller class really helps cut down the number of classes that you need and presents a straightforward way to think about how you need to display straight content (like an overview of the Golden Gate Bridge).
Using the application design I describe in this chapter, adding stored data mode, saving state (or where the user was in the application when they last quit) and localization (enabling you to easily display your content in the user's choice of language) is easy; I explain them as I work through the implementation in Chapter 3 of this minibook. Although I don't dig too deeply into localization in this minibook, I show you how to build your application so that you can easily include that handy feature in your app.
If there's one thing I can guarantee about development, it's that nobody gets it right the first time. Although object-oriented design and development are in themselves fun intellectual exercises (at least for some folks), they're also very valuable. An object-oriented program is relatively easier to modify and extend, not just during initial development, but also over time from version to version. (Actually, the initial development and the version updating are both the same; they differ only by a period of rest and vacation between them.)
The design of even this simple application evolved over time, as I figured out the capabilities and intricacies of the platform and the impact of my design decisions. What I'm doing in this chapter, and the ones following, is helping you avoid (at least most of) the blind alleys I stumbled down while developing my first application. So get ready for a stumble-free experience.