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

Chapter 1. getting started: Going mobile

I just don't see what all this iPhone fuss is about. My phone works just fine...

The iPhone changed everything. It's a gaming platform, a personal organizer, a full web-browser, oh yeah, and a phone. The iPhone is one of the most exciting devices to come out in some time, and with the opening of the App Store, it's an opportunity for independent developers to compete worldwide with big-name software companies. All you need to release your own app are a couple of software tools, some knowledge, and enthusiasm. Apple provides the software, and we'll help you with the knowledge; we're sure you've got the enthusiasm covered.

There's a lot of buzz and a lot of money tied up in the App Store...

Mobile applications aren't just ported desktop apps

There are about a billion good reasons to get into the App Store, and now it's time for you to jump in. To get there from here, you'll learn about designing and implementing an iPhone app, but it's not the same as developing for the desktop, or writing a web application.

It's important to think an iPhone application through from the beginning. You need to constantly ask yourself "What is it the user is trying to do?" Get rid of everything else, minimize the input they have to provide, and keep it focused.

This is NOT the same as this

iPhone apps are not small desktop apps

There's a lot of talk about how the iPhone is a small computer that people carry with them. That's definitely true, but it doesn't mean iPhone apps are just small desktop apps. Some of the most important issues that you'll encounter designing an app for the iPhone:

  • iPhones have a small screen and are task-focused

    Even with the iPhone's fantastic screen, it's still relatively small (320×480). You need to put real thought into every screen and keep it focused on the specific task the user is doing.

  • iPhones have limited CPU and memory

    On top of that, there's no virtual memory and every bit of CPU oomph you use means more battery drain. iPhone OS monitors the system closely and if you go crazy with memory usage, it'll just kill your app. And no one wants that.

  • Only one application can run at a time

    If it's your application running, why should you care? Because if anything else happens, like the phone rings, a text message comes in, the user clicks on a link, etc., your app gets shut down and the user moves on to another application. You need to be able to gracefully exit at any time and be able to put users back into a reasonable spot when they return.

Anatomy of an iPhone app

Before we dive into creating our first app, let's take a look at what makes up a typical iPhone app.

First we have one or more views...

iPhone apps are made up of one or more views—in a normal app, these views have GUI components on them like text fields, buttons, labels, etc. Games have views too, but typically don't use the normal GUI components. Games generally require their own custom interfaces that are created with things like OpenGL or Quartz.

Views can be built using code, graphically using Interface Builder, or some combination of both. Most apps use a mix.

...then the code that makes the views work...

iPhone apps have a clean separation between the GUI (the view) and the actual code that provides the application logic. In general, each view has a View Controller behind it that reacts to button presses, table row selection, tilting the phone, etc. This code is almost always written in Objective-C using Apple's IDE (integrated development environment), Xcode.

Xcode is the IDE of choice for writing iPhone apps. It includes a number of application templates to get you started.

...and any other resources, all packaged into your application.

If you're new to developing for OS X you might be surprised to find out that applications (iPhone and full desktop apps) are really just directories. Any app directory contains the actual binary executable, some metadata about the application (the author, the icon filename, code signatures, etc.) and any other application resources like images, application data, help files, etc. iPhone applications behave the same way, so when you tell Xcode about other resources your application needs, it will bundle them up for you when you build the application.

Every iPhone app has some resources associated with it. At a minimum, your application will have an icon file, an Info.plist that has information about the application itself, and the actual binary. Other common resources are interface files, called nibs.

Pictures

Date

Now let's get started on your first iPhone App...

Mike can't make a decision

Mike's a great guy, but he never knows what he wants to do. Help him save time waffling about what to do, and give him a straightforward answer.

The way I see it is I already made the decision to buy an iPhone... I shouldn't have to think again!

We'll write Mike an app.

Mike has an iPhone, so let's write him an app that requires a simple button push to tell him what to do when he needs to make a decision.

Mike

Make a good first impression

When users start up your application, the first thing they see is your view. It needs to be usable and focused on what your application is supposed to do. Throughout this book, whenever we start a new application, we're going to take a little time to sketch up what we want it to look like.

