Chapter 1
Building a Real-World iOS App: Bands

WHAT YOU WILL LEARN IN THIS CHAPTER:

 
  • A brief history of the iPhone SDK
  • An introduction to the Bands app
  • How to scope an app and define features

The idea of mobile computing has been around since the late 1970s. The first real mobile computer was the Psion Organiser, which was released in 1984, followed by the Psion Organiser II in 1986. For the most part these early mobile computers looked like calculators. Mobile computing began to pick up speed in the 1990s. That was when the Personal Digital Assistant, or PDA, began to catch on. The phrase Personal Digital Assistant was first used by the CEO of Apple, but not the one you may be thinking of. John Sculley became the CEO of Apple after Steve Jobs was forced out. He made the remark while talking about the Apple Newton, Apple’s first attempt at mobile computing. By most accounts it was not a success and was discontinued in 1998.

广告:个人专属 VPN,独立 IP,无限流量,多机房切换,还可以屏蔽广告和恶意软件,每月最低仅 5 美元

Through the rest of the 1990s and early 2000s, mobile computing continued to evolve. There were many popular PDAs such as the Palm Pilot as well as devices running Windows Mobile. They had their users, but they didn’t have an excited developer base.

Smartphones were also coming into their own during this time. They combined the features of a PDA with the capability to make phone calls. Palm and Windows Mobile along with the BlackBerry dominated these early days. That changed in 2007 when Apple announced the iPhone.

The original iPhone went on sale June 2007. It was instantly an iconic device. Using an iPhone felt like you were using the future. Though touch screens had been around for more than a decade, the iPhone made you feel like you were interacting with real objects, not just touching buttons on a screen. The original release of the iPhone had one big limitation, though; there was no software SDK developers could use to write native applications for it. Steve Jobs instead recommended developers write web applications that would feel like native applications. At the time the tech world was in the middle of the Web 2.0 craze, so the idea wasn’t that far-fetched, but it just didn’t fly with developers.

By September 2007, the idea of “jail breaking” your iPhone began to catch on. Hackers had not only figured out how to unlock the digital security Apple had in place but had also figured out how to write and run their own applications on the device. You had to be pretty brave to do this, though, because jail breaking voided the warranty of an expensive phone, and writing bad software could easily render the device useless.

In October 2007, Apple reversed course and announced that an SDK to write native third-party applications for the iPhone was in development. In March 2008, it was released to developers along with an innovative new way to distribute these new applications called the App Store. That’s when the term app becomes the preferred term for these third-party applications. It is also when the rush to this new development platform, now called the iPhone OS, begins.

The App Store officially launched July 10, 2008. According to Apple, since then there have been more than 1 million apps written and made available in the App Store with more than 10 billion downloads. Having an app is like having a web page in the 1990s: Everyone wants one.

The developer industry around building apps has exploded. That’s probably why you are reading this book. You want to know how to build an app. The best way to learn how to build an app is to actually build an app.

INTRODUCING BANDS

The app you build throughout the course of this book is named Bands. It’s a simple app that you can use to take quick notes about bands you like or want to remember. It won’t win an Apple Design Award, but that’s not its purpose. It is meant to be a conduit to teach you what it’s like to take an idea for an app and make it into a reality, teaching you skills along the way that you can apply when building your own apps. The figures in this section show what the Bands app will look like when you’re done.

Figure 1-1 shows the first screen of the Bands app. It’s a list of all the bands a user adds to the app, sorted alphabetically and indexed.

阅读 ‧ 电子书库

FIGURE 1-1

When a user taps on a band, they see the details of the band, as shown in Figure 1-2. Here they can take notes, add a picture, and set a few other properties about each band.

阅读 ‧ 电子书库

FIGURE 1-2

From the band details, users have the option to do a few different things, as shown in Figure 1-3. They can tell their friends about the band in various ways, as shown in Figure 1-4, search the web for more info about the band, as shown in Figure 1-5, find local record stores, as shown in Figure 1-6, and even search and preview tracks from the band, as shown in Figure 1-7.

阅读 ‧ 电子书库

FIGURE 1-3

阅读 ‧ 电子书库

FIGURE 1-4

阅读 ‧ 电子书库

FIGURE 1-5

阅读 ‧ 电子书库

FIGURE 1-6

阅读 ‧ 电子书库

FIGURE 1-7

Now that you see what the Bands app can become, it’s time to start.

GETTING STARTED

Every app starts with an idea. You may have your own idea for an app, or perhaps your boss has the idea and you are in charge of making it a reality. The Bands app also started with an idea. Say you are at a bar or concert hall, and a band is playing that you’ve never heard of that you want to remember. Or perhaps you are out with friends and talking about music, and someone mentions another band you would like to remember. It would be great to have a place where you could keep all these bands together so that you can go back later when you have time to learn more about them. You could use a note-taking app or send yourself an e-mail, but having a dedicated app you could pull up and have them all together would be ideal.

Naming your app may be one of the hardest parts of app development. It needs to be catchy and memorable yet adequately describe what the app does. The name has to be unique within the App Store. You can search the App Store for names you like and see if there is already an app with that name. You also need to keep in mind how the app name will look on an actual iPhone or iPad. Typically, you have about 12 characters before the app name is truncated. Figure 1-8 shows what a long name looks like. Apple apps, in contrast, are a great example of short names that describe the app well (see Figure 1-9).

