chanson

The next CocoaHeads Silicon Valley meeting will be on Thursday, May 15, 2008 — that's tonight! — at 7:30 in the Garage 1 meeting room at Infinite Loop 4 on Apple's main campus. That's inside and upstairs at Apple's Infinite Loop campus in Cupertino. See the web site for directions.

This month's main presentation is on the Best of Both Worlds — an introduction to Cocoa development by Scott Stevenson.

This talk is a combination of an introduction to Cocoa, as well as a series of advanced tips and tricks that even relatively experienced Mac programmers may not know about.

The idea here is that we want to give all of the people who are new to Mac and iPhone development a chance to get started, but we also want to do something special for our advanced programmers. So rather than choosing one, we're just going to go ahead and do both.

Joel Norvell will also be presenting on how to edit PDF forms using Cocoa — he's done a lot of work with PDFKit and Cocoa, and I'm looking forward to learning from him.

Thanks a ton to Scott Stevenson, Steve Zyszkiewicz, Michael Jurewitz and Joar Wingfors for organizing!

In general, at a CocoaHeads meeting we do some introductions, have a presentation including Q&A time with the presenter, and then have an open Q&A and demo-your-cool-app period. After the meeting there's more independent mingling and discussion until it's time to go at 9:30. Often a subset of the meeting moves to BJ's Brewhouse in Cupertino, which is right in front of the Apple Infinite Loop campus on De Anza Boulevard.

The next CocoaHeads Silicon Valley meeting will be on Thursday, April 17, 2008 — that's tonight! — at 7:30 in the De Anza 3 auditorium at Apple. That's just inside the south side of De Anza 3, right across Mariani Avenue from Apple's Infinite Loop campus in Cupertino. See the web site for directions.

This month's presentation is all about designing and implementing your human interface. User experience and human interface design are critical for Mac OS X software to get right. To that end, there's even going to be a UI makeover as Scott describes in his post on the meeting!

Thanks a ton to Scott Stevenson, Steve Zyszkiewicz, Michael Jurewitz and Joar Wingfors for organizing!

In general, at a CocoaHeads meeting we do some introductions, have a presentation including Q&A time with the presenter, and then have an open Q&A and demo-your-cool-app period. After the meeting there's more independent mingling and discussion until it's time to go at 9:30. Often a subset of the meeting moves to BJ's Brewhouse in Cupertino, which is right in front of the Apple Infinite Loop campus on De Anza Boulevard.

The next CocoaHeads Silicon Valley meeting will be on Thursday, February 7, 2008 — that's tonight! — at 7:30 in the De Anza 3 auditorium at Apple. That's just inside the south side of De Anza 3, right across Mariani Avenue from Apple's Infinite Loop campus in Cupertino. See the web site for directions.

This month's presentation is by Scott Stevenson about Core Animation, one of the great new technologies available to Cocoa developers in Mac OS X 10.5 Leopard.

Thanks a ton to Scott Stevenson and Steve Zyszkiewicz for doing the organizing!

In general, at a CocoaHeads meeting we do some introductions, have a presentation including Q&A time with the presenter, and then have an open Q&A and demo-your-cool-app period. After the meeting there's more independent mingling and discussion until it's time to go at 9:30. Often a subset of the meeting moves to BJ's Brewhouse in Cupertino, which is right in front of the Apple Infinite Loop campus on De Anza Boulevard.

The next CocoaHeads Silicon Valley meeting will be on Thursday, November 8, 2007 — that's tonight! — at 7:30 in the Town Hall auditorium at Apple. That's just inside Infinite Loop 4, right around the loop at Apple's campus in Cupertino. See the web site for directions.

This month's presentation is by Deric Horn, Application Frameworks Evangelist at Apple. He's going to take us on a tour through what's new in Cocoa in Leopard!

Thanks a ton to Scott Stevenson and Steve Zyszkiewicz for doing the organizing!

In general, at a CocoaHeads meeting we do some introductions, have a presentation including Q&A time with the presenter, and then have an open Q&A and demo-your-cool-app period. After the meeting there's more independent mingling and discussion.

When we haven't had a presentation or two lined up, we've also had some great "unmeetings" (in the spirit of "unconferences") where we came up with an agenda for the core of the meeting on the fly by writing down topics and questions on our room's whiteboard and talking about each one of them for a few minutes. It worked really well.

