Marc Charbonneau’s Blog

From Domain of the Bored:

/^retain$|^(alloc|new)|[cC]opy/

ObjectAlloc can be a useful tool for detecting memory leaks, but a simple search is just as good (and probably easier) for catching the really stupid memory management mistakes. (via CocoaBlogs)

Every so often on forums or mailing lists I see someone ask the question, “how do I learn Cocoa?” There’s no short answer, and rather than try to type out a reply each time the subject is brought up, I’m going to expand on it a bit here. Even though there’s no right path for everyone, I can give some tips and advice from my own experience. Read on if you feel overwhelmed, or just don’t know where to begin.

Do the Currency Converter Tutorial

Before you write a single line of code you need to get familiar with the basic tools for programming in OSX. If you’ve never set foot in Xcode or Interface Builder, Apple’s Currency Converter tutorial is just the thing you need. It will also introduce you to those [ ] braces that seem so weird at first if you’re coming from a different language.

Learn about Memory Management

Whether you’ve dealt with memory management in other languages or not, Objective-C’s retain release pattern probably isn’t going to be familiar. It’s not something to worry about though, memory management in Objective-C is easy to learn, and works well in practice. Most tutorials are going to be roughly the same, but you can go here or here for starters.

Know your Resources

Part of programming any language is knowing where to go to get help and information. In addition to the built-in API documentation there are some great community resources out there, and I’d suggest visiting them each time you sit down to code, if not daily. A few that have been indispensable to me are Apple Developer Connection, the CocoaDev Wiki, and the Cocoabuilder Mailing List Archive.

It’s also a great idea to become active in the Cocoa developer community. In addition to providing interesting daily reading, you’re bound to pick up useful little tricks and hints that aren’t publicized elsewhere. Apple’s Cocoa-dev Mailing List, and OmniGroup’s MacOSX-Dev Mailing List are both active centers for discussion. Blogs, from both small and large development companies, are also a good source of information (although I assume if you’re reading this, you already know that). Take a look around Cocoa Blogs for starters.

If this is your first introduction to programming, you might want to read through CocoaLab’s Become an Xcoder e-book, which covers the basics using the OSX environment. Also, Cocoa Dev Central’s Tutorials are extremely helpful and well-written, for beginners and experienced programmers both.

Forget about Bindings

Maybe you’ve heard about these neat new technologies like Bindings and Core Data, and you’re thinking you don’t have to worry about things like data source methods because they’re the “old fashioned” way. Well, forget it. Bindings saves you a lot of work, but it’s no replacement for understanding how things work at a lower level. In fact, once you start writing a real world application using bindings, you’ll almost always need to use a trick or two to get them working, and that requires an intimate knowledge of key value coding and object handling. Learn the basics first, and save bindings and Core Data until they’re really needed.

Buy Hillegass’ Book

Cocoa Programming for Mac OSX is one of the best Cocoa books you can buy. Even though most programmers recommend it as the first step in learning Cocoa, I’m leaving it towards the end here. It’s not because Hillegass doesn’t teach you the basics of Cocoa programming, but because the majority of the book focuses on more advanced topics such as writing a subclass of NSView, or working with the responder chain. If you already know the fundamentals behind Cocoa and are enthusiastic about using those skills to write a real application, you’re going to get a lot more out of this book than using it as your first and only resource.

Explore the Frameworks

Believe it or not, Cocoa programming doesn’t just involve Cocoa. There is a lot of functionality hidden away /System/Library/Frameworks that isn’t included in a new Cocoa project by default. You can find everything from CD burning to working with Open GL, and they can do a lot of the heavy lifting for you. Best of all, there are no restrictive licensing issues or huge price tags involved.

Write your own Dream App

You can read as many tutorials and books as you want, but there’s simply no substitute for writing code. It doesn’t matter if your idea sucks, the code you write is terrible, or if the end result doesn’t always work correctly (assuming you finish it at all). As long as you’re working on something, you’re going to end up running into new challenges, gaining experience and learning new concepts. And in my experience, that’s simply the best way to improve your skill set, no matter what language you’re working in.

