You are previewing Head First iPhone Development.

Head First iPhone Development

Cover of Head First iPhone Development by Dan Pilone... Published by O'Reilly Media, Inc.
  1. Copyright
  2. Advance Praise for Head First iPhone Development
  3. The Authors
  4. how to use this book: Intro
    1. Who is this book for?
      1. Who should probably back away from this book?
    2. We know what you're thinking.
    3. And we know what your brain is thinking.
    4. Metacognition: thinking about thinking
      1. Here's what WE did:
    5. Here's what YOU can do to bend your brain into submission
    6. Read me
      1. System requirements
    7. The technical review team
    8. Acknowledgments
    9. Safari® Books Online
  5. 1. getting started: Going mobile
    1. 1.1. There's a lot of buzz and a lot of money tied up in the App Store...
    2. 1.2. Mobile applications aren't just ported desktop apps
      1. 1.2.1. iPhone apps are not small desktop apps
    3. 1.3. Anatomy of an iPhone app
      1. 1.3.1. First we have one or more views...
      2. 1.3.2. ...then the code that makes the views work...
      3. 1.3.3. ...and any other resources, all packaged into your application.
    4. 1.4. Mike can't make a decision
    5. 1.5. Make a good first impression
    6. 1.6. It all starts with the iPhone SDK
    7. 1.7. Xcode includes app templates to help you get started
    8. 1.8. Xcode is the hub of your iPhone project...
    9. 1.9. ...and plays a role in every part of writing your app
    10. 1.10. Build your interface using... Interface Builder
    11. 1.11. Add the button to your view
    12. 1.12. The iPhone Simulator lets you test your app on your Mac
    13. 1.13. What happened?
      1. 1.13.1. Unless the UI components are hooked up to the code, nothing is going to happen.
    14. 1.14. Use Interface Builder to connect UI controls to code
    15. 1.15. Interface Builder lists which events a component can trigger
    16. 1.16. Elements dispatch events when things happen to them
    17. 1.17. Connect your events to methods
    18. 1.18. Your iPhone Toolbox
  6. 2. iPhone app patterns: Hello @twitter!
    1. 2.1. First we need to figure out what Mike (really) wants
    2. 2.2. App design rules—the iPhone HIG
      1. 2.2.1. Application types
    3. 2.3. HIG guidelines for pickers and buttons
    4. 2.4. Create a new View-based project for InstaTwit
      1. 2.4.1. Start with the view layout
    5. 2.5. The life of a root view
    6. 2.6. First, get the data from Mike
    7. 2.7. Use pickers when you want controlled input
      1. 2.7.1. When in doubt, check out Apple's API documentation
    8. 2.8. Fill the picker rows with Mike's data
    9. 2.9. Pickers get their data from a datasource...
      1. 2.9.1. ...and tell their delegates when something happens.
    10. 2.10. There's a pattern for that
      1. 2.10.1. Controls have their own specific datasources and delegates
      2. 2.10.2. Protocols tell you what methods (messages) you need to implement
    11. 2.11. First, declare that the controller conforms to both protocols
      1. 2.11.1. Next, add Mike's activities and feelings to the implementation file
    12. 2.12. The datasource protocol has two required methods
    13. 2.13. Connect the datasource just like actions and outlets
    14. 2.14. There's just one method for the delegate protocol
    15. 2.15. The button needs to be connected to an event
      1. 2.15.1. Without an action, your button won't work!
    16. 2.16. Add the IBOutlet and property to our view controller
    17. 2.17. Connect the picker to our outlet
    18. 2.18. Use our picker reference to pull the selected values
    19. 2.19. Your iPhone Toolbox
  7. 3. objective-c for the iPhone: Twitter needs variety
    1. 3.1. Renee is catching on....
    2. 3.2. Make room for custom input
    3. 3.3. Header files describe the interface to your class
    4. 3.4. Auto-generated accessors also handle memory management
      1. 3.4.1. Objective-C can automatically release references, too.
    5. 3.5. To keep your memory straight, you need to remember just two things
    6. 3.6. But when Mike's finished typing...
    7. 3.7. Customize your UITextField
      1. 3.7.1. Next change the label on the return key
    8. 3.8. Components that use the keyboard ask it to appear...
      1. 3.8.1. ...by passing messages to other objects
    9. 3.9. Ask the textField to give up focus
    10. 3.10. Messages in Objective-C use named arguments
    11. 3.11. Use message passing to tell our view controller when the Done button is pressed
    12. 3.12. Something's still not right
      1. 3.12.1. Build the tweet with strings
    13. 3.13. Your Objective-C Toolbox
  8. 4. multiple views: A table with a view
    1. 4.1. So, how do these views fit together?
    2. 4.2. The navigation template pulls multiple views together
    3. 4.3. The navigation template starts with a table view
    4. 4.4. A table is a collection of cells
      1. 4.4.1. Each drink gets its own cell... sorta
    5. 4.5. Just a few more drinks
    6. 4.6. Plists are an easy way to save and load data
    7. 4.7. Arrays (and more) have built-in support for plists
    8. 4.8. Use a detail view to drill down into data
    9. 4.9. A closer look at the detail view
    10. 4.10. Use the navigation controller to switch between views
    11. 4.11. Navigation controllers maintain a stack of views
      1. 4.11.1. We'll use the tap notification in the table view delegate
    12. 4.12. Instantiate a view controller like any other class
    13. 4.13. Dictionaries store information as key-value pairs
    14. 4.14. Debugging—the dark side of iPhone development
      1. 4.14.1. Warnings can help find problems without debugging
    15. 4.15. First stop on your debugging adventure: the console
    16. 4.16. Interact with your application while it's running
      1. 4.16.1. And when it's about to stop running
    17. 4.17. Xcode supports you after your app breaks, too
    18. 4.18. The Xcode debugger shows you the state of your application
    19. 4.19. What the heck is going on?
    20. 4.20. Your iPhone Toolbox
  9. 5. plists and modal views: Refining your app
    1. 5.1. It all started with Sam...
      1. 5.1.1. DrinkMixer
    2. 5.2. Use the debugger to investigate the crash
      1. 5.2.1. We're trying to stuff a dictionary into a string
    3. 5.3. Update your code to handle a plist of dictionaries
    4. 5.4. The detail view needs data
    5. 5.5. Each dictionary has all the information we need
    6. 5.6. We have a usability problem
    7. 5.7. Use a disclosure indicator if your cell leads to more information
    8. 5.8. Sales were going strong...
    9. 5.9. Use navigation controller buttons for editing
    10. 5.10. The button should create a new view
    11. 5.11. We need a view... but not necessarily a new view
    12. 5.12. The view controller defines the behavior for the view
    13. 5.13. A nib file contains the UI components and connections...
      1. 5.13.1. ...and information about the nib's File's Owner
    14. 5.14. You can subclass and extend views like any other class
    15. 5.15. Use Xcode to create a view controller without a nib
    16. 5.16. Modal views focus the user on the task at hand...
      1. 5.16.1. ...like adding or editing items
    17. 5.17. Any view can present a modal view
    18. 5.18. Our view doesn't have a navigation bar
    19. 5.19. Create the save and cancel buttons
    20. 5.20. Write the save and cancel actions
    21. 5.21. Your iPhone Toolbox
  10. 6. saving, editing, and sorting data: Everyone's an editor...
    1. 6.1. Sam is ready to add a Red-Headed School Girl...
    2. 6.2. ...but the keyboard is in the way
    3. 6.3. We need to wrap our content in a scroll view
    4. 6.4. The scroll view is the same size as the screen
    5. 6.5. The keyboard changes the visible area
    6. 6.6. iPhone notifies you about the keyboard
    7. 6.7. Register with the default notification center for events
      1. 6.7.1. Then unregister when you're done
    8. 6.8. Keyboard events tell you the keyboard state and size
    9. 6.9. The table view doesn't know its data has changed
    10. 6.10. You need to ask the table view to reload its data
    11. 6.11. The array is out of order, too
      1. 6.11.1. We can sort our array using NSSortDescriptor
    12. 6.12. Table views have built-in support for editing and deleting
    13. 6.13. Your iPhone Development Toolbox
  11. 7. tab bars and core data: Enterprise apps
    1. 7.1. HF bounty hunting
    2. 7.2. Choose a template to start iBountyHunter
    3. 7.3. Drawing how iBountyHunter works...
    4. 7.4. Build the fugitive list view
    5. 7.5. Next up: the captured view
      1. 7.5.1. A view's contents are actually subviews
    6. 7.6. After a quick meeting with Bob...
    7. 7.7. Core Data lets you focus on your app
      1. 7.7.1. But wait, there's more!
    8. 7.8. Core Data needs to know what to load
      1. 7.8.1. We need to define our types...
    9. 7.9. Core Data describes entities with a Managed Object Model
    10. 7.10. Build your Fugitive entity
      1. 7.10.1. Exactly!
    11. 7.11. Whip up a Fugitive class without writing a line
      1. 7.11.1. Our generated Fugitive class matches our Managed Object Model
      2. 7.11.2. NSManagedObject handles storage and memory for generated properties
      3. 7.11.3. NSManagedObject also implements the properties
    12. 7.12. Use an NSFetchRequest to describe your search
      1. 7.12.1. Ask the Managed Object Context to fetch data using your NSFetchRequest
    13. 7.13. Add the database as a resource
      1. 7.13.1. Back to the Core Data stack
    14. 7.14. The template sets things up for a SQLite DB
      1. 7.14.1. iPhone Apps are read-only
    15. 7.15. The iPhone's application structure defines where you can read and write
      1. 7.15.1. Use the Documents directory to store user data
    16. 7.16. Copy the database to the correct place
    17. 7.17. To be continued...
    18. 7.18. Your Core Data Toolbox
  12. 8. migrating and optimizing with core data: Things are changing
    1. 8.1. Bob needs documentation
    2. 8.2. Everything stems from our object model
    3. 8.3. The data hasn't been updated
      1. 8.3.1. Core Data caught a mismatch between our DB and our model
    4. 8.4. Data migration is a common problem
    5. 8.5. We need to migrate the old data into the new model
      1. 8.5.1. Our two models need different versions
    6. 8.6. Xcode makes it easy to version the data model
    7. 8.7. Core Data can "lightly" migrate data
    8. 8.8. Bob has some design input
      1. 8.8.1. The Managed Object Context saves new or changed items
    9. 8.9. A quick demo with Bob
    10. 8.10. Use predicates for filtering data
      1. 8.10.1. NSFetchRequest concepts are nearly identical to SQL
    11. 8.11. We need to set a predicate on our NSFetchRequest
    12. 8.12. Core Data controller classes provide efficient results handling
      1. 8.12.1. Table views and NSFetchedResultsControllers are made for each other
    13. 8.13. Time for some high-efficiency streamlining
    14. 8.14. Next we need to change the search to use the controller...
    15. 8.15. Refactor viewWillAppear to use the controller
    16. 8.16. We need to refresh the data
      1. 8.16.1. NSFetchedResultsController can check for changes
    17. 8.17. Your Data Toolbox
  13. 9. camera, map kit, and core location: Proof in the real world
    1. 9.1. For Bob, payment requires proof!
      1. 9.1.1. Flip over for the detail view!
    2. 9.2. The way to the camera...
      1. 9.2.1. The iPhone isn't the only device using apps
    3. 9.3. There's a method for checking
    4. 9.4. Prompt the user with action sheets
      1. 9.4.1. We'll use action sheets to let the user pick the image source
    5. 9.5. Bob needs the where, in addition to the when
    6. 9.6. Core Location can find you in a few ways
      1. 9.6.1. Core Location relies on the LocationManager
    7. 9.7. Add a new framework
      1. 9.7.1. Then update the header file
    8. 9.8. Just latitude and longitude won't work for Bob
    9. 9.9. Map Kit is new with iPhone 3.0
    10. 9.10. A little custom setup for the map
    11. 9.11. Annotations require a little more finesse
    12. 9.12. Your extras Toolbox
    13. 9.13. It's been great having you here!
  14. A. leftovers: The top 6 things (we didn't cover)
    1. A.1. #1. Internationalization and Localization
      1. A.1.1. Localizing nibs
    2. A.2. Localizing string resources
    3. A.3. Generating your strings file
    4. A.4. #2. UIWebView
      1. A.4.1. Using UIWebView
    5. A.5. UIWebView properties
      1. A.5.1. Loading generated content
      2. A.5.2. The UIWebView supports a delegate, too
    6. A.6. #3. Device orientation and view rotation
      1. A.6.1. The view controller tells the iPhone OS what orientations it supports
    7. A.7. Handling view rotations
    8. A.8. Handling rotation with two different views
    9. A.9. #4. View animations
      1. A.9.1. Animating table view updates
      2. A.9.2. Animating view and control changes
    10. A.10. #5. Accelerometer
      1. A.10.1. All you need is the UIAccelerometer
    11. A.11. Understanding the device acceleration
    12. A.12. #6. A word or two about gaming...
      1. A.12.1. Multitouch
    13. A.13. Quartz and OpenGL
      1. A.13.1. Quartz
      2. A.13.2. OpenGL
      3. A.13.3. Game Kit
  15. B. preparing an app for distribution: Get ready for the App Store
    1. B.1. Apple has rules
      1. B.1.1. Start at the Apple Developer Portal
      2. B.1.2. First get your Development Certificate
    2. B.2. The Provisioning Profile pulls it all together
    3. B.3. Keep track in the Organizer
    4. B.4. A few final tips...
O'Reilly logo

how to use this book: Intro

I can't believe they put that in an iPhone development book!

In this section, we answer the burning question: "So why DID they put that in an iPhone development book?"

Who is this book for?

If you can answer "yes" to all of these:

❶ Do you have previous development experience?

❷ Do you want to learn, understand, remember, and apply important iPhone design and development concepts so that you can write your own iPhone apps, and start selling them in the App Store?

It definitely helps if you've already got some object-oriented chops, too. Experience with Mac development is helpful, but definitely not required.

❸ Do you prefer stimulating dinner party conversation to dry, dull, academic lectures?

this book is for you.

Who should probably back away from this book?

If you can answer "yes" to any of these:

❶ Are you completely new to software development?

Check out Head First Java for an excellent introduction to object-oriented development, and then come back and join us in iPhoneville.

❷ Are you already developing iPhone apps and looking for a reference book on Objective-C?

❸ Are you afraid to try something different? Would you rather have a root canal than mix stripes with plaid? Do you believe that a technical book can't be serious if there's a bounty hunter in it?

this book is not for you.

[Note from marketing: this book is for anyone with a credit card. Or cash. Cash is nice, too – Ed]

We know what you're thinking.

"How can this be a serious iPhone development book?"

"What's with all the graphics?"

"Can I actually learn it this way?"

And we know what your brain is thinking.

Your brain craves novelty. It's always searching, scanning, waiting for something unusual. It was built that way, and it helps you stay alive.

So what does your brain do with all the routine, ordinary, normal things you encounter? Everything it can to stop them from interfering with the brain's real job—recording things that matter. It doesn't bother saving the boring things; they never make it past the "this is obviously not important" filter.

How does your brain know what's important? Suppose you're out for a day hike and a tiger jumps in front of you. What happens inside your head and body?

Neurons fire. Emotions crank up. Chemicals surge.

And that's how your brain knows...

This must be important! Don't forget it!

But imagine you're at home, or in a library. It's a safe, warm, tiger-free zone. You're studying. Getting ready for an exam. Or trying to learn some tough technical topic your boss thinks will take a week, ten days at the most.

Just one problem. Your brain's trying to do you a big favor. It's trying to make sure that this obviously non-important content doesn't clutter up scarce resources. Resources that are better spent storing the really big things. Like tigers. Like the danger of fire. Like how you should never again snowboard in shorts.

And there's no simple way to tell your brain, "Hey brain, thank you very much, but no matter how dull this book is, and how little I'm registering on the emotional Richter scale right now, I really do want you to keep this stuff around."

Your brain thinks THIS is important.

Great. Only 540 more dull, dry, boring pages.

Your brain thinks THIS isn't worth saving.

Metacognition: thinking about thinking

If you really want to learn, and you want to learn more quickly and more deeply, pay attention to how you pay attention. Think about how you think. Learn how you learn.

Most of us did not take courses on metacognition or learning theory when we were growing up. We were expected to learn, but rarely taught to learn.

But we assume that if you're holding this book, you really want to learn about iPhone development. And you probably don't want to spend a lot of time. And since you're going to build more apps in the future, you need to remember what you read. And for that, you've got to understand it. To get the most from this book, or any book or learning experience, take responsibility for your brain. Your brain on this content.

The trick is to get your brain to see the new material you're learning as Really Important. Crucial to your well-being. As important as a tiger. Otherwise, you're in for a constant battle, with your brain doing its best to keep the new content from sticking.

So just how DO you get your brain to think that iPhone development is a hungry tiger?

There's the slow, tedious way, or the faster, more effective way. The slow way is about sheer repetition. You obviously know that you are able to learn and remember even the dullest of topics if you keep pounding the same thing into your brain. With enough repetition, your brain says, "This doesn't feel important to him, but he keeps looking at the same thing over and over and over, so I suppose it must be."

The faster way is to do anything that increases brain activity, especially different types of brain activity. The things on the previous page are a big part of the solution, and they're all things that have been proven to help your brain work in your favor. For example, studies show that putting words within the pictures they describe (as opposed to somewhere else in the page, like a caption or in the body text) causes your brain to try to makes sense of how the words and picture relate, and this causes more neurons to fire. More neurons firing = more chances for your brain to get that this is something worth paying attention to, and possibly recording.

A conversational style helps because people tend to pay more attention when they perceive that they're in a conversation, since they're expected to follow along and hold up their end. The amazing thing is, your brain doesn't necessarily care that the "conversation" is between you and a book! On the other hand, if the writing style is formal and dry, your brain perceives it the same way you experience being lectured to while sitting in a roomful of passive attendees. No need to stay awake.

But pictures and conversational style are just the beginning.

I wonder how I can trick my brain into remembering this stuff...

Here's what WE did:

We used pictures, because your brain is tuned for visuals, not text. As far as your brain's concerned, a picture really is worth a thousand words. And when text and pictures work together, we embedded the text in the pictures because your brain works more effectively when the text is within the thing the text refers to, as opposed to in a caption or buried in the text somewhere.

We used redundancy, saying the same thing in different ways and with different media types, and multiple senses, to increase the chance that the content gets coded into more than one area of your brain.

We used concepts and pictures in unexpected ways because your brain is tuned for novelty, and we used pictures and ideas with at least some emotional content, because your brain is tuned to pay attention to the biochemistry of emotions. That which causes you to feel something is more likely to be remembered, even if that feeling is nothing more than a little humor, surprise, or interest.

We used a personalized, conversational style, because your brain is tuned to pay more attention when it believes you're in a conversation than if it thinks you're passively listening to a presentation. Your brain does this even when you're reading.

We included loads of activities, because your brain is tuned to learn and remember more when you do things than when you read about things. And we made the exercises challenging-yet-do-able, because that's what most people prefer.

We used multiple learning styles, because you might prefer step-by-step procedures, while someone else wants to understand the big picture first, and someone else just wants to see an example. But regardless of your own learning preference, everyone benefits from seeing the same content represented in multiple ways.

We include content for both sides of your brain, because the more of your brain you engage, the more likely you are to learn and remember, and the longer you can stay focused. Since working one side of the brain often means giving the other side a chance to rest, you can be more productive at learning for a longer period of time.

And we included stories and exercises that present more than one point of view, because your brain is tuned to learn more deeply when it's forced to make evaluations and judgments.

We included challenges, with exercises, and by asking questions that don't always have a straight answer, because your brain is tuned to learn and remember when it has to work at something. Think about it—you can't get your body in shape just by watching people at the gym. But we did our best to make sure that when you're working hard, it's on the right things. That you're not spending one extra dendrite processing a hard-to-understand example, or parsing difficult, jargon-laden, or overly terse text.

We used people. In stories, examples, pictures, etc., because, well, because you're a person. And your brain pays more attention to people than it does to things.

Here's what YOU can do to bend your brain into submission

So, we did our part. The rest is up to you. These tips are a starting point; listen to your brain and figure out what works for you and what doesn't. Try new things.

Cut this out and stick it on your refrigerator.

Slow down. The more you understand, the less you have to memorize.

Don't just read. Stop and think. When the book asks you a question, don't just skip to the answer. Imagine that someone really is asking the question. The more deeply you force your brain to think, the better chance you have of learning and remembering.

Do the exercises. Write your own notes.

We put them in, but if we did them for you, that would be like having someone else do your workouts for you. And don't just look at the exercises. Use a pencil. There's plenty of evidence that physical activity while learning can increase the learning.

Read the "There are No Dumb Questions"

That means all of them. They're not optional sidebars—they're part of the core content! Don't skip them.

Make this the last thing you read before bed. Or at least the last challenging thing.

Part of the learning (especially the transfer to long-term memory) happens after you put the book down. Your brain needs time on its own, to do more processing. If you put in something new during that processing time, some of what you just learned will be lost.

Drink water. Lots of it.

Your brain works best in a nice bath of fluid. Dehydration (which can happen before you ever feel thirsty) decreases cognitive function.

Talk about it. Out loud.

Speaking activates a different part of the brain. If you're trying to understand something, or increase your chance of remembering it later, say it out loud. Better still, try to explain it out loud to someone else. You'll learn more quickly, and you might uncover ideas you hadn't known were there when you were reading about it.

Listen to your brain.

Pay attention to whether your brain is getting overloaded. If you find yourself starting to skim the surface or forget what you just read, it's time for a break. Once you go past a certain point, you won't learn faster by trying to shove more in, and you might even hurt the process.

Feel something!

Your brain needs to know that this matters. Get involved with the stories. Make up your own captions for the photos. Groaning over a bad joke is still better than feeling nothing at all.

Create something!

Apply this to your daily work; use what you are learning to make decisions on your projects. Just do something to get some experience beyond the exercises and activities in this book. All you need is a pencil and a problem to solve... a problem that might benefit from using the tools and techniques you're studying for the exam.

Read me

This is a learning experience, not a reference book. We deliberately stripped out everything that might get in the way of learning whatever it is we're working on at that point in the book. And the first time through, you need to begin at the beginning, because the book makes assumptions about what you've already seen and learned.

We start off by building an app in the very first chapter.

Believe it or not, even if you've never developed for the iPhone before, you can jump right in and starting building apps. You'll also learn your way around the tools used for iPhone development.

We don't worry about preparing your app to submit to the App Store until the end of book.

In this book, you can get on with the business of learning how to create iPhone apps without stressing over the packaging and distribution of your app out of the gate. But, we know that's what everyone who wants to build an iPhone app ultimately wants to do, so we cover that process (and all it's glorious gotchas) in an Appendix at the end.