Update: Every CocoaHeads gets bigger. Tonight's meeting has 59 people so far, which is nearly a 20% increase over last month's meeting!

That's right, Objective-C has garbage collection now in Leopard! And it's not just a conservative collector like the Boehm collector GNUstep supports, either; it's a full-fledged multi-threaded, generational garbage collector! (Though due to the limitations imposed by C semantics, it isn't a copying collector.)

Practically speaking, this means that you don't have to worry about memory management in Cocoa applications the way you used to, if you can require Leopard. You're not entirely freed from worrying about memory management, of course: For one thing, you need to be careful about multithreading, as any -finalize methods you implement will be run in a collector thread. For another, you can still easily over-root objects that should be collectable; this is a common cause of memory leaks in garbage-collected applications, and should be familiar to Java developers.

To address the over-rooting problem, zeroing weak references have been introduced to Objective-C. By prefixing an instance variable declaration with __weak, you tell the garbage collector that if it's the only reference to an object that the object should be considered collectable. And when the object is collected, the instance variable will be set to nil for you!

This works for any number of weak references to a particular collectable object. So long as there are no strong references to an object — which are the regular kind of non-weak references you're used to — an object is eligible for collection no matter how many weak references there are to it. Thus I can create an object, assign it to a thousand different __weak instance variables, and then not assign it to any regular instance variables, and it will eventually be collected and all of those __weak instance variables will be "simultaneously" changed to nil.

Because objects are commonly stored in collections — for example, in static NSMutableDictionary instances that are used as caches — the Foundation framework also has some additional classes that can support weak references. There's NSPointerArray, NSHashTable, and NSHashMap:

• NSPointerArray is a lot like NSMutableArray, but it can contain arbitrary pointers (not just objects) and also supports nil elements and can hold zeroing weak references.
• NSHashTable is a lot like NSMutableSet, but it can hold zeroing weak references.
• NSHashMap is a lot like NSMutableDictionary, but it can hold zeroing weak references for either its keys or its values, and doesn't have to copy its keys.

And most importantly, the behavior of an instance of any of these classes can be customized by creating an instance of the NSPointerFunctions class: That's how all of the above collection classes implement their equality comparison, hashing, and weak-reference behavior. See the header or documentation for details.

One other thing you can do is create hybrid applications and frameworks. As Scott Stevenson shows in his Objective-C 2.0 tutorial, you can build an application or framework such that garbage collection is either supported or required. For frameworks this is particularly useful; after all, you may want to use a framework in both a GC and in a non-GC application. By building it as GC-supported rather than GC-required, you can create a single framework binary that can be used in either.

How does this work? It's simple: When running under GC, the Objective-C runtime will "eat" all -retain, -release and -autorelease messages such that objects never receive them, and objects will never be sent a -dealloc. However, you can still write your code such that it has all of the proper non-GC memory management too. Then when you build it GC-supported, if it's loaded into a process that is using the collector it will use GC, but if it's loaded into a process using reference counting it will behave correctly there too.

There are a couple of things that you can't do with GC. One is that you can't use a non-GC framework in a GC application; an entire process has to be either GC or non-GC. Thus if you use third-party frameworks that haven't been made hybrid, GC-supporting frameworks, you'll need to stick with reference counting until the frameworks are updated.

The other thing you can't do with GC is write code that makes use of GC but that runs on pre-Leopard operating systems. Code built for GC uses certain runtime calls that are not present in earlier versions of the Objective-C runtime, and unfortunately this means that code built for GC requires the Leopard version of the runtime to execute. Leopard contains so many other compelling developer and end-user features, and other Objective-C 2.0 features also require Leopard, so in practice this probably won't be such a huge deterrent.

Update: At jcr's request, I've expanded the discussion of weak references to make it clear that the number of weak references to an object doesn't matter; as long as there are no strong references to it (whether in instance variables, reachable via globals, or on the stack or in registers), it will be eligible for collection.

One of the great new features in Leopard is a standard way of supporting source lists — those blue outline views with a gradient highlight, like in iTunes, that provide an interface to some collections of objects.

These have become quite common in a lot of applications since their introduction in iTunes, and everybody does them slightly differently. Now, though, there's a simple way for applications running on Leopard to get the source list look and feel almost for free!

There's a new property added to NSTableView called selection highlight style. There are currently two possible values for the highlight style: Normal, the default, which gets you the regular look and feel and selection highlight behavior, and source list, which gets you not just source list-style selection highlighting, but also gets you the proper background color — whether you're in the foreground or the background — and for outline views, will also get you the proper indentation per level, the row height, and inter-cell spacing.

