Cocoaphony

In the last post, we discussed how to wrap simple C++ objects in Objective-C. But how about more complex objects, particularly with shared_ptr? Read more…

Last year, I presented an approach to wrapping C++. Since then, I’ve been introduced to other approaches, particularly from gf who helped me better understand opaque objects. Since I do a lot of cross-language work, I’ve had some opportunity to play with and expand this, and so I’d like to update my C++ wrapping approach.

First, to remind everyone of the problem: you have a C++ object that you want to consume in Objective-C. That’s easy in ObjC++, but if you make an ivar that references a C++ class, then the header file can only be included by ObjC++ classes. This quickly spreads .mm files throughout your project, creating all kinds of headaches. ObjC is a beautiful thing, and C++ is fine, but ObjC++ is a crazy land that should be carefully segregated from civilized code. So how do we do it?

Read more…

So say you had this code:

printf("%s", 1);
NSLog(@"%s", 1);

And you compiled with -Wformat. You might expect both of these lines to kick out a warning:

Format '%s' expects type 'char *', but argument 2 has type 'int'

You’d be particularly misled when you went and looked at the definition of NSLog():

FOUNDATION_EXPORT void NSLog(NSString *format, ...) __attribute__((format(__NSString__, 1, 2)));

Why look there, doesn’t that look like it should provide format type checking? Oh how foolish. Neither gcc nor clang can actually handle that __NSString__ specifier in a robust way. So the first line above will give a useful warning, but the second one will silently compile and later crash. Exciting, I know. You have been warned.

-Wformat-nonliteral and -Wformat-security do catch dangerous calls like NSLog(foo), so __NSString__ isn’t a complete loss, but it’s a shame we can’t get type checking here.

There’s a good discussion of this at NSLog(…) improper format specifier affects other variables?

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

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…

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. Read more…