File this one under useful snippets for Mac Cocoa development. How to extract the application version number out of your app's info.plist file.

You are writing a Mac Cocoa application, and you know you want to store your user specific application support files in a predictable location, like ~/Library/Application Support/<Application>/. So... how exactly do we do that?

Once again, Google to the rescue, and we find the answer at Cocoa Dev Central. This will not only construct the file name for you, but it will create the directory if it doesn't exist, too.

- (NSString *) pathForDataFile { 
    NSFileManager *fileManager = [NSFileManager defaultManager]; 

    NSString *folder = @"~/Library/Application Support/MyApplication/"; 
    folder = [folder stringByExpandingTildeInPath]; 

    if ([fileManager fileExistsAtPath: folder] == NO) { 
        [fileManager createDirectoryAtPath:folder attributes: nil]; 
    }

    NSString *fileName = @"MyApplication.mysettings"; 
    return [folder stringByAppendingPathComponent: fileName];
} 

Again, an example that just works. I'm on a roll today.

I was struggling with my Photoshop plugin again. The plugin window is modal. But then I need to pop up a modal window, in order to prompt the user for new name/description for the user-saved presets. I was puzzling and Googling, and then I stumbled across a reference to "sheets". Bingo!

This page has the best little example of sheet usage. I was able to copy/paste and then a couple of tweaks, and a couple IB bindings and it all just worked.

- (IBAction)openSheet:(id)sender
{
	[NSApp beginSheet: theSheet
			modalForWindow: theParent
			modalDelegate: self
			didEndSelector: @selector(sheetDidEnd: returnCode: contextInfo:)
			contextInfo:NULL];
}

- (IBAction)theSheetOK:(id)sender
{
	[NSApp endSheet:theSheet returnCode: NSOKButton];
	[theSheet orderOut:nil];
}

- (IBAction)theSheetCancel:(id)sender
{
	[NSApp endSheet:theSheet returnCode: NSCancelButton];
	[theSheet orderOut:nil];
}

- (void)sheetDidEnd:(NSWindow *)sheet returnCode:(int)returnCode contextInfo:(void *)contextInfo
{
	if (returnCode == NSOKButton)
		NSBeep();
}

I really love code examples that just work.

Cocoa-in-Carbon application. Note to self. Do NOT "freeze-dry" a controller object in your NIB file, especially if your controller object opens your NIB file in it's init method.

Just sayin.

Parallels provides a nice tool for resizing the file you have chosen as your hard drive for your virtual machine, called the Parallels Image Tool. Unfortunately, Windows is not quite so cooperative, and will not just recognize the resized file as a larger HDD automagically. You need to resize your partition, and Windows doesn't provide any easy ways of doing this.

Googling for a solution, I discovered this very detailed example using Gparted - the Gnome Partion Editor Tool with Parallels. Unfortunately, it is old, and when I tried it the Gparted image refused to boot cleanly, with some sort of error on ... mouse detection, I think. You should just go directly to the Gparted project at SourceForge, and find the most recent stable ISO file to download. While booting, most of the instructions from uneasysilence no longer apply to the new version of Gparted, but I just went with the defaults, and it all worked. Once GParted is up and running, then the instructions from uneasysilence are useful again.

Having recently acquired an iPhone (yes, yes, hacked to work in Canada), I've been drawn to all these iPhone SDK articles. I mean, it's a realy cool device, so who wouldn't want to develop apps for it?

But different developers have really different ideas about it. Here are a few that I've read:

The iPhone is Now THE Platform for the Future of Mobile Computing

Lest you think me an Apple "fan boy", for the record I don't yet own a Mac. However, after watching the video of how the iPhone SDK works and since that SDK only plays on Macs, I'm going to drop a thousand on a Mac Book. It's well worth the investment just to play in the iPhone world.