You can even set this property directly on your table or outline view in Interface Builder 3!

Of course, the obvious next question is "How do I get the small-caps look for section headers like in iTunes, Mail, and the Finder?" It's pretty simple! There are just a couple of methods you'll need to implement in your NSOutlineView delegate as described by Jim Puls in this message to the cocoa-dev list on October 26; conceptually, all you need to do is tell the outline view that your header items are group items — another new feature in Leopard — and then, when the cell containing them is displayed, adjust their string to be all-caps.

Mac OS X 10.5 Leopard will be available on October 26, 2007! That's only ten days away!

Leopard kicks ass. It's a great release; I've been running it for many months, and it's really freaking sweet. Especially a lot of the "under the hood" changes for developers — there are a huge number of new developer features coming in Leopard that will really help you take your Mac OS X applications to the next level. Trust me — even if you still want to target Tiger, you'll want to live on Leopard to do so.

I can't wait to be able to actually talk about the nitty-gritty details of what is so cool and why it's so cool outside of work. In the meantime, just trust me, and either go to your local Apple Store on October 26 or pre-order online. I think you'll be quite pleased with what you get.

The next CocoaHeads Silicon Valley meeting will be on Thursday, April 12, 2007 from 7:30-9PM in the Hong Kong conference room at Apple. That's just inside the entrance to Infinite Loop 1, the main headquarters building at Apple's campus in Cupertino.

See the web site for details, directions, and the organizer's contact information.

R. Tyler Ballance will be talking about C#, Microsoft .NET 3.0 and Visual Studio.NET 2005 as someone who has used both platforms extensively. But don't worry, he's not pitching us on becoming a Microsoft developer! He'll be comparing and contrasting it with Objective-C, Cocoa, Xcode and Interface Builder — even covering some of what's coming in Leopard — and he may even cover what the Open Source community has to offer with Mono.

As always, we'll also be hanging out and talking about Cocoa in general, discussing new and cool things that have come up in the past month, and helping each other out. Join us!

Collections are quite widely used in a lot of the code I see posted to the Cocoa-dev mailing list and elsewhere. Unfortunately, many times they're not used to represent collections of objects but rather to represent objects themselves. In one recent pathological case, I even saw some code that used an NSMutableArray as a model object instead of the typical NSMutableDictionary, complete with hard-coded indexes to represent the different properties of the object!

Why's this a problem? This goes back to the core tenet of object-oriented programming: In object-oriented programming, you write software by sending messages to objects, and these objects are state plus behavior. When you use a dictionary or an array as a model object behavior goes out the window — the only behavior you'll get out of that model object is that which makes it a dictionary or array, not anything specific to your application.

Thus even if you're only just going to implement accessors to start with, you're generally better off creating classes to stand behind your model objects because you'll have an easier time moving appropriate behavior into them. And if your application targets Leopard this is extra-easy thanks to the new support in Objective-C 2.0 for properties.

There's a Leopard Developer Tools Overview now at the Apple Developer Connection!

The developer tools in Mac OS X Leopard are crafted for one mission: to enable you to create amazing applications. Offering a streamlined workflow, Xcode 3.0 helps you develop your applications faster than ever. The all-new Interface Builder lets you build awesome user interfaces that take full advantage of Leopard's capabilities. The new language features in Objective-C 2.0 speed up your development cycle. The innovative new Xray brings the ability to visualize your application at runtime in a way that's never before been possible. And, the brand-new Dashcode makes it a snap to create elegant and powerful Dashboard widgets.

It's the second article in the Leopard Technology Series for Developers, and boy is there a lot of meat there!

The article covers a whole lot of tools: Xcode 3, Interface Builder 3, the extremely innovative new Xray performance tool, and Dashcode, Apple's environment for creating Dashboard widgets using HTML, CSS, and JavaScript. There's a lot of coverage of Xcode enhancements including code folding, improved syntax coloring, inline display of errors and warnings, inline editing of breakpoint conditions, and mouse-over inspection of variables while debugging.

Of perhaps even more interest than the new tools to Cocoa developers will be some information about new language features in Objective-C 2.0 including fast iteration of collections using for ( … in …) syntax and properties that eliminate the tedium of implementing accessor methods and streamline accessor syntax.

Check it out!