I’ve been writing code in TextMate the past two days, trying to see if it could replace Xcode as my primary editor for Objective-C. I’ve always heard good things about TextMate, and since it’s been getting a lot of publicity lately I decided to give it a shot. I wasn’t expecting too much from it; I don’t have any real complaints about Xcode’s editor, and I figured trying to separate the editor from Xcode would introduce a lot of extra work whenever I want to start a build or start a debugging session.

Despite this, I haven’t had too many problems. There’s no getting around using Xcode, but TextMate does do a decent job of replacing the just the editor portion. You can manage the two in different ways; I prefer to use TextMate’s tabbed project mode for all the source files in the project, although you can also set TextMate as Xcode’s external editor, which opens a new editor each time you click a file in Xcode’s project window. For the actual build process you can save everything and switch over to Xcode’s build window, or use the tools from TextMate’s Xcode bundle. I find myself doing a little of both, depending on the situation.

I expect to go back to Xcode’s editor sooner or later. There are just too many small things I miss when I’m using TextMate, and although it’s a good source code editor, it doesn’t really have any one big draw to keep me using it (especially with Xcode 3.0 on the way). There’s no reason not to give it a try though; it’s probably the best alternative out there if you don’t want to use the built in editor.

A few weeks ago I read a blog post by Daniel Jalkut on how to commit editing in an NSTextField. The basic idea is when you want to end editing (or just validate the current value), you call [window makeFirstResponder:nil]. This validates the text field’s value, commits the changes, and resigns the text field as the first responder.

I’ve known this for a while, but what I didn’t know was how to restore the first responder afterwards. Although you can get the current first responder by calling [window firstResponder], trying to make this object first responder afterwards does not seem to do anything. What Daniel realized was that this object is not the NSTextField we’re dealing with, but the window’s field editor. You can get a reference to the actual text field you want through the field editor’s delegate.

I rewrote this slightly for my own use, and packaged it up into an NSWindow category. See Daniel’s post for a code snippet with a few more comments.

@implementation NSWindow (NSWindowAdditions)

- (bool)endEditing;
{
	bool success;
	id responder = [self firstResponder];

	// If we're dealing with the field editor, the real first responder is
	// its delegate.

	if ( (responder != nil) && [responder isKindOfClass:[NSTextView class]] && [(NSTextView*)responder isFieldEditor] )
		responder = ( [[responder delegate] isKindOfClass:[NSResponder class]] ) ? [responder delegate] : nil;

	success = [self makeFirstResponder:nil];

	// Return first responder status.

	if ( success && responder != nil )
		[self makeFirstResponder:responder];

	return success;
}

- (void)forceEndEditing;
{
	[self endEditingFor:nil];
}

@end

Again, thanks to Daniel Jalkut for this.

Scott Stevenson, a well known member of the Cocoa development community, unveiled Cocoa Blogs today. The site is a round-up of some of the best OSX development blogs on the web, highlighting some of the more useful tutorials and posts. I’m looking forward to adding it to my daily reading.

A new installment of the Leopard Technology Series for Developers was posted today, showcasing Xcode and the rest of the developer tools. Xcode seems to have taken a few hints from Visual Studio for its next release, and the improvements to the code editor and debugger look nice. Perhaps more importantly, speed and code completion are improved (at least they claim) as well. I’ve heard a few complaints in the past about Xcode’s speed from developers working on large projects.

I saw this in Apple’s Cocoa-dev mailing list recently and thought it was clever. It’s a hack, and I don’t know of any situation off the top of my head where I’d use it, but if you need an instance variable in one of your categories ((For non-Cocoa programmers, a category is a powerful Objective-C tool that allows you to add new methods to an existing class. Although you can access existing instance variables you can’t add new ones, which is what this work-around accomplishes.)) I can’t see why it wouldn’t work.

static NSDictionary *ivarHolder = nil;

@implementation NSSomeClass (Additions)