Our first application is pretty straightforward: it is going to be a single view with a button that Mike can press to get a decision. To keep things simple, we'll change the label of the button to show what he should do after he pushes it.

This is the status bar – your app can choose to hide it, but unless you're writing a game, you should probably leave it.

Press the button and the label text will change to tell Mike what he should do.

This is the iPhone simulator – this lets you run and test your application without using a real phone. We'll talk more about it later.

The iPhone screen is 320 × 480 pixels.

We'll sketch up our GUIs for each application before we build them. Pen & paper are some of the best mockup tools you could use.

Let's call it iDecide.

iDecide

This is a button

What should I do?

Now that we know what to build, let's get into the tools.

It all starts with the iPhone SDK

It's time to go get some tools. Head over to http://developer.apple.com/iphone. You can download the SDK (and other useful Apple development resources) for free with the basic registration, but to distribute a completed app on the App Store or install your app on the iPhone for testing you need to become a paid Standard or Enterprise Developer. The SDK comes with a simulator for testing directly on your Mac, so free registration is all you'll need for now.

The SDK comes with Xcode, Instruments, Interface Builder, and the iPhone Simulator. Code for the iPhone is written in Xcode using Objective-C. Interface Builder is used for graphically editing GUIs, Instruments helps you assess memory usage and performance for your app, and the Simulator is used for testing.

  • Register as a developer at http://developer.apple.com/iphone.

  • Download the latest SDK; this book is based on the 3.1 SDK. Just look for the Download button at the top of the page.

  • Install the SDK. Once the Installation completes, you can find Xcode.app in /Developer/Applications. Just double-click it to start it up.

You will probably want to drag it onto your Dock—we're going to be using it a lot.

there are no: Dumb Questions

Q:

What are the most important things to consider when developing a mobile app?

A:

There are two key things to keep in mind when developing a mobile application. First, the device has limited resources: memory, CPU, storage, Net access speed (if they have access at all), etc. Second, usage patterns are different for mobile applications. Mobile apps are generally convenience applications—users want to fire up your application, quickly accomplish their goal, and go back to what they were doing in the real world.

Q:

I've developed for mobile platforms before, and it was a mess. Nothing worked the same between different devices, you couldn't count on the screen size, they didn't even have the same number of buttons on different devices! Is this any better?

A:

YES! For the most part, developing for iPhone avoids these problems. iPhones all have a 320×480 screen, an accelerometer, a single home key, etc. However...

Q:

There are several different models of the iPhone out there. Are they all the same? What about the iPod Touch?

A:

Not all iPhone and iPod Touch devices are the same. For example, not all devices have a camera or GPS. Net access speeds vary by device as well depending on whether they're connected to EDGE, 3G, or Wifi. To make matters more complicated, the iPhone 3GS has a faster processor and better video card than previous iPhone models. If you take advantage of any features that might not be present on all devices you must make sure your code can handle not having that feature available. Apple will test for this (for example, trying to use the camera on a first generation iPod Touch) and reject your application if it doesn't accomodate a device properly.

Q:

What language does the iPhone use?

A:

iPhone apps are generally written in Objective-C, an object-oriented language that is also used for Mac development. However, you can use C and even C++ on the iPhone. Since the GUI and Core Framework libraries for the iPhone are written in Objective-C, most developers use Objective-C for their application; however, it's not uncommon to see support libraries written in C.

Q:

Do I have to use an IDE? I'm really a command-line kinda developer.

A:

Technically speaking, no, you don't have to use the Xcode IDE for straight development. However, the IDE makes iPhone development so much easier that you really should ask yourself if you have a good reason for avoiding it, especially since to deploy onto an actual iPhone or the simulator for testing, it's mandatory. This book uses the Xcode IDE as well as other Apple development tools like Interface Builder, and we encourage you to at least try them out before you abandon them.

Q:

Can I give applications I write out to friends?

A:

