iOS 6 Application Development For Dummies (2013)

Part VI. The Part of Tens

image

In this part . . .

Neal once had a boss who liked to hire smart-but-lazy people. He figured that if he gave them a hard job, they’d find an easy way to do it.

In this part, you see some ways to (first) avoid doing more work than you have to and (second) avoid redoing things because you outsmarted yourself. You also see how to take the RoadTrip app further and create an app that you can really sell (and people will want to buy) in the App Store.

Chapter 21. Ten Ways to Extend the RoadTrip App

In This Chapter

arrow Discovering some additional features for the RoadTrip app

arrow Making structural improvements to the app

arrow Creating an application ecosystem

Although the example app developed in this book — the RoadTrip app — has the basic structure and features that you would include in a commercial app of this type, you would have some additional tasks to take care of if you intended to make it a true, viable commercial application.

Of course, you would have to add more content to the app. You would also need to add more features, as well as strengthen the basic structure a bit.

In this chapter, I suggest some additions you would need to give RoadTrip to make it a commercial success.

Add Preferences

If you go international, roaming charges could make your app prohibitively expensive to use, and the user may want to turn off those features that use the Internet in your app. The app also has some features (see an example in the upcoming section, “Monitor the Current Location’s Distance from the Destination”) that the user may want to use only under certain circumstances, such as tracking and notifying you of how far away your are from your final destination or a specified location (or even the wonderful car sound). To make for happy users, you want to program any optional features to be present based on a preference setting — and enable setting preferences both through the Settings application as well as in the RoadTrip app.

Cache Data

If you allow users to turn off Internet access, or if the user is someplace where Internet service isn’t available, you need to add the logic to RoadTrip to cache data (such as events). Then, when Internet access isn’t available or the user doesn’t want to use the Internet, RoadTrip will use the cached data.

Monitor the Current Location’s Distance from the Destination

In other books and in my classes, I show developers how to add a fun feature to the RoadTrip app. When the user shakes the device, a semitransparent window drops from the top of the screen and displays the distance for either a found location or the final destination. You add this feature by using the accelerometer and core location frameworks.

If the user finds this feature annoying — and because this added feature can chew up the battery life — you want to offer the user the option to toggle it on and off. See the earlier section “Add Preferences.”

Post to Facebook and Twitter

Unless you’re living under a rock, you know that social networking apps are all the rage. Apple added Twitter support in iOS 5 and has expanded social network support even further with the Social Framework in iOS 6. The Social Framework includes support for Facebook.

Send Postcards from the Road

In some of my applications, I have a postcard feature. It would be nice in RoadTrip to allow the user to take a photo and attach it to an e-mail to make all her friends jealous.

Add Hotels and Reservations

A great feature to include in the RoadTrip app is to allow the user to add hotel reservations. You keep track of them in the app by enabling the user to add a reservation to her calendar, a hotel to the address book, and so on.

Create an Itinerary

You can build in a feature in the app that helps the user plan his trip. Enable the user to add his own points of interest and create an itinerary. You should be able to see the itinerary both as a list view and plotted on the map.

Make the App Part of an Application Ecosystem

As I mention in Chapter 1, you want to do the right task on the right device. Although the iPad is the perfect device for both planning and going on your trip, the iPhone is great to use when you’re actually traveling. That’s why it’s always a good idea to consider creating a universal app, as you have done with the Road Trip example app.

It’s Never Early Enough to Start Speaking a Foreign Language

With the world growing even flatter and the iPhone and iPad available worldwide, the potential market for your app is considerably larger than just among people who speak English. Localizing an application isn’t difficult, just tedious. While you obviously can’t implement all the features in your app all at once (that is, some have to be done later than others), when it comes to localizing the strings you use in your application, you had better build them right — and build them in from the start. The painless way is to use the NSLocalizedString macro from the very start (the one I explain in Chapter 13), and you’ll still be a happy camper at the end.

Provide Some Implementation Enhancements

You could definitely tighten up some of the implementation code in the RoadTrip app. Some of the things I did (or didn’t do) in the book were intentional to make the initial app building easier for you to follow. To remedy the less-than-stellar structure that came about as a result, here are a few things you could add on your own:

image Because both the Event Page controller and the Weather controller use a Web view, you could create a Web view superclass that implements all the Web view functionality.

image Because Trip is designed to be a singleton, you could add a class method to Trip that returns a reference to itself so that you don’t have to go through the App Delegate every time.

image I also recommend putting all your constants into a single file and replacing all hard-coded values with constants as well. As you change, or experiment with, those values during the development process, having one place to find constants makes life much easier.