Answering a question on Stack Overflow, asking for an explanation of the Application Delegate, how it is accessed and created.

In Cocoa, a delegate is an object that another object defers to on questions of behavior and informs about changes in its state. For instance, a UITableViewDelegate is responsible for answering questions about how the UITableView should behave when selections are made or rows are reordered. It is the object that the UITableView asks when it wants to know how high a particular row should be. In the Model-View-Controller paradigm, delegates are Controllers, and many delegates’ names end in “Controller.”

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.

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.

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.

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.

See Take 2 for an updated approach to this problem.

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.

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 by Aaron Hillegass. It is the book. I have a syllabus based on it that’s stripped down to the chapters that are useful for iPhone programmers. I’ll get that into a blog post.

When I teach this, it runs between 5 and 10 full days depending on how in-depth I cover the Mac side.

Apple finally updated the Memory Management Guide to deal with IBOutlets.

They came to the same recommendation that many of us have. Treat them exactly like other properties. Mark them as retain properties, release them in -dealloc, and overload -setView to clear them in low-memory situations. This last recommendation was one that many of us used, but was based on undocumented behaviors. Apple finally documented the behavior because there’s no other good way to do it given their internal implementation.

Unfortunately they haven’t updated the “Using View Controllers” documentation to include this stuff, and the section on how -loadView works is still a bit vague. I’ve sent them feedback on those pages.

For those of you familiar with SQL and coming to Core Data, you probably want to separate the concept of “database” into the two kinds we’re discussing here. There are relational databases, which is what you’re probably used to, and object databases, which is what Core Data provides. Core Data happens to implement its object database on top of a relational database (SQLite), but that is a opaque implementation detail.

In a relational database, the key actions are the select and the transaction. In the select, you ask the database to form itself into a collection of columns (joins are just a fancy way of doing that), filter and sort itself according to some set of rules, and then return you a linear collection of rows. In the transaction, you inform the system that you are beginning a transaction, instruct the database to perform a series of transformations, and then commit or roll-back the transaction. It’s a great model, but Core Data doesn’t look much like it.

Trying to solve this problem last night, I came across this great script to automate the process. Works great, right out of the box.

build_for_iphoneos

If you want to integrate this with an xcodebuild, you’ll still need to build a small xcodeproj file. There’s a template for this and instructions here:

Building Makefile Projects With XCode