Yes and no. First, if you want to put an application on anyone's actual device (including your own) you'll need to become a registered Apple iPhone Developer. Once you've done that, you can register a device and install your application on it. However, that's not really a great way to get your application out there, and Apple limits how many devices you can register this way. It's great for testing your application, but not how you want to go about passing it around.

A better way is to submit your application to the iTunes App Store. You can choose to distribute your application for free or charge for it, but by distributing it through the iTunes App Store, you make your application available to the world (and maybe make some money, too!). We'll talk more about distributing apps later in the book.

Q:

Can I develop an app for the iPhone then rebuild it for other phones like Windows Mobile, Android, or Blackberries?

A:

In a word, no. When you develop for iPhone, you use Apple's iPhone frameworks, like Cocoa Touch, as well as Objective-C. Neither of these are available on other devices.

Now let's get started. Launch Xcode...

Xcode includes app templates to help you get started

When you start Xcode, you'll get a welcome screen where you can select Create a New Project. You'll get this dialog:

This is the very same Xcode that you'd use to develop for the Mac. Since we're working with the iPhone, make sure iPhone OS Application is selected..

These are the basic App templates. Based on your selection, different code and files are populated for you.

If you click on each project type, the description here will help fill you in on some details.

As we go through the book, we'll use different types of projects and discuss why you'd choose one over another for each app. For iDecide, we have one screen (or view) that we're not going to be flipping or anything, so start with the View-based Application and name it iDecide.

The Xcode template includes more than just source code.

Files

Header files describe the interface for the classes in the project you selected.

The .m files contain the basic implementation files for the app type you selected.

Resources

Databases, plists, and other types of data are stored in here for your app.

This is the folder where you'll store the icon for your app and any other images you need.

Frameworks

Frameworks are development libraries – depending on what your application does, you'll need different frameworks. For example, there's a MapKit framework, a Core Data framework, etc.

Xcode will generate at least one view for your template, which is a *.xib file.

Root View

The frameworks that your template type needs are already included.

Xcode is the hub of your iPhone project...

When Xcode opens with your new View-based project, it will be populated with all of the files that you see below. We'll be using some of the other tools that came with the SDK (especially Interface Builder and the Simulator), but they are all working with the files that are included here.

The files and frameworks shown were stubbed out based on our selection of a View-based application. As we go forward, we'll use different types of apps and that will lead to different defaults.

Class files are the Objective C files that your App will use – most code will be written here.

Other sources include your main function and precompiled info.

Resources contains all of your Interface Builder (.xib) files, pictures, data, and other stuff that your app will need to run.

Frameworks shows a list of the libraries you're using.

Folder groupings in Xcode are not file locations.

Here is where you can configure whether to build your app for the simulator or a real device. We'll stick with the simulator throughout the book.

The toolbar includes options for setting breakpoints, building and running your application, and more. We'll mostly use Build and Debug.

The Detail View shows a list of the selected files. Whatever is selected will show here

You don't have to group your files this way, but this is the default from the template. This grouping works well for us, so we'll leave it alone.

The Editor Pane shows your file with the appropriate editor loaded and allows you to work directly with the code, plist, whatever.

...and plays a role in every part of writing your app

Xcode is much more than just a text editor. As you've already seen, Xcode includes the templates to get you started developing an application. Depending on your application, you may use all of a template or just parts of it, but you'll almost always start with one of them. Once you get your basic app template in place, you'll use Xcode for a lot more:

  • Maintaining your project resources

    Xcode will create a new directory for your project and sort the various files into subdirectories. You don't have to stick with the default layout, but if you decide to reorganize, do it from within Xcode. Xcode also has built-in support for version control tools like Subversion and can be used to checkout and commit your project changes.

  • Editing your code and resources

    You'll use Xcode to edit your application code, and it supports a variety of languages beyond just Objective-C. Xcode also has a number of built-in editors for resource files like plists (we'll talk more about them later on). For resources Xcode doesn't handle natively, like UI definition (.xib) files, double-clicking on one of those files in Xcode will launch the appropriate editor, in this case Interface Builder. Some file types Xcode can only view, like pictures, or it will merely list, like sound files.

  • Building and testing your application

    Xcode comes with all of the compilers necessary to build your code and generate a working application. Once your application is compiled, Xcode can install it on the iPhone Simulator or a real device. Xcode includes a top-notch debugger with both graphical and command-line interfaces to let you debug your application. You can launch profiling tools like Instruments to check for memory or performance issues.

  • Prepare your application for sale

    Once you get your application thoroughly tested and you're ready to sell it, Xcode manages your provisioning profiles and code signing certificates that let you put your application on real devices or upload it to the iTunes App Store for sale.

