Beginning iPhone Development 216
Cory Foy writes "When my wife got a Touch several months back, the first thing I wanted to do was build some applications for it. Who wouldn't want to play with a device that has accelerometers, position sensors and multi-touch gestures? But being new to the Mac world, I needed something to help guide me along. Beginning iPhone Development aims to be that guide. But does it live up to the challenge of teaching a newbie Mac and iPhone developer?" Read below for the rest of Cory's review.
The first thing you'll need to do is head over to the Apple Developers Site and register for an account. You can then download the iPhone API. Note that while the API download and simulator are free — deploying to a real iPhone or iTouch is not, even if it is your own. To do that you have to apply to the iPhone Developer Program which is $99. For the book, you'll be fine with just the simulator with the exception of any accelerometer application, since the simulator doesn't have that feature.| Beginning iPhone Development: Exploring the iPhone SDK | |
| author | Dave Mark, Jeff LaMarche |
| pages | 536 |
| publisher | Apress |
| rating | Five $1000 Rubies |
| reviewer | Cory Foy |
| ISBN | 978-1-4302-1626-1 |
| summary | A great introduction to the iPhone SDK and getting into iPhone Development |
With that out of the way, I was quite impressed with the book. Although I've done quite a bit of development in the past, I haven't worked with Objective-C before, and was a little concerned if I would be in over my head. If you are in that position, don't fear — the authors do a great job of walking you through, and you'll find yourself working with it in no time.
The first chapters introduce you to the basics of the iPhone and development, starting with the canonical "Hello, World" application. The book walks you through how to get and install Xcode and the iPhone API. It then introduces you to Interface Builder, the partner-in-crime to Xcode. Even in the first chapter, the authors show their attention to detail, explaining common issues you might run into (like trying to Build and Run while your iPhone or iTouch is plugged in to your Mac).
Chapter 3 introduces the Model-View-Controller paradigm, a pattern that is probably one of the most misunderstood patterns in UI development. They give you enough information to be familiar with the terms you'll be using, and they very much mean it when they tell you not to worry if you aren't understanding something — they always loop back around to make sure you understand it.
Chapter 4 was a long chapter for me, but introduces some important concepts around user interaction and controls. By the end, you have an interface which has a variety of controls which interact with each other. As with the other chapters, the authors introduce tips and tricks to make things easier (for example, Option->Cmd->Up Arrow to switch from the header to implementation file in Xcode).
Chapter 5 covers autorotation and basic animations, including linking in the Core Graphics Framework. I especially like how the authors gave three different ways of making your app auto-rotation aware, describing the benefits and drawbacks of each. Chapter 6 follows this up by introducing multi-view interfaces, something very necessary as you get into more complex iPhone development.
Chapters 7-9 describe various methods to presenting information to users, including toolbars, table views, hierarchical navigation and hierarchical lists. However, it isn't all drag-n-drop, the authors get into some good (and sometimes deep) conversations about what you are doing. For example, in Chapter 8, they talk about issues with NSDictionary and how to create deep mutable copies.
Chapters 10-13 are the last of the "fundamentals" — application settings, basic data management, custom drawing using Quartz and Open GL, and taking inputs (including gestures and multi-touch). As someone who spends most of his time as far away from graphics libraries as possible, I was quite impressed with the basics that were introduced and what someone like me could get up and running.
Finally we get into the fun. Chapter 14 introduces Core Location, allowing to figure out where in the world you are. The book goes through a discussion about the various ways to get location information, and drawbacks of each. (Helpful tip: no matter which method, if you are polling every second, you'll drain the battery pretty quickly). For the simulator-only users, this is when things start to become tricky. Chapter 14 does work, though you aren't prompted for access to Core Location.
Chapter 15, however, is useless without an actual phone, even though it's perhaps the most fun. In this chapter, the book goes through the accelerometer and all the interesting things you can do with it. There's even a small discussion on the physics (but just enough!). Both apps you create (Shake and Break and the Marble game) are quite fun for someone just starting out with all of this. It's a shame Apple couldn't figure out a way yet to include the accelerometer in the simulator.
Chapter 16 covers using the iPhone camera and Photo Library. It's short, but it shows the power of the simple interfaces Apple provides. In just 9 pages you'll be capturing images right from the iPhone.
The final two chapters I thought were quite fitting — Localization and Follow-Ups. In the localization chapter, the book covers extracting strings out to resource files and using locale to read them in. Having a day job which ships our software in 12 different languages, I know first-hand how difficult localization can be to get right, so I was glad to see this chapter. The final chapter is just a wrap-up of resources you can reach out to for help and information.
All in all I was very surprised and pleased with the book. I've had the fortune of reading many technical books, and few do a great job of walking someone through the basics without making them feel like a dolt. It felt like every time I was stuck or unsure there was a tip, hint or paragraph which explained what was going on.
The main drawback to me is the fee to deploy apps to your own phone. This wasn't something I ran into doing either J2ME or Windows Mobile apps in the past, and it is a shame that to even work on your own phone you have to pay a fee. However, since the fee does give you the ability to submit apps to the App Store, then I guess it's a consolation. I'd rather Apple lock deployments to one iPhone (or iTouch) for the truly casual people who just want to do interesting things on their own phone.
In summary, I give this book five $1000 Rubys for making a clean, concise, easy-to-read and follow introduction to iPhone development. Great job guys!
You can purchase Beginning iPhone Development: Exploring the iPhone SDK from amazon.com. Slashdot welcomes readers' book reviews — to see your own review here, read the book review guidelines, then visit the submission page.
Objective-C, not too bad... (Score:5, Informative)
stop stop stop (Score:1, Informative)
The actual programming is easy (Score:1, Informative)
Programming the device is rather simple, going through all the Apple hoops just to put the app on your device or deploy it is far
more difficult. In fact if you start the developer sign up process and your application programming on the same day it is highly likely
that your app will be ready way before Apple gives you the go ahead to pay them $100 for the opportunity to program for it.
Re:Objective-C, not too bad... (Score:1, Informative)
I would recommend Cocoa Programming for Mac OS X for a good introduction to Cocoa and Objective-C. No-referral Amazon link [amazon.com].
Code-Signing (Score:3, Informative)
> Note that while the API download and simulator are free â" deploying to a real iPhone or iTouch is not, even if it is your own.
Not necessarily true. There are ways to circument [246tnt.com] the code-signing.
First Step (Score:5, Informative)
Accelerometer (Score:5, Informative)
It's possible to link up an iPhone's accelerometer to the simulator, and it's also possible to link up the accelerometer in a MacBook to the simulator as well. More details here [blogspot.com]. Honestly, though, it's probably easier to just jailbreak your iPhone.
Re:The C Programming Disease (Score:5, Informative)
1. The language discussed is Objective C, not C.
2. If no one programs in languages like C, you can say goodbye to modern computing. There's no way you're going to program an operating system in Python.
Re:First Step (Score:1, Informative)
Owning a mac is the first part, then you need the phone, apply to pay apple $100 and if they say yes you can pay then wait some more then
you can finally get something running on your device. Deploying it to the app store will take you another month in frustration waiting for
approval.
Re:A hundred bucks? (Score:3, Informative)
If you have to pay a corporation a single dollar for the permission to program, you are doing it wrong. How does Apple get a free pass for this kind of shit?
Note that while the API download and simulator are free â" deploying to a real iPhone or iTouch is not, even if it is your own. To do that you have to apply to the iPhone Developer Program which is $99.
You don't have to pay a single cent to program. You have to register... But the SDK is completely free. Anyone can download it.
What you do have to pay for is distributing your software to live hardware. Apple uses code signing much like you see on consoles like the Xbox and PlayStation. If you aren't worried about distributing to other people you can always just jailbreak your device... Then you don't even have to pay for the code signing.
iPhone SDK training (Score:3, Informative)
Picked this up three days ago. (Score:2, Informative)
Re:why?? (Score:3, Informative)
I'm wondering if this is just a few ACs trolling the hell out of the place.
Re:The actual programming is easy (Score:2, Informative)
Re:Interface Builder (Score:2, Informative)
Last time I used XCode/Interface builder, a method added in XCode would show up in IB as soon as you saved the .h file that declared it.
Fairly bizarre (Score:5, Informative)
Interface Builder is fairly bizarre, but it starts to make sense after a while. It does. Really.
My primary reference for iPhone development has been Erica Sadun's [ericasadun.com] book, but I may pick this one up too.
BTW: people may bitch about code signing, but Apple gave me my signature when I asked for it. This is minor compared with what was necessary when my employers wanted to do Brew [qualcomm.com] development. I considered going the jailbreak route, but ended up not doing so.
...laura
Re:The C Programming Disease (Score:4, Informative)
Personally I find Objective C really rather neat. Of course it undoubtably helps that I grew up with C and can hack it upside down and backwards. I never really used C++ to anything like the same degree (having moved on to other things) and so when I started playing around with the iPhone recently this was my first taste of Objective C.
It's syntax really is weird I agree, but once you get past that - and it's no worse than many other languages - it's just hunky dory. Certainly the freedom of not having C++'s bondage style language features and ridiculous complexity really is rather refreshing. And no gabage-collection - well if you're just coding something the size of an iPhone app and you can't handle your own garbage then really you should go stick to visual basic in a nice safe environment.
Re:The C Programming Disease (Score:4, Informative)
It does, but I think the OP point was that "nil" effectively implements all methods and returns 0, nil, or 0XDEADBEEF1374, like a bottom class without the semantic consistency of languages with true bottom types.
Objective-C: dynamic language with access to C (Score:4, Informative)
There are many resources available for iPhone/Cocoa programmers. The earliest versions of Cocoa shipped commercially in 1988, and the most used features and patterns haven't changed much. Here is a good place to start: http://www.cocoadev.com/index.pl?CocoaPrerequisites [cocoadev.com]
Why does Objective-C use BOOl and YES,NO instead of bool and true/false? One reason is that Objective-C predates the addition of the bool type to standard C by 11 years.
If you don't like dynamic languages, you won't like Objective-C. Bruce Eckel makes an interesting argument for dynamic languages at http://www.mindview.net/WebLog/log-0025 [mindview.net].
I think the ability to seamlessly use and intermix the world of C and C++ software with Objective-C outweighs and criticism that Objective-C includes C.
You must keep an open mind - There are an infinite number of different ways to solve every programming problem. Many programming languages and reusable software libraries use different approaches to solve common problems. There is a good chance that Objective-C and Cocoa use a substantially different approach from other languages and frameworks you may have used. That doesn't make either approach better or worse automatically. Every commercial software development technology has advantages in at least some cases or the technology would not exist. Cocoa is renowned for enabling very high programmer productivity without constraining the set of problems that can be solved, but programmer's opinions will always vary and software development environments are subject to aesthetic judgments irrespective of abstract technical merit. Many programmers are enthralled by Objective-C and Cocoa. You might be enthralled too. Or, you may never like Objective-C and Cocoa from an aesthetic standpoint, and there isn't really anything anyone can do to change that without affecting the aesthetics for others.
Re:Interface Builder (Score:4, Informative)
Dragging and dropping to connect button actions to methods between two pieces of software (XCode and Interface Builder) that don't actively sync with one another
Your experience is a bit outdated. Starting in Leopard, they do sync actively.
Re:Objective-C, not too bad... (Score:2, Informative)
Re:The C Programming Disease (Score:3, Informative)
C++ only does that if you are trying to pass classes by value, which is almost always a bad idea. I agree it's unintuitive but then a lot of C++ is, you don't lose anything if you simply never pass subclasses by value. If you use references the whole problem disappears.
iPhone dev works on our G4 (Score:2, Informative)
The SDK *says* it requires an Intel Mac, but my wife found instructions on the net and just last night we compiled and ran from XCode on her G4 to her iPhone.
She had been excited that we had an excuse to upgrade from her G4, but it turns out iPhone development doesn't require us to upgrade.