Simplifying your code using NSDictionary
Matt Gallagher has put up yet another fantastic blog post. This time he’s tackling the issue of removing the data from your code with an easy to understand example that shows off a very powerful design mechanism.
If you aren’t already subscribed to his blog and you consider yourself a Cocoa developer you need to smack that big giant RSS button right after clicking the link:
Simplifying your code using NSDictionary
The past few weeks have been quite the whirlwind of activity here at Camp Fruit Stand, and I have some exciting news: I am now an intern at United Lemur, working on an iPhone game for them, and loving every minute of it.
As I look back at the date on my last post I’m not surprised that it’s been over a month since I last had a chance to put anything into print. Any free time that I have had has been spent either working on the house or reading the developer documentation from Apple on how to write software for the iPhone.
Even though I’m the “new guy” everyone has welcomed me with open arms and instantly made me feel like a member of the team. From day one I was given a new name (I am now known as Mike McChristopher among my fellow lemurs), a new email address, and full responsibility for a project that will result in another great United Lemur app in the App Store.
It has also been fantastic to be behind the scenes in the troop’s chat room as their initial foray, Puzzllotto, has played out and to watch as they prep their next big thing.
I think one of the best things about having the opportunity to join this troop is that I am part of an incredibly talented group of developers, designers, and engineers that aren’t just doing this to get rich. Something great happens to a person when they are exposed to others in their field that are so obviously passionate about what they do.
I’d also like to take a few words to thank Mike Lee. From the beginning Mike has been one of the nicest, most easy going, easily approachable guys I’ve ever had the pleasure to meet. He has given me an incredible opportunity by allowing me to join him in his crusade to save the lemurs and for that I thank him.
Now don’t worry, I will still be creating new posts here (in fact I’ve got a couple in the queue already), but be warned: my future posts might have a bit of lemur scent on them.
The Case of the Missing HUD Controls
With the advent of Leopard Apple made some significant upgrades to the library of UI controls that it makes available to developers through Interface Builder. One of the more lauded controls was the inclusion of the HUD Window.
The celebration over the inclusion of this flavor of NSPanel was quickly followed with confusion and anger over Apple’s apparent incompetence to deliver any of the standard controls in a HUD flavor. Apparently someone got tired of waiting for Apple to realize their mistake and decided to just whip up their own versions instead.
Head on over to binarymethod.com and checkout the free BGHUDAppKit library and Interface Builder plugin.
The Mac Developer Roundtable Episode 12: Developer Groups
If you’re a fan of Scotty’s podcasts (though who isn’t, I mean really…) and you think you can stand to listen to me and 6 other guys ramble on about developer groups for 1 hour, 34 minutes and 4 seconds head on over to Mac-Developer-Network.com and download the latest episode of The Mac Developer Roundtable.
I was lucky enough to be joined by a great crew of developers: Scotty (of course), Jiva DeVoe, Joe Heck, Paul Kim, Dave Verwer and Jonathan “Wolf” Rentzsch.
This is my second time recording a podcast with Scotty and I think I did a lot better than my first outing. Hopefully Scotty still feels that I’m a worthwhile guest and I’ll get to polish my skills a bit more in the future.
Bar Harbor, ME: A Screen Saver
A couple of years ago I whipped up a photo screen saver bundle from some photos that I took while my wife and I were on our second honeymoon. I’ve always meant to release it, but have just not gotten around to whipping up a download page for it or uploading it to MacUpdate or Apple Downloads.
That being said, I’ve decided to provide it here for now, just to get it into a few folks hands and maybe even gather some feedback on it. It’s a doozy of a download (47.3 MB) but it contains 12 high resolution photos in and around Bar Harbor.
Grab it here: BarHarborME.slideSaver.tbz and let me know what you think.
This content is being provided under the Creative Commons Attribution-Noncommercial 3.0 Unported license.
stevenf.com: How To Report a Bug
Steven Frank (of Panic fame) has posted a great article on his site: How to report a bug in a Mac OS X application
Here’s the teaser:
Bugs happen. It’s a fact of life. Although you may not be in the mood at the exact moment they strike, the best possible thing you can do is file a bug report with the developer. You may not get an immediate solution, but you will provide extremely valuable forensic information that should help the developer fix the problem over the long term. Here’s how to report a bug effectively.
Developers hate having bugs discovered by their users, but hate getting lousy bug reports even more. I’m tempted to include a variant of this article in the Help section of my next app under the heading, What should I do if I think I’ve found a bug?
Just from reading the title of this post most of you already know that I’m writing about Cocoa Programming for Mac OS X, 3rd Edition by Aaron Hillegass. I am currently working through this fantastic manual that claims it will teach me 80% of what I need to know in order to get started.
Now it’s true that I’ve already released an app into the wild and some of you may be asking yourselves why such an accomplished software author would bother going back to learn the basics. First off, quit kissing my butt with that “accomplished software author” stuff, I’m not even close to that goal yet. However, your question is valid, why am I starting back at the beginning? The truth is that even though I consider myself a semi-decent programmer, I am hardly a decent Cocoa programmer. Yet.
When I decided to write Bezipped I chose it because it was an app that had a small enough scope that I could create it in a short amount of time, but big enough that I could make a decent amount of fundamental mistakes in its design and execution. I needed some sort of starting point, a basis for all the stuff I was going to learn, a comparison point for all the stuff I would do wrong.
I currently have 90 pages left to read in The Book and once I finish I’m most likely going to rewrite Bezipped from the ground up using all the techniques that I’ve learned over the past months. I may even document it on the blog here so you too can learn from my mistakes.
There’s a great post on The Daydream Blog about coming up to speed with Cocoa development. One paragraph really rang true for me:
Every time you try to learn a new aspect of Cocoa, you find yourself struggling to do something that feels like the “right way”. A few days later you come out with 3 lines of code that feel completely natural but felt incredibly painful to reach. You will be met with countless, “aaah, that’s how it works and it makes complete sense” moments. You spend days wondering why this bit of Cocoa is so gnarly, and seemingly unintuitive, until you reach another moment of understanding.
Read the whole post here.
Finding Memory Leaks With The LLVM/Clang Static Analyzer
While you may be familiar with using tools like Instruments to find and fix memory leaks in your application, the Clang Static Analyzer takes a different approach to memory leak detection by compiling your Xcode project and scanning each method, class, loop, and logic block for potential leaks. You may have heard of the Clang Static Analyzer referred to by the name of the command line tool used to run the analyzer: scan-build. That is how I will be referring to it for the remainder of this post.
scan-build is currently only available in binary form for OS X 10.5.
If you haven’t yet downloaded scan-build head on over to the LLVM/Clang Static Analyzer homepage and look for the Download section at the bottom of the page. Click the link for checker-NN.tar.gz (where NN is some build number). At the time of this writing the link reads checker-72.tar.gz. The developers of scan-build are very active so I have no doubt that the build number is already different.
Since scan-build is a command line tool it makes sense to install it into one of OS X’s pre-defined command line tool locations. We’ll put it in /usr/local/bin.
sudo mv ~/Downloads/checker-NN/* /usr/local/bin/
scan-build tests your code by compiling your Xcode project and studying it for defects during the build process. To check your code, you just invoke scan-build from the command line at the top level of any one of your project directories.
scan-build xcodebuild** BUILD SUCCEEDED **
scan-build: No bugs found.
or something similar to
** BUILD SUCCEEDED **
scan-build: 7 bugs found.
scan-build: Open ‘/tmp/scan-build-fw1RAD/2008-07-31-1/index.html’ to examine bug reports.
After running scan-build a few times the first thing that you might want to do is tell scan-build to put its reports in a different directory. To do that, simply specify the output folder on the command line like so:
scan-build -o /path/to/the/directory/where/you/want/your/report xcodebuild
There are a few other flags that can be passed to scan-build, but for now the reports that are generated should be the same regardless of the flags you set. Check out the Other Options section on the Static Analyzer usage page for the full (but still pretty short) list of available options.
One thing to note is that scan-build is still in pre-1.0 and has some rough edges. You may notice some false-positives or other undesirable behavior. As with any pre-release software use it at your own risk and always have a backup of your work. That being said, I have not had nor heard of any disastrous problems with it, so your risk is probably pretty low.
A lot of folks in the OS X development community have gotten a lot of use out of scan-build in the past few months. One of the larger scale uses of it can be found on the Adium project, you can view the results of their static analysis here.
Good luck!
I was fortunate enough to be invited by Steve Scott (Scotty) to be on the latest Mac Developer Roundtable podcast with Danny Greg and Marcus Zarra. We recorded for 3 hours and it was a ton of fun (don’t worry, the edited version was only 1.5 hours long). We covered a wide range of topics from the new iPhone, new technologies and how and why we use them, how Windows programmers view our development tools and the usual round of “developer picks”.
If you’re a Mac developer and are not currently subscribed to The Mac Developer Network podcasts I highly recommend heading over to Scotty’s site and checking it out. Scotty is a fantastic and gracious host and runs a great podcast.