OK, enough talking about Xcode: double-click on iDecideViewController.xib and we'll start with the view.

Build your interface using... Interface Builder

When you open any *.xib file in Interface Builder, it will automatically show the Main window, your view, and a library of UI elements. Interface Builder allows you to drag and drop any of the basic library elements into your view, edit them, and work with the connections between the code and these elements. All of these elements come from the Cocoa Touch framework, a custom UI framework for the iPhone and the iPod Touch.

This is the Main window. It shows the objects and views that are currently created for that particular nib. File's Owner and the First Responder exist for every nib, and the others will vary. We'll talk about both in much greater detail later.

The library shows all of the elements you can choose from to drop into your view. If you scroll around, you'll see there are a lot of options.

Each screen in your application is a view. This shows what your view will look like (minus any data that needs to be loaded) in the app. You can build views using code and/or by dragging and dropping controls using Interface Builder. We'll use Interface Builder for iDecide.

A GUI builder sure sounds easier. I guess it just spits out Objective-C code into my files?

No—Interface Builder creates nibs.

Nibs (which have .xib extensions) are XML documents that are loaded by the framework when the app starts up. We'll talk a lot more about this in the next chapter, but for now it's just important to understand that Interface Builder is not creating Objective-C code. It's creating an XML description of the GUI you're building, and the Cocoa Touch framework uses that to actually create the buttons and whatnot for your application at runtime. Everything we do in Interface Builder could be done in pure Objective-C code, but as you'll see, there are some things that are really just easier to lay out with a GUI builder.

...then the Cocoa Touch framework built into our app uses the description in the .xib file to create the actual Cocoa Touch objects in our view.

iDecideViewController.xib

We create the XML description using Interface Builder...

And that view is what the user sees when they run our app.

What should I do?

Views for iPhone Apps are called nibs, and have an .xib extension.

Add the button to your view

To add elements to the view, all you need to do is drag and drop the elements you want onto your view. For our app, we just need a button with a label on it.

Drag the rectangular button onto the view.

The initial size of the button will be small, so resize it to be a bit bigger. Just grab the corners of the button and pull.

Drag the label onto the button.

Edit the new label on the button to say "What should I do?" by double-clicking on the "label"and type the new text, then move the text around to center it on the button.

The iPhone Simulator lets you test your app on your Mac

The Simulator is a great tool for testing your apps quickly and for free. It doesn't come with all of the applications that a real phone does, but for the most part it behaves the same way. When you first start the simulator you see the Springboard, just like on a real iPhone, with iDecide installed (and a default icon that you can change later). Xcode then opens the app and your code is running.

There are some differences between using the Simulator and your iPhone. For starters, shaking and rotating your Mac won't accomplish anything. To approximate rotation and check landscape and portrait views, there are some commands under the Hardware menu.

there are no: Dumb Questions

Q:

Are there other things that don't work on the Simulator?

A:

The Simulator can only work with some gestures, network accessibility and core location are limited, and it doesn't have an accelerometer or camera. For more information, reference Apple's iPhone OS 3.0 Library documentation, via the Help menu in the Simulator.

The Simulator is great for getting started with your application, but at some point you have to move over to a real device. Also, be aware that the iPod Touch and the iPhone are two different devices with different capabilities. You really should test on both, which means you'll need to join one of the paid programs.

Q:

What's with this whole nibs have a xib extension thing?

A:

