Metadata Viewer
Posted by Daniel Lyons Thu, 17 May 2007 08:30:00 GMT
For part of an app I’m working on I need to be able to load Spotlight’s metadata from a given file. There is apparently a Carbon API for doing this but not a Cocoa one; Cocoa just manufactures NSMetadataItem objects for search results, whereas Carbon creates MDItems for you either given a path or as search results. This sucks, so I decided to fix it before going any further. Plus it was a nice small thing I could make an app with to sharpen my lousy Cocoa skills.
Result: MetadataViewer.
Drop a file on that icon and it shows you a little table with all the metadata. So much nicer than mdls. Sure. And probably implemented a dozen times already.
Observations
Cocoa’s a lot harder than I remembered. Memory management is as awkward as you’ve been lead to believe. In fact that app has a small memory leak. I believe that leak has to do with my confusion about what to do with “objects” created by Carbon rather than Cocoa though.
I tried to get unit testing to work. OCUnit has been included with Xcode for some time now. Ultimately, with much manual tweaking, I was able to get to a point where it would build and run the test script, which would merrily report that none of my 0 test cases failed. Fearing for my forehead, I gave up.
I thought about documentation. I tried HeaderDoc and found it noisy. The real developers seemed to be saying that Doxygen is better anyhow. So then I stopped caring.
Bindings saved the day. Of course, realizing that the reason why my app wasn’t doing anything was because I hadn’t set up the bindings yet was a priceless moment. (“Oh yeah…”) And then fussing with it because I wasn’t quite sure how to hook up the model object to the array controller was also priceless. I had to use bindings for that, rather than the direct connection, because the array is a property of my NSDocument instance. But once I did that, it worked, with the usual amazement.
Bindings are very cool. I worry about the magicalness but I have a pretty good handle on what I think is going on underneath the surface, so I’m not too worried about it killing me in the future. But I do wonder. :)
Like Rails, Cocoa suffers somewhat from being so accessible. I really should read and memorize a bunch of documentation about memory management before I get too serious about using it. But it’s so easy and fun, particularly using Interface Builder and the bindings, that I find myself thinking, “well, who cares about a little memory leak?” Nobody, until it shits all over the place.
I’m surprised at how much work the “easy” part of this was, and how little work the “hard” part of this app was. It took me about half the time to create a correct, mostly non-leaky five-method object. That seemed like a long time, but I guess I was relearning the memory management stuff and the syntax and the right way to iterate through a collection, using the debugger and things like that. Having a nice big hooked up interface like that took almost no effort. In fact, what would remain to be done if I cared to look at it would be to disable more functionality. It thinks those objects are editable, and they aren’t; it thinks you can create new documents and you can’t, etc. I don’t think it’ll let you save, because I didn’t implement the saving method, but it doesn’t know that, really.
So there you go.
Edit 1:16 PM: I’ve updated the app to not create new files and not permit editing of the content. And I made the table use the whole window. So it’s a little nicer. Same link above.