We focus on what you can build and test on the simulator.

The iPhone SDK comes with a great (and free!) tool for testing your apps on your computer. The simulator lets you try out your code without having to worry about getting it in the app store or on a real device. But, it also has its limits. There's some cool iPhone stuff you just can't test on the simulator, like the accelerometer and compass. So we don't cover those kinds of things in very much detail in this book since we want to make sure you're creating and testing apps quickly and easily.

The activities are NOT optional.

The exercises and activities are not add-ons; they're part of the core content of the book. Some of them are to help with memory, some are for understanding, and some will help you apply what you've learned. Don't skip the exercises. Even crossword puzzles are important—they'll help get concepts into your brain the way you'll see them on the PMP exam. But more importantly, they're good for giving your brain a chance to think about the words and terms you've been learning in a different context.

The redundancy is intentional and important.

One distinct difference in a Head First book is that we want you to really get it. And we want you to finish the book remembering what you've learned. Most reference books don't have retention and recall as a goal, but this book is about learning, so you'll see some of the same concepts come up more than once.

The Brain Power exercises don't have answers.

For some of them, there is no right answer, and for others, part of the learning experience of the Brain Power activities is for you to decide if and when your answers are right. In some of the Brain Power exercises, you will find hints to point you in the right direction.

System requirements