That's an odd artifact showing the roots of OS X. Nibs date back to the NeXTStep days, before NeXT was acquired by Apple. In OS X Leopard, Apple released a new format for nib files based on an XML Schema and changed the extension to xib. So, while the format is XML and they have a .xib extension, people still refer to them as nibs. You'll see more NeXTStep heritage in library class names too—almost everything starts with "NS", short for NeXTStep.

Q:

Why didn't anything happen when I clicked on the button in the Simulator?

A:

It's temping to expect that button to just work out of the gate, given how much XCode sets up for you. However, if you think about what we've done, there has been some XML created to load a framework and draw a button, but we didn't tell it to do anything with that button yet...

OK, so Interface Builder created XML, but we still need to write code to implement the button press, right?

UI behavior is implemented in Objective-C.

Interface Builder creates your button, but to make that button actually do something, you'll need to code what it should do.

Controls trigger events in Objective-C when things happen to them, like the button being pressed or text changing in a text field. For events like button presses, Interface Builder has to connect the view controls with code in your controller class for action methods, tagged with IBAction (for Interface Builder Action). We'll talk more about the Objective-C syntax later, but for now, you'll need to declare a method in your header (.h) file and the implementation in the .m.

This line declares a method called buttonPressed that Interface Builder will recognize as a possible callback.

The .xib file describes the button as you configured it in Interface Builder.

.xib

iDecideViewController.xib

Button

-(IBAction)
 buttonPressed:(id)
 sender;

-(IBAction)
 buttonPressed:(id)
 sender
 {

 method that the button
 calls
}

iDecideViewController.h

You provide the method implementation in the .m file. Here's where you code up what should actually happen when the button is pressed.

iDecideViewController.m

#import <UIKit/UIKit.h>
 @interface iDecideViewController :  UIViewController {
       IBOutlet UILabel *decisionText;
 }
 @property (retain, nonatomic) UILabel *decisionText;
 -(IBAction)buttonPressed:(id)sender;
 @end

We'll need to change the label text to provide Mike's answer, so we need to be able to get to the label control that the framework will build from our nib.

We'll talk more about properties later in the book.

Here's the action that will be called when the button is pressed.

iDecideViewController.h

The @synthesize tells the compiler to create the property we declared in the header file.

#import "iDecideViewController.h"
 @implementation iDecideViewController
 @synthesize decisionText;
 -(IBAction)buttonPressed:(id)sender
 {
    decisionText.text = @"Go for it!";
 }

- (void)dealloc {
    [decisionText release];
    [super dealloc];
 }

This is the implementation of the method that gets called when the button is pressed.

We'll use our reference to the label to change the text.

The dealloc method is where you can clean up your memory usage. We'll talk more about this in Chapter 3.

iDecideViewController.m

What happened?

The Objective-C code is all set to handle it when the button is pressed, but Interface Builder has no idea it needs to connect the button to that code. We can use Interface Builder to hook up our button to the buttonPressed method we just wrote. Then, when the .xib file is loaded by the framework, it will connect the button object it creates with our code.

This is the part we're missing – the link between the instantiated button and the code that needs to get called...

.xib

iDecideViewController.xib

-(IBAction)
buttonPressed:(id)
sender;

Button

-(IBAction)
 buttonPressed:(id)
 sender
 {
 method that the button
 calls
 }

iDecideViewController.h

.h

.m

iDecideViewController.m

Unless the UI components are hooked up to the code, nothing is going to happen.

We need to connect the button's "Hey, I just got pressed" event to our buttonPressed action method. That will get our method called when the user taps on the button. We then need to get a reference to the UILabel that the framework is going to create for us when the nib is loaded—that's where the IBOutlet comes in. Let's start with the outlet so we can change the UILabel text when the button is pressed.

Use Interface Builder to connect UI controls to code

Jump back into Interface Builder for iDecideViewController.xib, and let's hook up the components to our new code.

Hit this button to display the hierarchy view; it's a little easier to see what's going on with the nib.

A list of everything in your view, plus its class name.

If you don't have a two button mouse, just hit CTRL and then click.