阅读 ‧ 电子书库

FIGURE 1-8

阅读 ‧ 电子书库

FIGURE 1-9

NOTE Searching the available apps in the App Store does not guarantee the name is available. The only true way to know is when you attempt to submit the app through iTunes Connect, which you will learn about in Chapter 12, “Deploying Your iOS App.”

Scoping the App

You now have an idea for an app that has a name. The next step is scoping what the app will do. You want your app to be useful, but you also need to keep in mind what is realistic. Too many features can make it hard when the first-time users open your app. Too many features also mean much more development time. Too few features and your app won’t be useful. Finding the balance is the key.

It helps to list all the things you would like your app to do. The following list demonstrates some of the ideas you might want to incorporate in an app like Bands.

 
  • Add any number of bands.
  • Take notes about a band.
  • Take pictures of a band.
  • Tell your friends about a band.
  • Search the web for a band.
  • Find places to buy merchandise from a band.
  • Plot all the tour dates of a band.
  • Have reviews from publications and critics of a band.
  • Have a multimedia library associated with each band.
  • Preview tracks of a band.

There are many more ideas that could be added to the list, but these will do. Now you need to look at the ideas and decide which ones are valuable and which ones are too complicated for the app. You also need to keep in mind functions and features that are used in Apple’s native apps. Duplicating them can cause your app to be rejected when you submit it for approval. It’s better to cut those out right away.

With that in mind, the multimedia library for all the music of a band can be tossed first, because Apple’s Music app does this. Plotting all the tour dates of a band sounds great, but where would you get the information? Having a user manually enter them would be burdensome and probably seldom used, so that idea can be cut as well. Having reviews from publications and critics has the same issue of where you would get the data. There are also copyright issues. That idea can also be dismissed. The rest are all great ideas that can make a useful app.

Defining the Features

With a manageable and useful list of ideas, you can now define the features of the app. Defining the features and what it takes to create them helps you get a good idea of how much time and effort the entire app will take. It also helps you wrap your mind around the final goal, which, of course, is a fully functional app. The features you build into the Bands app in this book are chosen more for the lessons they can teach you to apply when building your own apps, so some of the features may not make the most sense. The following is the list of features you will implement in the Bands app.

 
  1. Adding a band—The app needs a way to add a band. A band needs to have a name, and you need a way to take notes as well as add an optional picture. A rating would help users remember how much they enjoyed the band. A way to record if the band is on tour, off tour, or disbanded is useful as well as a way for users to mark if they have seen the band live. A simple user interface that lists all these in one place and allows the users to edit them seems like the logical choice. Having access to the camera or photo library is needed for the band picture.
  2. Saving multiple bands—An app that saves just one band would not be useful. Saving multiple bands means you need to implement both some sort of persistent storage as well as a way to view all the bands and find them quickly.
  3. Sharing bands—When users find a band they like, they will want to tell others. The app should be able to send e-mails and text messages preformatted with information the users add about a band. Having the ability to share a band through Facebook, Twitter, and Flickr would be useful as well.
  4. Searching for a band on the web—Searching the web for a band a user just learned about will be helpful. This needs a lightweight browser to be included in the app so that users don’t need to use Mobile Safari. It should also be user-friendly and do the initial search for the users.
  5. Finding local record stores—If users want to buy tickets to a local show or buy a poster for a band they like, they may need to find a record store. This feature needs to show a map with pins marking all the record stores close to the user’s location.
  6. Search for tracks—Finding new tracks of a band and previewing them is a fun feature to add to the Bands app. Users can sample new tracks, and if they like them, they can purchase them through the iTunes Store.

Creating a Development Plan

The development plan for the Bands app is laid out in the rest of the chapters of this book. As a beginning developer your first task is to learn about Objective-C and Cocoa Touch, the language and frameworks used to create all iOS apps. Next, you need to learn about Xcode, the integrated development environment you will use to build the Bands app. From there you will implement each feature of the app from the easiest to the most complicated. Finally, when the app’s features are complete, you learn how to get your app in the hands of beta testers before the ultimate goal of getting your app into the App Store.

SUMMARY

All apps start with an idea. The idea for the Bands app is an app that allows users to keep track of bands they hear about from a friend or at a local bar. The next step is coming up with a concrete set of features that are well defined. The Bands app will store information about multiple bands to persistent storage as well as sharing the bands with friends, searching the web for band information, finding local record stores, and previewing and purchasing tracks from the iTunes Store. To start you first need to learn about Objective-C, which you do in the next chapter.

EXERCISES
 
  1. What do you need to keep in mind when naming an app?
  2. Why is it important to scope your app before starting?
  3. What can happen if your app duplicates functionality found in Apple apps?
WHAT YOU LEARNED IN THIS CHAPTER
TOPIC KEY CONCEPTS
iPhone SDK The iPhone SDK was first announced October 2007, and initially introduced to developers March 2008. Since then it has been used to create more than 1 million apps.
The Bands app The Bands app is an app that users can use to remember bands they’ve seen live or have been introduced to by a friend. Instead of keeping them in notes or sending an e-mail, the users can have them all in one place. You learn how to build an iOS app by building the Bands app.
Scope and Features Scoping an app and defining its features is important before beginning development. It helps you keep the app useful without adding too many features that users may find hard to use.