1. Use TidyUp To Purge Duplicates. TidyUp (download link), by Hyperbolic Software is a great way to search your iPhoto library for duplicate items. Every now and then, my iPhone will re-import photos, or forget it already imported them. TidyUp lets you search using some fairly granular criteria to eliminate duplicate files.

2. Keywords are your friends. I tend to go a bit keyword crazy. Every photo or image I import has keywords. A presentation image of a clock might have the keywords “presentation, time, clock, timepiece” assigned to it. A photo of my friend Mindy in Boston will have “Boston, Mindy, harbor” attached to it. Using keywords will make the next step, Smart Albums, a lot easier.

3. Use Smart Albums. I’m not a big fan of iPhoto’s Event-based organization. For starters, I hate how events are created by day. I don’t know about you, but the amount of true events (weddings, vacations, etc.) I shoot on an annual basis is minor. Instead I get a lot of onsey-twosie photo events that are a pain to organize. Also, a lot of images for me are multipurpose. Earlier, I mentioned I tag images I might use in presentations, so I’ve got a Smart Album built on the presentation keyword. I don’t like to rely on iPhoto’s Faces and Places intelligence, so I will also build Smart Albums based on areas I shoot a lot; I’ve got albums for Boston, Boothbay, and New York.

You can also use multiple keywords or criteria to create yet more specific albums. For example, you could create a Smart Album of wallpapers with the Apple logo you’ve created in the last year, that also have a ranking of five stars or higher.

4. Keep Events Window Clean. Like I said, most of the photos I take are random shots off my iPhone. My OCD really kicks in when I see events that aren’t events, so I keyword them and move them into a miscellaneous general purpose event. Periodically, I’ll go through that holding bin and, since most of the time my “I don’t know what else to do with this” event really is an “I don’t know why I took this photo” and I’ll purge 99 percent of the images there.

5. Empty the Trash and Purge. iPhoto has a separate trash can from the rest of OS X. Deleting an image won’t immediately delete the file from your hard drive. Instead you need to go in and manually empty the trash. Checking the trash periodically will let you permanently get rid of bad or duplicate photos, and might reveal some lost gems that look much better than you remember.

iPhoto is a great program, but it isn’t yet so perfect that it can’t stand improvement. These small changes take only a little time but add result in a markedly different user experience. Any other iPhoto tips you care to add?

Related content from GigaOM Pro (sub req’d):

• Will Facebook (or Apple) Be the Next Great Hadoop Champion?
• 8 Infrastructure Companies Poised to Make Headlines in 2011
• Mobile 2011: Data Consumption Will Explode

If you ever work at home, you know how important it is to choose the right desk. To prevent discomfort (and potential back problems), it’s really important to choose the right height. Here’s an easy way to do it. More »

Is a particular keyboard shortcut in Mac OS X giving you grief? If you want to remap it to something you’d like better, there’s a handy little setting in System Preferences that can help you out. More »

My (Too?) Many Monitors

First, you need some extra hardware. Obviously, you’ll need two extra monitors, in addition to the one built in to your computer, but that’s not all. You’ll also need to pick up a USB-to-video adapter. These come in many flavors. I’ve got a Sewell USB-to-DVI external video card ($79.95), but another good cheap option is the EVGA UV Plus+ ($69.99 for the UV16). Both options come with DVI-to-VGA adapters, so you can use either type of connection.

One of your monitors should be connected via your Mac’s video-out port (whether it be mini-DVI or Mini DisplayPort, depending on your machine’s age). You can get an adapter for that direct from Apple, or from third-party vendors. That’s the easy part.

Now, connect your other monitor using the USB-to-video device you decided upon. To do this, first install DisplayLink’s Mac OS X drivers. The latest version (1.6 Beta 3 as of this writing) can be found here. Without these drivers, no USB video cards will work with a Mac.

Once you’ve installed the drivers, plug in your second external monitor using the USB video adapter. Your screen should go blue, then extend to your new monitor. Use Displays under System Preferences to make any necessary adjustments.

Note that using DisplayLink to operate a third display with your Mac isn’t perfect. Because of restrictions Apple imposes on OS access for third-party software, the DisplayLink drivers don’t support 3D acceleration or OpenGL, meaning that keynote presentations won’t work properly, and video will be choppy. But if you’re using that third display to house an extra browser window, or even for photo editing, it’s more than up to the task. Plus, you can add up to four additional monitors over USB using this method (though separate adapters would be required).

DisplayLink’s been around for a while, but I remember when I was first testing a multi-monitor solution, it took me longer than it should have to unearth this solution. Hopefully now you won’t have the same problem.

Related content from GigaOM Pro (sub req’d):

• By The Numbers: Running a Coworking Space
• The Internet of Things: What It Is, Why It Matters
• How to Capture Building Management’s Untapped Middle Market

