Prashant P. wrote me recently asking some questions that I thought I’d answer here. First, can iPhone development be full time job, and second, will it help him get into a “mainstream job” in Java, .NET, etc. As he notes, most of the iPhone development he’s seen has been a part-time rather than full-time job; a side-line rather than a career. Read more…
The long-lasting power of Snow Leopard from The Yankee Group.
Ever since I first saw GCD at WWDC, I’ve been amazed by it and eager to give it a real spin. But since the vast majority of my work is in low-level libraries that run on both Mac and iPhone, GCD is closed to me (as is garbage collection; more on that later). I’ve said that multi-core would come to mobile devices because everything will come to mobile devices (laptops are the new desktops, and mobile is the new laptop). And for the iPhone, multi-core also makes a lot of sense by allowing Apple to dedicate a core to its own use during important functions like phone calls. But Carl Howe makes an even more compelling argument for mobile multi-core: better battery life.
With multi-core comes another strong possibility: garbage collection. The availability of a second core makes this more likely on iPhone. Yes, memory is tighter, but ever-growing. And GC will likely do a better job of reclaiming memory faster than much of the leaky programs I see from novice programmers. But to do it well, I think a second core is a real must. I’ve grown good at memory management over the years, and it’s hard for me to write GC Cocoa because it “feels wrong.” But I think I could get used to it…. And it would help alleviate the biggest class of coding error I see in Cocoa programs.
Of course, the clang static analyzer will probably help get rid of 90% of those errors anyway, so maybe the need for GC just went way down…. Have I mentioned recently how incredible clang really is? I desperately long for them to finish bringing it to Obj-C++ so I can use it.
I work on a lot of projects that share significant code between iPhone and Mac versions. This is the beauty of Cocoa. While working on these projects, I’ve bumped into this idiom many times:
#ifdef TARGET_OS_IPHONE
#import <uikit /UIKit.h>
#else
#import <cocoa /Cocoa.h>
#endif
This is almost never correct, and almost always means that someone imported Cocoa.h into a model class. Model classes should never rely on UIKit or Cocoa. They should just import Foundation.h.
There is one interesting exception that we’ve run into: NSImage versus UIImage. These are really model classes, but they’re part of AppKit and UIKit. They have very similar interfaces, so in most code you should be able to interchange them and keep everything portable. What to do? Read more…
Summary: Beginning iPhone Development: Exploring the iPhone SDK
Beginning iPhone Development is a pretty good book. It assumes you already have some background in ObjC, which makes it harder for people without any Cocoa experience (the most common place to get ObjC experience). A short ObjC intro would have been useful. Like other books in this space, it doesn’t provide much background in basic Foundation features like Collections and Notifications, nor key patterns like delegation, memory management and naming. As students move beyond trivial projects, they will likely start to have trouble unless they shore up these skills elsewhere. Read more…
Summary: If you want a real understanding of Cocoa and Cocoa Touch, this book is too recipe-based to give you that. If you really want recipes, consider Apple’s Sample Code.
I haven’t been thrilled with the first crop of iPhone development books that hit the market. This shouldn’t be surprising. It’s a new platform and, as with the first AppStore apps, the pressure to be first to market fights the authors’ desire to provide the best possible product.
I was specifically asked about iPhone Developer’s Cookbook: Building Applications with the iPhone SDK by Erica Sadun. My biggest concern is that it’s a cookbook based on “recipes” to do this or that. This is often exactly the problem with how people learn Mac and iPhone development. They think that it’s just Java or C++ with a different syntax and if they learn where the brackets go, then they’ll be a Cocoa developer. Read more…
Now and then I teach Mac and iPhone courses, and several people have asked me to detail my syllabus, and provide some other pointers on how to get started. I’ve taught this course in various forms, running from 3 to 10 days long. A week and a half is good; it gives you a weekend to absorb a little bit.
I tend to teach Mac and iPhone together, though I been focusing on iPhone because that’s what we’ve needed most. I still favor Aaron Hillegass’s Cocoa Programming for Mac OS X
So without further ado, the syllabus and resources. I can’t promise that reading through this will be as effective as watching me pace around for a week telling you about it, but it perhaps it will give a nice kick-start. Read more…
I’ll talk more about it later, but the absolute best way to learn iPhone is to learn Mac first. That’s how I teach my classes. The available Mac educational resources are just much better, at least today.
The absolute gold standard for learning Cocoa on Mac is Cocoa Programming for Mac OS X
When I teach this, it runs between 5 and 10 full days depending on how in-depth I cover the Mac side. Read more…
