Tag: OS X

Warning: long and geeky post follows — iPhone wanna-be developers, read on!

I’ve found it, finally, the best iPhone development book so far! Read on to see why.

Fairly recently, I decided to turn my attention to native iPhone application development, but I found the arena a little sparse when it comes to what I’d call good documentation.

For some perspective, I’m a software developer of 20+ years with background in Unix and Windows; I’m very well versed in C, C++, C#, and Java, among a good number of other higher-level languages, having produced a number of enterprise applications.

You’d think that picking up Objective-C and the Cocoa Touch frameworks would be a fairly simple task. However, the moment you step foot into the pool, you’re get a cold shock at how much you don’t know and it can feel daunting enough to want to retract back to familiar territory.

Don’t give up. It is easy.

Looking forward into the unknown presents a much more gloomy impression than when you’ve taken a few steps and looked back to see just how far you’ve come and in such a short period of time.

Here’s what’s happening: The Apple Frameworks represent a large and mature collection of some impressive code. The closest experience I’ve felt to it, and this is admittedly a horrible analogy, is Ruby on Rails.

With Rails, there’s so much going on by convention that you have to sling very little code to get impressive things to happen. This makes it hard to understand: there is no code to trace.

Same way with the Apple Foundation classes that are based on NeXTSTEP — a lot is handled for you, and often in new ways you might not have thought about because of limitations of other platforms, so that very little code is required to do something quite impressive. The problem is figuring out what that code is you’re supposed to write, and more importantly how’d you know to go about doing that in the first place. Hint: knowing the Foundation Framework is important to understanding the Cocoa Touch Framework.

This leaves one in the lurch that the sample code appears rather sparse, and the framework documentation overwhelming, with little guidance on how all the pieces fit together into a simple, cohesive whole. The problem is all too common.

My biggest gripe with many frameworks, especially Java and it’s auto-generated documentation, is that all you’re really presented with is a list of method signatures with very little discussion about what they do, purpose and limits to the input values, discussions of side effects, the importance of call order, and so forth. With other languages, you’re lucky if you can find the header file to include or the library file to link against. It’s all just expected that you somehow know this, and that doesn’t work when you’re learning a framework, though it’s fine if you just need a reference.

Apple’s online documentation is certainly comprehensive, but the reality is you’re going to be watching videos and reading tons of documentation, picking up crumbs of useful bits as you go. The cohesive moment of comprehension will come, but it will be a long and slow ride. You want something faster.

If you’re learning Objective-C at the same time, the ride is extra bumpy, because not only are there just a few language extensions sitting on top of C, but the ObjC library is actually doing some clever work that you want to know about, and this has additional implications because there’s a lot of convention going on as well. Further obscuring things is the fact that, due to historical reasons, the terminology you are most likely already familiar with doesn’t map nicely. A nice look under the hood solves this. Objective-C isn’t just some new keywords, it’s new application behavior.

What’s Wrong With Other iPhone Books At The Moment
As of early 2009, you’re going to find few iPhone books out there. Most of what exists is for the hacked version of the iPhone, and while that may even sound useful, the tearing apart of the SDK is rough and incomplete, not to mention the implementation to call is painful. This just isn’t applicable to the real world constraints of native mode development.

Think you can get by with a slightly out of date copy of a Cocoa book? Think again. The UIKit framework is just different enough that your approach needs to be slightly different. Tight, efficient, resource management becomes very important.

Also, unless you already know and understand Interface Builder, it can be a hard time following along when your book doesn’t match your software version. Apple keeps modifying Interface Builder, making it better, but the changes can come across as so dramatic, interface-wise, that to the new comer it looks like a totally different application each revision. Once you “get it” the sweeping changes are cognitively transparent. The iPhone SDK includes, you guessed it, a new XCode and Interface Builder.

What few modern iPhone books there are out there jump straight into a technical feast of SDK details, leaving the reader with a learning curve that’s as vertical as a brick wall.

What’s needed is a book that introduces only what you need to know, when you need to know it, explaining tips and tricks along the way, delving into the philosophies of why things are the way they are, what the developers were thinking, how the frameworks are structured, what the conventions are, and when those conventions aren’t followed. And, instead of showing you the end solution all refactored into a neat package, take the long way, when needed, to introduce you to what’s going on and then evolve into the optimal solution.

I’ve Found Such A Book!
The book, by Apress, is called Beginning iPhone Development – Exploring the iPhone SDK by Dave Mark and Jeff LaMarche. This book is about the fundamental concepts you need to understand in order to make the frameworks do their magic.

Its tutorials are very well constructed, easy to follow, and are specifically designed to teach the framework in such a way as you understand what’s going on and learn to fish for yourself.