-(NSString *)magicalValue
{
    if ( ivarHolder == nil )
        ivarHolder = [[NSDictionary alloc] init];

    NSDictionary *vars = [ivarHolder objectForKey:[NSNumber numberWithInt:self]];
    return [vars objectForKey:@"magicalValue"]
}

@end

Thanks to Jonathan del Strother on the Cocoa-dev list for sharing this.

A new technology article from Apple Developer Connection today, explaining what developers can expect to see in Leopard:

Leopard is the sixth major version of Mac OS X and it will be the most advanced and powerful version yet. For users, it is full of new features and elegant user experience improvements that will make it a joy to use. For developers, things get even better. Leopard contains a cornucopia of cutting-edge new frameworks, streamlined developer tools, new application technologies, and strong system-level foundations. No matter what kind of developer you are, there’s something new in the system that will feel tailor made just for you.

My first thoughts are that the development tools look great. Since I haven’t bought an ADC Premier account I can only look at the screenshots, but I’m really impressed by what I can see. Between Xcode 3.0, Interface Builder and the new Xray profiling tool, it seems like Apple really spent a lot of effort improving and cleaning up some of the more outdated parts of the development tools. I know when I finally get Leopard on my system, playing around with Xcode is one of the first things I’m going to do.

Objective-C 2.0 and Core Animation I’m not terribly excited about. The last two big additions to Cocoa, Bindings and Core Data, had tangible benefits that developers could apply to existing problems in their applications. Core Animation sounds visually appealing, but I doubt it’s something many applications really “need” in order to accomplish their basic workflow. Same thing with Objective-C 2.0; although I’m sure many new .NET and Java developers will find it a little easier to work with, it’s not really going to let existing developers do anything they couldn’t do before. It looks like Objective-C 2.0 will be fully backwards compatible, which is good. I have no real desire to trade in retain / release memory management for the new garbage collection, since in certain conditions you really do need that extra amount of control, even if garbage collection makes things easier 80% of the time.

There are also a few new frameworks which will be worth looking over. The one that really caught my eye is the Calendar Store framework, which provides integration with iCal. Considering how much Web 2.0 calendar and productivity webapps have been in the news lately, I think we’re going to see a lot more integration between different platforms in the near future. I’ve used Plaxo a bit in the past, which is headed in this direction but only supports OSX Address Book data at the moment. Hopefully with frameworks like Calendar Store, by this time next year I’ll be using Outlook at work and on my PDA, iCal at home, and they’ll both sync up seamlessly.

I noticed a free PDF eBook by CocoaLab today, Become an Xcoder. It covers everything from variables and control loops, to more advanced topics like pointers and Objective-C memory management. Pretty basic overall, but it seems like a friendly introduction for any Mac user who wants to jump into programming for the first time.

On a related note, Scott Stevenson over at Cocoa Dev Central recently updated the Learn C for Cocoa tutorial. It’s worth a read if you haven’t had a chance to read through K&R, or just need to refresh your memory on C.

For a lot of programmers, no matter what language or technology you’re working with the hardest part of developing an application isn’t just writing code, but making the end result look nice as well. Those of us who prefer an IDE to Photoshop are pretty much reliant on what we can find on the internet, and a lot of what’s out there is only available for a fee, or includes restrictive licenses. Good design work is worth paying for, but for those independent developers without any real budgets, there are a few free alternatives. Here are a few I’ve used in the past.

FAMFAMFAM Icons
Over 1,000 very nice looking 16×16 px icons. They work great for websites, but are just as good for menu and toolbar icons in .NET programs. Cocoa applications use 32×32 px toolbar icons (or even higher, with resolution independence on its way), but you can still use them to spruce up a boring NSTableView.

Squidfingers Patterns
Dozens of simple, elegant looking patterns that make a great backgrounds for any website or application. I’ve noticed one or two other OSX software websites using them in the past.

Matt Ball’s Royalty Free Icons
I don’t know much about this designer, other than the fact that he posted some really nice 32×32 px OSX-ish toolbar icons on CocoaDev last year. The icon set includes many generic icons common to OSX applications, so you can quickly prototype a nice looking UI without resorting to stealing from someone else’s Contents/Resources directory.