❶ Right-click on the label you dropped on the button. This will bring up a list of events and references.

❷ Click on the circle next to New Referencing Outlet and drag it to File's Owner (this represents the class file that will load this nib—in our case, iDecideViewController). Then click on the decisionText outlet. Now when the decisionText UILabel is generated, our decisionText property will be set to a reference to the control, thanks to the IBOutlet.

Ok—I get how we can now change the label, but how does interface builder know that you pressed a button?

Interface Builder lists which events a component can trigger

We need to attach the right component event to the code. We wrote an action method earlier that we can connect the button to:

- (IBAction) buttonPressed:(id)sender;

IB = Interface Builder

This is the name of the method that will get called. The name can be anything, but the method must have one argument of type (id).

All IBAction messages take one argument: the sender of the message. This is the element that triggered the action.

Now we need to pick the event that should trigger this method. If you right-click on the button in Interface Builder, you'll see a list of events it could dispatch. We want the TouchUpInside event.

This list shows all of the events that the button can register. We'll get into the different events later in the book.

Most of these events sound like what they are.

We'll be using the "touch up inside" event.

Elements dispatch events when things happen to them

Whenever something happens to an element, for instance, a button gets tapped, the element dispatches one or more events. What we need to do is tell the button to notify us when that event gets raised. We'll be using the TouchUpInside event. If you think about how you click a button on the iPhone, the actual click inside the button isn't what matters: it's when you remove your finger (touch up) that the actual tap occurs. Connecting an event to a method is just like connecting an element to an outlet.

Connect your events to methods

Just like with outlets, you drag the connection from the button event to File's Owner and select the action that should be called.

❶ Right-click on the button you dropped on the view. This will bring up a list of events and references like it did with the label.

❷ Next click on the circle next to Touch Up Inside and drag it to File's Owner. Click on the buttonPressed action. Now when the button gets pressed, our buttonPressed method will be called.

So does it really matter whether I use an IBOutlet or an IBAction since Interface Builder can use both?

It matters a lot!

They're not the same. Use an IBOutlet when you need a reference to something in the interface (e.g., so you can change the label text). Use an IBAction when you want a control to tell your code when something happens (like the button gets pressed).

Phew. Now I know what to do!

Mike can make at least one decision.

Your app is working! All the pieces are fitting together: the *.xib file describes the interface, Interface Builder has connected it to the code, and Objective-C is making it all work together.

You're on your way to being #1 on the App Store.

How about a Twitter app?

there are no: Dumb Questions

Q:

What is that File's Owner thing?

A:

Interface Builder has an expectation of what class will be the nib's File's Owner. You can change what class Interface Builder thinks it will be, but by default a new project is set up so that the main View Controller created by Xcode is the File's Owner for the main view created by Xcode. That's why we didn't have to change anything. Since the File's Owner is set up to be our iDecideViewController, Interface Builder could look at the iDecideViewController header and see we had an IBOutlet named descriptionText and an IBAction named button pressed. When you connected the UILabel's referencing outlet to File's Owner descriptionText, Interface Builder saved the information necessary so that when the nib is loaded by the application, the references are set correctly in our iDecideViewController. The same thing happened with the TouchUpInside event, except in this case instead of hooking up a component to a reference, it hooked up a component's event to a method that should be called.

Beware—Interface Builder's expectation of the class that will load the nib does not mean that other classes can't try—it just might not work well if that class doesn't have the necessary properties and methods.

Q:

What's with the "Outlet" stuff?

A:

Interface Builder has the idea of Outlets and Actions, and we'll talk more about them in a bit. Basically an Outlet is a reference to something and an Action is a message (method) that gets sent (called) when something happens.

Q:

Why does our new text string have an @ in front of it?

A:

Cocoa Touch uses a string class named NSString for its text strings. Since it's so common, Objective-C has built in support for creating them from constants. You indicate a string constant should be an NSString by putting an @ symbol in front of it. Otherwise, it's just a normal char* like in C or C++.

Your iPhone Toolbox

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