This is in stark contrast to substandard books that merely cover a framework’s capabilities with cut’n’paste examples that have little bearing to real applications. This alone gives is five out of five stars by my standards.

My only complaint is a minor nit that there are a small handful of typos, and unfortunately, they happen in the code examples. However, they’re glaring, and you won’t get tripped up by them. (For example, on page 85, the tutorial is about UIImage. And, UIImage appears four times in a six line sample. The first one, however, says “jmUIImage” and the indentation is off. It looks like a macro expansion, a note, or the mangled initials of one of the authors. The code won’t compile with it, and it’s obvious from context what it should be.) To me, this is forgivable. Especially since it’s rare.

I want to show you something.

I have a habit of tagging my books when I find an exceptional piece of information that I haven’t found elsewhere. I give a book high marks if it earns somewhere between three to seven tags, as the majority of my collection never gets any tags. Tagging, for me, is not note taking — it’s rare event.

I think the picture speaks for itself.

For Example…
So, at this point, I present for my own edification and future reference, some of that tagged content. Who knows, maybe something you see here might just get you traction on the learning curve.

– In Objective-C, colons are a legal character of the method identifier, they are not syntactic sugar.
– Even though a number of macros translate to nothing, void, zero, or null under the hood, their presence provides important hinting for data types and method calls.
– The NIB’s File’s Owner is a place holder for the class that loaded the NIB file.
– The NIB’s First Responder is the object the user is currently interacting with.
– The application icon is a 57×57 .png file, see Info.plist’s Icon File.
– The iPhone specially optimizes .png files so this is the best format.
– Reset the iPhone Simulator by deleting its directory from ~/Library/Application Support
– You want to use @property (retain, nonatomic) as often as possible.
– Interface Builder uses your defined accessors to properties, which use retain; that means you do need to deallocate Interface Builder objects, even if you didn’t instantiate them.
– There are four control states on a control, often you want UIControlStateNormal.
– Learn to use retain/release, there is no garbage collecting on the iPhone.
– It’s better to init/release than using factory methods; factories use autorelease pools, and while this will work, it often keeps resources around longer than you intend — avoid autorelease pools.
– Hog too many resources, whether CPU or memory, and the phone will reboot.
– Everything from UIApplication on down will fire messages to Delegate objects at certain well-defined times, you need to learn what these times are and what messages are sent; it’s not just subclass avoidance.
– You can Option-Click on a class or interface name in XCode and go right to the documentation.
– You can press ESC to cause auto complete to happen immediately.
– Command-equal_sign will size a control to fit.
– When you’ve got a lot of control hierarchies going on, use the View Mode button to see them as a list.
– Scaling an image takes computational overhead, avoid if you can.
– Set the Alpha slider to 1.0 in order to optimize the drawing sequence, it skips looking at the underlying background and factoring it in — it applies to the image drawn.
– Also set the Opaque checkbox in order to optimize the drawing sequence, it skips drawing the underlying background for the parts where the image is transparent.
– The Tag control allows you to assign a numerical identifier to controls to locate them later.
– You need to handle the Did End on Exit event in order to make the keyboard go away.
– You may also need a huge, invisible, custom button as well to make the keyboard go away.
– In XCode, use Option-Command-up_arrow to toggle between a header and its source file.
– In the Interface Builder, move the cursor over a view and hold down Option to see how many pixels there are between the item and its superview.
– Option-dragging a control in Interface Builder makes a copy.
– Nifty buttons are actually stretchable images, and Apple has buried a ton of them free for your use in the UICatalog sample code on their site.
– There are three different ways to handle layouts when rotation happens: autosize, reposition, and view swapping.
– The rotation callback passes you the orientation the phone came from, you need to use other means to get the current orientation.
– If you want to use Core Graphics, for things like view transitions, you need to link the framework into your application.
– Some frameworks, like Core Graphics, have one version for the iPhone hardware and one version for the iPhone Simulator.
– If you use the correct parameters, XCode’s build process can play games with the path and always target the right framework (use Relative to Current SDK, and do not select Copy items).
– Right-click the Resources folder and use Add / Existing Frameworks… to do this process in a safe way.
– If a view isn’t shown, it’s superview is nil.

…there’s plenty more, but you get the idea. The book is jammed with all kinds of useful things to someone who is new to iPhone development. This presentation of material makes the learning curve very approachable.

And, once over that hurdle, all those other books that I said were problematic suddenly make a whole lot of sense.

This book is the best first step I’ve seen in the journey to writing iPhone applications. Period.

Walt gives “Beginning iPhone Development” two thumbs up, five stars our of five starts, and a head nod of appreciation to the authors. Well done, guys. Well done.