There are three searchable aspects of your app within iTunes. These are your company name, the app name and the hidden keywords field. These all hold equal bearing and don’t affect search order. In other words, if your company name is “Smash House,” by default, your app won’t appear before the app “Smash Brothers” or one that happens to have “smash” in its name. In other words, all apps are treated equal by the search engine.

Space for keywords is limited. Your application name can be a total of 250 characters long, and your keywords list is limited to 100 characters (including spaces or commas). It’s important to note, however, that your keywords section doesn’t need spaces. Each word can be separated with only a comma.

It’s also important to note that iTunes search is exact search: The words placed in the search box by the consumer must all be found in one of your three searchable fields. iTunes will make no assumptions on the part of the consumer. The plural form of a word is a completely separate word than the singular form (kid vs. kids, hero vs. heroes, etc.) and words within words will not be pulled out in search (EA’s apps will not show up in a search for “Each,” for example). It will, however, often recognize slight misspellings or take out unnecessary spaces (a search for Face Book will still result in the Facebook app).

Remember, the single highest percentage of app discovery comes from searching for a specific type of app, which makes learning the nuances of SEO crucial to pushing your app to the front of the crowd.

This is the first post in a three-part series. To learn more about marketing iPhone apps, read Part 2 and Part 3, which will be posted later this week. For an in-depth analysis of app marketing, download the GigaOM Pro report “How to Market Your iPhone App: A Developer’s Guide” (subscription required).

Image Source: flickr user Yutaka Tsutano.

If iTunes 10 is a little too gray and washed out for your eyes, a simple terminal command can up the contrast (maybe a little too much). More »

You can eject from the sidebar in Finder, or from the desktop (dragging to the trash). However, there’s also a third way: a menu bar item. Apple doesn’t show this item by default in Snow Leopard, which led me to try and find a way to enable it. It’s actually fairly easy:

1. Open a Finder window and go to /System/Library/CoreServices/Menu Extras.
2. Double click on Eject.menu and it should appear instantly in your menu bar.

You can move the menu bar item by holding down the Command key and dragging it around. You can also get rid of it by dragging it off the menu bar, where it’ll vanish in a puff of smoke, just like you’d drag an item off the Dock.

Mo’ Power

Back in the EOF days, there was a great little piece of third-party software called EOGenerator that implemented something called the generation gap design pattern. Essentially, this little program would create your custom subclasses of EOGenericRecord (EOF’s equivalent of NSManagedObject) for you. It wouldn’t just create that, though, it would actually create two classes for each entity in your EOModel.

One of these two classes was yours to modify as you saw fit. It would never get overwritten even if you ran the EOGenerator script again, over and over. The other class contained all the generated code derived from your EOModel and was designed not to be touched by the programmer. You had your class, EOGenerator had its class, and you could both work without any fear of stepping on each other’s toes. You could add attributes and entities to your data model and regenerate the machine-readable classes without any chance of losing your custom validation or methods. It was nice.

Wolf Rentzsch has re-implemented this idea for Core Data, and the result is called MOGenerator. If you spend any time with Core Data and aren’t familiar with MOGenerator, go become familiar with it. It will make your life much, much, much better.

SQLite to Check Data

The default persistent store type for Core Data under iOS is a SQLite store, which means that Core Data keeps all of its data inside of a single SQLite database in your application’s /Documents folder. Now, the format of the persistent store is undocumented and you should never, ever, ever, ever, never change data in the persistent store or make any assumptions about how Core Data stores the data. That’s part of why we use Core Data: It’s an abstraction layer that lets us not worry about the underlying storage details.

But, sometimes, it can be really helpful to know whether data is getting into the persistent store or not. I often work on my data model before my user interface, so being able to peek in the data store to make sure all is well is really helpful.

The first thing you might want to consider doing, if you plan to do that, is to create a SQLite config file. This is a file of commands that will execute whenever you launch SQLite. To do that, simply create a file called .sqliterc in your home directory. Here’s what mine looks like:

.mode column.header on.table

In mine, the first line tells SQLite to print the column names when I issue a SELECT command. The second line tells SQLite to present the data in tabular form. The last line prints out a list of all the tables in the database before it shows me the SQL command prompt. That’s handy given that the table names don’t usually exactly match your entity or class names.

Once you have a config file in place, you can open up any persistent store using the sqlite3 command in Terminal.app, like so:

sqlite3 MyApplication.sqlite

You can’t, of course, execute this directly against database files on your phone, but you can do it in the simulator as well as on files copied from your phone using Xcode’s Organizer. If you’re using the simulator, you can look for your SQLite databases at the following location:

/Users/[your account name]/Library/Application Support/iPhone Simulator/[SDK version #]/Applications/[application UUID]/Documents/[Application Name].sqlite

When I log into a database with my SQLite config file, this is what I see:

-- Loading resources from /Users/jeff/.sqlitercZHERO         ZPOWER        Z_METADATA    Z_PRIMARYKEYSQLite version 3.6.12Enter ".help" for instructionsEnter SQL statements terminated with a ";"sqlite>

Notice that it has dumped the names of all my tables. It’s pretty easy to figure out which table holds what data once they’re right in front of you. The example above is the persistent store from the SuperDB application from More iPhone 3 Development. The Hero entity managed objects are stored in ZHERO and the Power entity managed objects are stored in ZPOWER. To look at the contents of a table, you just need to execute a SQL SELECT command. The simplest is just SELECT * FROM TABLENAME;, which prints the entire contents of the table to the console, like so:

sqlite> select * from ZPOWER;Z_PK        Z_ENT       Z_OPT       ZHERO       ZSOURCE     ZNAME     ----------  ----------  ----------  ----------  ----------  ----------1           2           2           1           Mutation    Fire      sqlite> 

The format of the data is pretty easy to figure out but, again, you really should look and not touch. It’d be very easy to accidentally destroy a persistent store. A seemingly inconsequential change could get the metadata out of whack and prevent your app from using the persistent store any more.

Better Descrption

I noticed a few days ago that Wil Shipley was complaining about the fact that many of Apple’s delivered UIKit and Foundation objects have not overridden the -description method. This method is important because it’s the one that is used in format strings, NSLog(), and when you type the po command in GDB. Instead of getting a meaningful description of many delivered objects, you instead get the class name and memory address of the instance, which is what NSObject‘s implementation provides, which isn’t very much help while debugging.

Unfortunately, NSManagedObject is one of the many, many classes that doesn’t have its own meaningful implementation of -description. That doesn’t mean you can’t provide one, though.

One thing you can do is to create an abstract subclass of NSManagedObject and put the -description method there. If you then subclass this abstract class, all of your managed objects will inherit the method from the abstract class. If I have other common functionality, I’ll often do exactly that. But if I don’t (and often you won’t) I personally hate to clutter up my object hierarchy to add debugging tools. So I actually will cheat and do something you’re not really supposed to do, which is override a method using a category. The reason it’s bad to do this is because the Objective-C language does not specify which method should be used, which can lead to unpredictable behavior. But, when a class inherits a method from a superclass, I’ve found that overriding it in a category always works. I’m not suggesting you should do this in a shipping app, however. I wrap my method in pre-compiler definitions so that it doesn’t get compiled into the release version of my application.

My version of -description assumes you’re generating properties for your managed objects (I always do) and also assumes you’re using custom subclasses (but you are, because you’re using MOGenerator, right??). The method iterates over all the properties of the class and all its superclasses up to NSManagedObject, then prints them to the console. The categories I use look like this:

#if DEBUG@implementation NSObject(MCManagedObjectDebug)+ (NSMutableArray *)MCproperties{    NSMutableArray *properties = nil;

    if ([self superclass] != [NSManagedObject class])        properties = [[self superclass] MCproperties];    else        properties = [NSMutableArray array];

    unsigned int propCount;    objc_property_t * propList = class_copyPropertyList([self class], &propCount);    int i;

    for (i=0; i < propCount; i++)    {        objc_property_t oneProp = propList[i];        NSString *propName = [NSString stringWithUTF8String:property_getName(oneProp)];        if (![properties containsObject:propName])            [properties addObject:propName];    }    return properties;}@end

@implementation NSManagedObject(MCManagedObjectDebug)- (NSString *)description{    NSArray *properties = [[self class] MCproperties];    NSMutableString *ret = [NSMutableString stringWithFormat:@"%@:", [self className]];    NSDictionary *myAttributes = [[self entity] attributesByName];

    for (NSString *oneProperty in properties)    {        NSAttributeDescription *oneAttribute = [myAttributes valueForKey:oneProperty];        if (oneAttribute != nil) // If not, it's a relationship or fetched property        {            id value = [self valueForKey:oneProperty];            [ret appendFormat:@"nt%@ = %@", oneProperty, value];        }

    }    return ret;}

@end#endif

The +MCProperties method uses the Objective-C runtime to discover and iterate over properties in the class definition, including @dynamic properties that were created at runtime. Because the property runtime calls do not include properties inherited from parent classes, the method acts recursively, iterating up the object hierarchy until it gets to NSManagedObject. The actual -description method simply prints out each of the attributes and the value currently stored for that attribute for this object instance. Once you do this, if you use NSLog() or po, the result is much richer information about the objects getting printed to the console. This version ignores relationships and fetched properties, but it wouldn’t be hard to add those in if you needed them.

©2008-2010 Jeff LaMarche.
iphonedevelopment.blogspot.com

Windows 7: Everybody knows that you can right-click any application to launch it as administrator, but what you might not know is there’s an even quicker way you can trigger administrator mode. More »

We’ll walk you through how to set up, enable, and tweak all 10 items so you can get the most out of your Mac right from the start.

Below is a sample of the video. The full screencast clocks in at just over 11 minutes.