As I prepare AlphaTalk for iOS7, there are all of these new sizes of icon files that I need to support. I wanted to easily see what sizes I already had (as my file names aren’t always that helpful). I thought it would be nice to see the image dimensions in list view in the Finder. So, here’s an Applescript that can be used as a service to put an image file’s dimensions into the Comments field of the file. It wipes out any other comments that are there, so beware if you were using the comments field for something interesting. In Automator, you can just create a new service, have it only accept image files, and then have it run this AppleScript. Hope this works for you!

on run {input}
set theList to the input
repeat with x from 1 to the count of items in theList
set theFile to (item x of theList) as alias
tell application "Image Events"
launch
set this_image to open theFile
copy the dimensions of this_image to {xdim, ydim}
close this_image
end tell

tell application "Finder"
set theName to the name of (item x of theList)
set commento to (xdim as string) & "x" & (ydim as string)
set comment of theFile to commento
end tell
end repeat
end run

I’m going through AlphaTalk, getting it ready for iOS7. There isn’t a huge amount of work to do, but as I read through the code, I have a hard time leaving things alone. One trend I noticed in the existing code base (which dates back to the early versions of AlphaBaby), is that I have a tendency to create objects and hold onto them for dear life. I think this goes back to the days when “creating” an object was a somewhat expensive thing, and if I didn’t have to create it again, all the better to hold onto it and reuse it if necessary. That led to all kinds of code that needed to keep these objects “in the loop” about various state changes that may happen when they are not being displayed. This is Just Silly. I should create these objects when I need them, and then let them get deallocated when they go off the screen. They are not horribly complex objects, just some simple UITableViewControllers and such. The work I had to do to keep them updated with various state changes disappears - the controller simply reloads its state every time it is created (which is every time it is shown on the screen). I think I really started thinking this way when segues were introduced. Every time you push/pop a segue, the view controller is created and then destroyed. So much cleaner, and it is actually more memory efficient since you aren’t holding on to views that you *might* visit again, for just the very small cost of creating them fresh every time.

So, in addition to getting rid of @synthesize statements, adding the lovely @[ ] array creation code, and getting rid of forward declarations for methods, I am going to be on the lookout for unnecessarily maintained objects. They are hiding in there, just waiting to be ripped out!