Slashdot Mirror


Beginning iPhone Development

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. 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 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.

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.

13 of 216 comments (clear)

  1. Objective-C, not too bad... by jDeepbeep · · Score: 5, Informative

    If you have a background in both C/C++, and in OOP. Otherwise, I'd suggest getting a little background in those first. I think it's slightly misleading to imply that this book is the best hand-holder in this regards.

    --
    Reply to That ||
  2. First Step by slashkitty · · Score: 5, Informative

    I thought the first step was getting a Mac, then you can get the sdk. It's actually a pretty high barrier to entry for a developer.

    --
    -- these are only opinions and they might not be mine.
    1. Re:First Step by shmlco · · Score: 4, Insightful

      As opposed to developing for Windows Mobile, where one can create applications just by thinking them into existence? Oh wait, I have to buy a PC to do WM development! Bummer.

      --
      Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
    2. Re:First Step by Belial6 · · Score: 5, Insightful

      Given that there is a greater than 90% chance that a person wanting to jump into Windows Mobile development will already have a machine capable of doing the development, and a less than 10% chance that a person wanting to jump into iPhone development will already have a Mac capable of doing the development means that the OP has a very valid point.

    3. Re:First Step by cabjf · · Score: 4, Insightful

      What an apt analogy. How many people buying cars buy them to change anything (or even care what kind of oil is put in them).

      I think the big disconnect between the average open source, linux geek and the general public is that the general public likes treating computers and computer based products as appliances that just work.

      The whole walled garden approach has worked out pretty well for Apple with the iPod and iPhone. If that doesn't fit your needs though, that's fine. Just don't assume that it isn't the best choice for anyone else because of your needs or opinions.

      The difference between what Apple is doing with the iPhone and what the cell companies are doing is that Apple is attempting to provide a user focused UI. Whereas the cell companies are trying to figure out how to charge for as much as possible for anything on their network.

  3. Accelerometer by Bogtha · · Score: 4, Informative

    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.

    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. Honestly, though, it's probably easier to just jailbreak your iPhone.

    --
    Bogtha Bogtha Bogtha
  4. Interface Builder by fragbait · · Score: 5, Interesting

    The biggest problem I've had so far is Interface Builder. It isn't the most intuitive piece of software. 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, at least not as I've yet to find.

    I already had the C/C++ and GUI/fat client app building experience from 10 years back.

    +fragbait

  5. Re:The C Programming Disease by SwedishPenguin · · Score: 4, 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.

  6. iTouch by linuxci · · Score: 4, Insightful

    iTouch is the name of a UK company that provides mobile content. They were around a long time before the iPod touch but lost top spot in Google to Apple despite the fact they don't make a product of that name.

  7. Re:stop stop stop by Anpheus · · Score: 4, Funny

    Dear Apple Legal,

    We don't care.

    Signed,
    Your Consumers

  8. Re:The C Programming Disease by IamTheRealMike · · Score: 4, Interesting

    Unfortunately Objective-C is designed such that it combines the worst parts of C with the worst parts of dynamic languages, so your point doesn't really hold. Method dispatch is all dynamic, and in the best case seems to be twice as slow as a C++ vcall. But it only gets that speed by building runtime dispatch caches, ie, trading off memory against CPU. On phones memory is also very limited.

    It really is an amazingly stupid language. I am not surprised no-one except Apple uses it. This is the language that thinks it's a good idea to redefine boolean to be YES and NO.

    That sort of weird syntax quirk is not a big deal though, it's just a time-waster. The real problems start when you realize that calling a method on a NULL object doesn't crash. Instead it returns zero, another NULL or if the method returns a struct, garbage. So what would be a clean kill with a nice stack trace in any sane language in Objective-C turns into silent propagation through your code of NULL pointers and zeros, until you save state and blow away the users data.

    On the iPhone there's no garbage collection. Yes it's back to the days of ref counting, whoopie-doo. The best they have to offer is a kludge called an "auto release pool", which basically just scopes lifetime to the current GUI event. Pretty useless for anything that lasts longer than a button push. It also massively complicates exception handling due to the rules around how auto-release pools stack (yes really).

    Then there's the lack of features. No namespaces. No abstract classes. No stack allocation thus no RAII. No operator overloading. No generics, really no type safety at all (calling a non-existant method is a warning not an error). Your code is trivial to decompile. And of course the only really supported development environment is a Mac.

    Java might be a stupid language to use on a phone as well, but seriously, I'll take that kind of stupid any day over Objective-C.

  9. Re:Apple Legal's Reply by Capmaster · · Score: 5, Funny

    iTouche.

  10. Fairly bizarre by spaceyhackerlady · · Score: 4, 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 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 development. I considered going the jailbreak route, but ended up not doing so.

    ...laura