The apparent quality of the SDK is so superior to anything out there in the ME world that I'll easily recoup the investment in development time alone and that includes learning from scratch Cocoa and Objective C (not that big a challenge for a Java jock.) Yes. I'd like to be able to code in Java to save myself a bit of learning curve but when you consider how much time is spent in UI coding vs the rest of the app, my gut tells me that being able to leverage all of the built in iPhone widgets and built in APIs (which is unlikely in Java) will more than make up for the little bit of Cocoa that I'll have to learn to do the things that are the unique value add of my code.

If you haven't watched the Apple iPhone SDK tutorials, give them a look and then compare them to what you know in the J2ME space. If you are like me, you'll want the full package and not some "slap a JVM into the iPhone so we can do SWT apps" solution.

Prohibiting background processing is not just a question of one feature being left off a long list of otherwise very well executed features. The issue of background processing is *the* issue for a mobile device because it is key to two things:

• telling the world about your status in some ongoing way
• receiving notification of important events

These two things are the key to most new real innovations in the mobile space. To be clear, by innovation, I mean creating functionalities that have not been possible before. I do not believe that Apple’s beautiful new iPhone UIs or visual metaphor’s allows for the creation of truly new application categories. Apple’s tools are great, but they just make apps that were already possible, easier to build and easier to use. But as a developer, I want to create things that have been bottled up in my head but without the right platform, were fundamentally impossible to do.

Craig Hockenberry is the man, the myth, and the legend behind the absolute best Twitter application on the Mac (he works for the Iconfactory). We would all love to see Twitterrific on the iPhone, but Craig offers up a "healthy dose of reality" regarding the iPhone SDK and backgrounding services (applications that run in the background even though the phone is running a different foreground app).

In a recent blog post, Craig attempts to explain why Apple will not be giving developers access to backgrounding services on the iPhone. He points out that in a mockup design of "Mobile Twitterrific," based on the jailbreak/community toolchain, refreshing the XML data from Twitter every 5 minutes led to a dead iPhone battery in only 4 hours.

"The heart of the problem [is] the radios. Both the EDGE and Wi-Fi transceivers have significant power requirements," he says. "Whenever that hardware is on, your battery life is going to suck."

He also reiterated what Apple said about the "Core Location" feature that Apple provided in the SDK: use it only on an "as-needed" basis. Craig said that the issue of backgrounding services may get addressed later on, but right now Apple is preventing iPhone developers from "shooting themselves in the foot." He said that it will take months before the desktop developers have gotten the mindset of an iPhone developer, and that thinking like a desktop developer will lead to bad designs.

For some reason, all of this reminded me of a panel I attended, at a science fiction convention in Edmonton, some time ago. The title of the panel was "Collecting... Tool of Satan, or just a really, really, bad idea?" I think the people who are the most bent out of shape in iPhone land, are the collectors. They want their cool new toy, and they want it to be perfect, and it has to be NOW. The platform will evolve, and some day they will be able to do every cool thing that they can think of. But for now, let's all be calm and realize that the iPhone and iPhone SDK are not evil. The collection is just... incomplete.

Ok, here’s mine!

Vote for Java6 on Leopard!

As mentioned previously a lot of Java developers on OSX are upset at Apple’s silence as to its intentions with respect to the release of Java 6. There used to be a developer preview available, which was pulled recently with no indication as to when a replacement would be available. People like me who upgraded in the hope of having the latest and greatest – which we have been very patiently waiting for over a year for – are very disappointed. Some who are working on Java 6 projects cannot use their computer easily, without resorting to installation of a separate OS in a virtual machine, to do their job. We all like OSX: its a beautiful easy to use Unix that usually really helps us get our work done. I have been very happily using it since 2004.

The solution of course is to have our voice heard. One way to do this is to file a bug with Apple. Please do this! The only problem I have with it is that as opposed to the Java bug database which is completely open, the Apple bug database is completely closed. So there’s no real way of verifying how many people have posted a report. We must therefore complement that action with an equal Open action. Following the noble example given to us by Nova Spivack, when he asked for people to make their voice heard in support of the Burmese people and got some real results, let us do the same to help Apple make the right decision. Anybody who would like to support this issue in the blogosphere, should help post a blog with the string

13949712720901ForOSX