Posts relating to software development with <code>Objective-C</code>.
Objective-C
Let me introduce you to the best language you’ve never heard of: Objectivist-C.
Although academic computer scientists have generally dismissed Objectivist-C, it has a zealous following among self-taught programmers and college sophomores.
Objectivist-C was invented by Russian-American programmer Ope Rand. Based on the principle of rational self-interest, Objectivist-C was influenced by Aristotle’s laws of logic and Smalltalk. In an unorthodox move, Rand first wrote about the principles of Objectivist-C in bestselling novels, and only later set them down in non-fiction.
Here’s what you need to know to program in Objectivist-C.
When you’re getting started with iOS development, it’s hard to figure out those first steps. What developer tools do you need? What are some good tutorials to start with? Where to begin delving into Apple’s thousands of pages of documentation?
That’s why I created iOS Development on 1 Page — a not-overwhelming guide for iOS newbies.
Is there any essential info about iOS development that should be added to iOS Development on 1 Page? Let me know!
Say you want to create a UIView
that you’re going to display in multiple places in your app.
Maybe you want to design a custom UITableViewCell
or AQGridViewCell
. Or maybe you want to create a view controller that can be displayed by several different view controllers in your app. Or maybe you want to create a custom UI widget that shows up multiple times in a view.
Does this mean you have to make the view programmatically? Is it time to break out the setFrame
and the addSubview
and the setTextColor
and the addTarget:action:forControlEvents:
?
Nope! You can still design your views in Interface Builder. Here’s how.
There are a lot of iPhone/iPad examples out there, but surprisingly I haven’t seen one for a common task — using a table view to create a form. Here’s the source code.
The IOSurface
framework lets you pass a reference to an IOSurface
— a kind of pixel buffer — from one process to another. Here’s an example of how to pass an IOSurface
through a mach port using the functions IOSurfaceCreateMachPort
and IOSurfaceLookupFromMachPort
.

- Works on Snow Leopard (with Mail.app running in either 32bit or 64bit).
- After moving a message, automatically selects the following message (instead of selecting nothing).
Mailbundle attached.
Steve Mokris is a developer at Kosada, Inc.
Cocoa’s NSSound
provides a blindingly simple way to play back audio asynchronously, and even provides some metadata and control over how the audio is played back.
It uses the default sound device, by default. It gives you the ability to change the output device.
According to the documentation:
- (void)setPlaybackDeviceIdentifier:(NSString *)playbackDeviceIdentifier Specifies the receiver's output device. playbackDeviceIdentifier Unique identifier of a sound output device.
That’s it. What is the “Unique identifier of a sound output device”? What format is this “Unique identifier”? How do I get a list of the “Unique identifiers” of the available output devices on my system?

In the year that has elapsed since I failed to explain why I was using PINE for email, I’ve switched to Apple Mail.
Well, it’s been alright, but much to my regret the improved latency due to keystrokes only traveling around my local machine – instead of through the interweb and back as was the case with PINE on a remote machine – makes it almost justifiable. Almost.
For years, iPhoto users have been stuck using a limited number of email clients to send their photos easily. This was mostly remedied by the iPhoto Mailer Patcher, but it left out non-applescript aware applications because, after all, iPhoto uses applescript to interface with them. One of the more notable omissions is Thunderbird.
Finally, this void has also been filled, via the iPhoto Thunderbird Bridge. It’s still quite primitive, but all the basics are there for iPhoto-Thunderbird integration.
If you’re an iPhoto/Thunderbird user, give it a whirl.
NSSpeechSynthesizer, the Cocoa class responsible for giving applications a voice under OS X, is leaky. Creating and destroying thousands of instances of this class slowly consumes all the available memory in a system, leading to degrading performance and eventual application instability.
The disappointing part is that this bug was first noticed almost two years ago.