To develop for the iPhone, you need an Intel-based Mac, period. We wrote this book using Snow Leopard and Xcode 3.2. If you are running Leopard with an older version of Xcode, we tried to point out where there were places that would trip you up. For some of the more advanced capabilities, like the accelerometer and the camera, you'll need an actual iPhone or iPod Touch and to be a registered developer. In Chapter 1, we point you in the direction to get the SDK and Apple documentation, so don't worry about that for now.

The technical review team

Michael Morrison

Joe Heck

Eric Shepherd

Technical Reviewers:

For this book we had an amazing, elite group of tech reviewers. They did a fantastic job, and we're really grateful for their incredible contribution.

Joe Heck is a software developer, technology manager, author, and instructor who's been involved with computing for 25 years, and developing for the iPhone platform since the first beta release. Employed at the Walt Disney Interactive Media Group, Joe is involved in various technologies and development platforms, and assisted the development team for Disney's iPhone game "Fairies Fly." He's the founder of the Seattle Xcoders developer group, which supports Macintosh and iPhone development in the Seattle area, and the author of SeattleBus, an iPhone app that provides real-time arrival and departure times of Seattle public transportation (available at the iPhone App Store). He also knows a ton about iPhones, and made sure that we were technically solid in every facet of the book. His attention to detail means that all of our nitty gritty answers are complete and correct.

