Summary: Beginning iPhone Development: Exploring the iPhone SDK
does not provide the student a strong foundation in Cocoa, but does teach key iPhone-UI topics well. For readers with a prior background in Cocoa, it is likely a good book for transitioning to iPhone, particularly iPhone UI.
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…
Say you want to talk to another app through Applescript. With 10.5, you can much more easily get there from Cocoa without complex forays into CoreServices, Carbon and AppleEvents. The docs on how to do it are a little thin at times (as all Applescript docs are), so let’s walk through it. The relevant docs you’ll want to read are these:
Learning Applescript
Scripting Bridge Framework Reference
Scripting Bridge Sample Code
And most importantly (and most hidden):
SBSystemPref’s Magical README
And now for a step-by-step example. We’re going to send some mail with an attachment through Mail.app.
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
as a textbook. I’m open to suggestions for excellent iPhone-specific books for beginners, but when I was developing this course last August, I didn’t find a lot on the market I was impressed with. Even the Big Nerd Ranch iPhone class I found disappointing, which is one of the reasons I had to write my own class for our new developers. The Big Nerd Ranch’s Cocoa Bootcamp still cannot be beat if you’re looking to learn Mac development and have several grand handy.
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…
When faced with mixing C++ and ObjC code, there are two main approaches. One is to just work in Objective-C++ through the entire project. I don’t like this approach. I find the mixing of ObjC and C++ classes very confusing, since they cannot be used interchangeably and require completely different memory management. The mix of class hierarchies and naming conventions lead to a lot of confusion when we introduce people to code that does this kind of mixing.
My opinion is that ObjC and C++ have very different patterns, so it is important to pick one to be in charge and wrap the other. So if you basically have an C++ program than needs a little ObjC to talk to the UI, then wrap the ObjC in C++ objects. If you basically have an ObjC program that needs a C++ middleware, then wrap the C++ objects. Read more…
