I keep coming across code like this:

newMonster.trueName = [NSString stringWithString:@"New Monster"];

It’s time to say stop it already with the extra +stringWithString:. I haven’t worked out yet where this anti-pattern comes from. Maybe it’s a misunderstanding of some sample code in Kochan? Maybe it’s a Java/.NET thing? I’m not sure. But I see it so often from so many places that it’s clearly something that needs discussing. (The rest of the linked article is good; it just gave me a good example of this issue.)

Observing NSNotifications in a view control is a good thing. But remember, just because you’re not onscreen doesn’t mean that you’re not still observing. This is particularly noteworthy on iPhone, where your view can get dropped any time memory is tight and you’re offscreen, but it can bite you anywhere.

ViewControllers, WindowControllers and other UI controllers are often better off registering and uregistering for notifications when they are put on and off the screen rather than when they are allocated and deallocated. This often means that they will need to update their state when put on screen. For example, an icon indicating “connected” might be part of a StatusViewController. When StatusView comes on screen, StatusViewController should update the connected status and then begin observing changes on it. When StatusView goes off screen, StatusViewController should stop observing.

Based on a post at StackOverflow. The question was whether Objective-C is only used for development on Mac OS/iPhone and why.

I think ObjC has been isolated to the Apple world through a quirk of history and the nature of proprietary systems.

It thought I was going to be quiet for two weeks, now three posts in a day. There was a good question on Stack Overflow about getting system information. The actual question is “what does system_profiler actually do?” But it’s a good way to show how to begin to understand how any program works on the Mac. Here are some of the most basic tools of the trade. This is not a deep tutorial on reverse engineering. It’s a whirlwind tour of how you begin to attack programs using pretty standard tools. I’m not getting into any of the anti-obfuscation tools like Onyx the Black Cat or commercial tools like IDA Pro, or even code injection like SIMBL or F-ScriptAnywhere. When you think you’re going to hide how your program works, make sure you research those first. You’ll learn quickly how hard that really is. Maybe you should read my thoughts about Obfuscating Cocoa.

We recently had a discussion on cocoa-students (the excellent list for Big Nerd Ranch alumni; yet another reason to go to BNR classes) about protecting Cocoa programs from reverse engineering, mostly around some anti-copying code. I had some thoughts on the subject since I happen to have a background in anti-counterfeiting.

Cocoa is a reverse-engineer’s dream. Spend some time at culater before dreaming you can really protect a Cocoa program. Objective-C is meant to be highly readable both in source and at run time. Obfuscation is not in its nature. This only points out Objective-C’s particular difficulties in this area; it is not to suggest C or C++ will save you. They’re just not quite as trivial as Objective-C.

That said, the world of obfuscation falls into three big camps: you can try to deal with 70% of your problem, 75% of your problem or 90% of your problem.

It’s been quiet here for a while. I’ve been spending most of my time working on XMPPFramework, an opensource framework that makes it easier to build XMPP clients for Mac and iPhone. I’ve been working on this nonstop for several weeks now in preparation for a demo based on this, so there hasn’t been a lot of time to post here. My code for that demo is done now, and I’m headed off on vacation for two weeks. So you should see more traffic here in July. I have quite a backlog of topics I just haven’t had time to really capture.

If you’re interested in a less edited form of my Cocoa musings, I still answer questions at Stack Overflow (feed), and I’ve started experimenting with Twitter, though I’m not sure yet how much I like tweeting.

See you all in July!

I can’t take credit for finding this myself. Gilad Gurantz forwarded it to me. From the Quartz Event Services documentation:

CGEventTimestamp

Defines the elapsed time in nanoseconds since startup that a Quartz event occurred. typedef uint64_t CGEventTimestamp; Discussion An event timestamp is a big, unsigned, 64-bit number. That's big, really big. You just won't believe how vastly, hugely, mind-bogglingly big it is. You may think your application has been running for a long time, but that's just peanuts to an event timestamp.

So if my math is right, “a long time” translates into over 2850 years. And it’s counted since the last reboot. I think we’ll avoid the Y2K problem on this one.

In Part 1 of our series, you learned how to use basic xcconfig files to manage build configuration in Xcode rather than using the Build Panel. This is useful, but a bit tedious to set up every time you make a new project. What we need is a way to automatically create new projects that have our setup in place already. Wouldn’t it be nice if you could create new Project Templates just like the ones that come with Xcode? You can, and since the release of the iPhone version of Xcode, it’s easier than ever. Let’s make one.

For those of you worried about the trouble with PandoraBoy’s hotkeys and Applescript, I’ve finally carved out some time to work on this stuff. I keep getting hung up on the hotkeys preference pane, which can’t be opened in IB3, due to the use of the Shortcut Recorder IB Palette. The answer, I’ve always known, is just to rewrite the hotkey pref pane. It isn’t that hard, I’ve just avoided it, and it’s finally time to do it and fix a few bugs in the process.

Have I mentioned recently that PandoraBoy is an excellent small project to practice and hone your Cocoa skills?

XCode has a decent build system, but it doesn’t work as well as it could out of the box. With just a little work, you can make your projects easier to setup and maintain just the way you want them, improve your code, and even speed up your build times.

The first thing we want to do is get rid of one of the great obfuscations of Xcode: The Build panel.

The build panel seems convenient at first, but in practice it makes it hard to see what’s going on in your build. It especially gets confusing as your build settings get complicated. When you need to turn off Thumb Code Generation because of an obscure assembler conflict in legacy C++ code (true story), it would be nice to put a comment somewhere indicating why you’ve done this so someone doesn’t come along later switch the setting. The Build Panel doesn’t give you an easy way to include comments right along with the setting (the “Comments” panel is pretty useless in my experience), and it’s easy to lose settings or accidentally apply them to only to one configuration.

XCode provides a better solution called xcconfig files. Everything you can do in the build panel can be done in xcconfig files, and you can actually read them and make comments. So let’s make some.