Eric Shepherd got started programming at age nine and never looked back. He's been a technical writer, writing developer documentation since 1997, and is currently the developer documentation lead at Mozilla. In his spare time, he writes software for old Apple II computers—because his day job just isn't geeky enough—and spends time with his daughter. Eric's review feedback was hugely helpful. His input meant that any typos or bugs we left in the code were caught and fixed. His thorough review means that no one else has to go through the problems he had in actually making the code work.

Michael Morrison is a writer, developer, and author of Head First JavaScript, Head First PHP & MySQL, and even a few books that don't have squiggly arrows, stick figures, and magnets. Michael is the founder of Stalefish Labs (www.stalefishlabs.com), an edutainment company specializing in games, toys, and interactive media, including a few iPhone apps. Michael spends a lot of time wearing helmets, be it for skateboarding, hockey, or iPhone debugging. Since he has iPhone Head First experience, Mike was a great combo to have helping us. Reviewing in both capacities, he was nice enough to always propose a solution for us when he found a layout problem, which makes those comments easier to take!

All three of these guys did a tremendous amount of review at the end in a short period of time and we really appreciate it! Thanks so much!

Acknowledgments

Our editors:

Thanks to Courtney Nash, who was there from the beginning and took us through to production, which normally is a long time, but not for us! She pushed us to make sure that every step of the way the book stayed true to its Head First title, even when it would've been WAY easier not to. She knows the chapter we're talking about.

Courtney Nash

And to Brett McLaughlin, who started us off on this book by responding to an IM that said "What do you think about Head First iPhone?" and got it turned into a book. He also played the learner (complete with the occasional complaining) for us throughout the book and was a big help in pacing the initial chapters.

Brett McLaughlin

Mark Reese

The O'Reilly team:

To Karen Shaner, who handled the tech review process, which got a little—ahem—accelerated there at the end. And also to Laurie Petrycki, who trusted us to do another Head First book less than a year after the last one. Finally, to our design editor Mark Reese for his graphics and layout help.

Our friends and family:

To all of the Pilones and the Chadwicks, who put up with a lot being pushed until October while we worked on the book and gave us the support we needed to become grown ups who can write this stuff. To Dan's brother, Paul, whose relentless "Seriously, Macs are awesome" mantra convinced Dan to get one and find out what all this OS X development stuff is about.

To Vinny and Nick, who put up with a good bit of shuffling around the past couple of months so we could get this done, and are totally going to get some major Mommy and Daddy time now. They both want iPhones.

To our friends who listened to the whining about getting this thing done and who took the kids for a couple hours here and there so we could get finished and encouraged us when we needed it!

Finally, to Apple, as silly as it sounds, because without the iPhone being such a unique and game-changing device, there would be no book!v

Safari® Books Online

Safari® Books Online is an on-demand digital library that lets you easily search over 7,500 technology and creative reference books and videos to find the answers you need quickly.

With a subscription, you can read any page and watch any video from our library online. Read books on your cell phone and mobile devices. Access new titles before they are available for print, and get exclusive access to manuscripts in development and post feedback for the authors. Copy and paste code samples, organize your favorites, download chapters, bookmark key sections, create notes, print out pages, and benefit from tons of other time-saving features.

O'Reilly Media has uploaded this book to the Safari Books Online service. To have full digital access to this book and others on similar topics from O'Reilly and other publishers, sign up for free at http://my.safaribooksonline.com.

The best content for your career. Discover unlimited learning on demand for around $1/day.