During an entertaining aside in Andy Ihnatko‘s keynote at this weekend’s Voices That Matter conference, I was reminded of a thought I’d had a while ago: Why don’t Mac desktop applications store their license info in the Keychain?

Complaining about restoring license keys should be just as trite of a humor topic as little bags of peanuts on flights, but it still holds true. Go to restore a machine, or move to a new one with a clean install, and you can write off at least an afternoon launching and entering at least two text fields per application.

Maybe I’m the only one who feels quite comfortable with syncing to MobileMe–I actually consider it the feature that keeps me coming back. (I do know there are people who have frustrating issues, and I truly feel for them, but I continue to believe they are in the minority.) Given that setup, here’s how I’d see setting up a new laptop:

1. Configure my MobileMe account and sync down the data, setting up my Mail accounts, Address Book and Calendar–and Keychain.
2. Launch a new copy of my licensed application.
3. There is no Step Three. Go on your merry way.

I’m not expert enough to suggest that it would improve security of your key, but it sure would discourage casual tweaking more than the plist or hidden file schemes you’d need to develop on your own. Also, separation of license key from a preferences file (hopefully developers are already doing this) allows a user to delete the preferences and start fresh without having to worry about relicensing.

I understand that Keychain development can be convoluted, but is that reason enough to not make the user’s life a little bit easier and your support burden of finding a lost license a little less frequent?

As I said at the top, I realize I’m talking out of my…hat here. I don’t have experience doing this (yet), so I am interested in hearing reasoned arguments. Until and unless this is proven untenable, simply consider it a feature request for your next release.

At some point, after I’d explained a few times why you have to write software this way on Android, I started wondering why all software, without exception, isn’t written this way by default.

As of 10.6, Apple added enableSuddenTermination and disableSuddenTermination calls to the NSProcessInfo API to allow you to implement similar behavior on the desktop. At its most simplistic description, you can inform the system your application doesn’t need to have its memory paged back in just to destroy it all–just kill the process and you will be sure it behaves properly on relaunch.

I encourage all fellow iOS developers who have already acquired a “sudden termination” design style to make note of this when developing a desktop Cocoa application; I also encourage desktop Cocoa developers to start thinking about how they would design with this paradigm, as it will be one more portable technique when and if you decide to go mobile.

(NSCache and Purgeable Memory is another new-to-10.6 mechanism I consider similar to iOS’ didReceiveMemoryWarning, only giving the OS permission to purge memory instead of it requesting you clean up.)

Download the Corporation Unknown configuration for Accessorizer.

At a previous employer, we ran into issues where newcomers were confused by Objective-C’s memory management, especially the differences between using properties (and dot notation) and directly accessing the ivar. As you might expect, this led to many memory-related problems. I’ve long been a proponent of only using accessors to access a member unless you have a darn good reason. (And Cocoa’s ? automatic key-value observing makes it even more difficult to have a good reason not to.) In order to visibly identify accessor-vs-direct access, we instituted a naming convention to make direct access look wrong: ivars are named with an underscore prefix (“_ivar”) and properties are not. To make this even more obvious that ivars are implementation details, we declared them @private.

You may disagree with this methodology; that’s fine. But without this context, you might have a hard time understanding my configuration decisions–and why Accessorizer especially rocks in this setup.

When I first started using Accessorizer, I thought of it as a code generator, and it’s hard not to chafe at your disagreements with how code generators generate code. I’ve found that thinking of it as a code template generator makes it easier: Generate the majority of stuff you use, omit the stuff you don’t normally use, and be comfortable with the knowledge that you will regularly have to tweak its output–it’s still better than writing it from scratch every time.

Accessor Style

• “ObjC 2.0 Properties” is always turned on. Period.
• I always use the Defaults Table (more about that later).
• “Detect IBOutlets” automatically inserts the “IBOutlet” declaration into recognized subclasses. Sometimes it doesn’t identify a class I want to be an IBOutlet, but I find this to be right much more often than it is wrong.
• “Append self.view=nil” is a somewhat strangely worded option. Checking it will generate code to nil those properties identified as IBOutlets. Combined with the “-(void)viewDidUnload” checkbox to its right, it will generate a full viewDidUnload method to release your IBOutlets.
• “Assign delegates” automatically overrides your assign/retain/copy property generation setting to be “assign” for any “id” property (or others identified as a delegate form; again, I find more often right than wrong).
• I uncheck “Omit assign for scalars”. True, the “assign” is not necessary, but I find it easier to scan for “assign” when I’m code reviewing than have to think about each type and whether it is handled appropriately. (According to Apple’s documentation, “assign” is also required for garbage collection but I haven’t written any GC code yet.)
• “Assign IBOutlets” is unchecked. I guess I’m still in the “retain outlets” camp, until I bother to change my mind.
• “BOOL getter=isValue” automatically identifies a “BOOL running” property and defines the getter as “isRunning”, just as Apple recommends.

• Since I’ve primarily been coding for iOS lately, I declare my properties “nonatomic”. If/when you’re working on the desktop, you probably want “omit this”–change it or create a “desktop” configuration.
• I omit readonly/readwrite. Most of the readonly properties I create are not backed by ivars, so I find I don’t need to override this behavior often.
• I haven’t been much concerned about __weak or __strong, so I omit it. You may decide otherwise.
• “@synthesize” will create appropriate @synthesize statements when generation the Implementation. (Be sure to check “generate getter/setter”, even though it applies to @dynamic–I’ll explain later when talking about Defaults Table.)

Getter/Setter settings

Not much to say about these settings other than “Use Defaults Table”. They don’t come into play very often, since I mainly use @synthesized properties but these settings work for me when I don’t. To see the effects on generated code, temporarily switch your properties generation to @dynamic with “generate getter/setter” checked and Implementation being generated–changes will be reflected as you make them.

Dealloc

• I default to “self.property = nil” behavior; I know others disagree. If you’re one of them, simply change the option to “release” in your configuration. If you do agree, or simply want to give this way a try, make a point of removing any related KVO or NSNotification observers before these generated lines or you will receive notifications of the nil settings and you most likely don’t want that.
• “dealloc full block” is the primary reason I am not just making my configuration available without comment. If you were to just take my configuration and copy the generated code, it would break your build because I leave this deselected so it’s not in a code block. As I develop my classes, I add ivars and use Accessorizer to generate the related code. Most of the code is pretty easy to wholesale copy-n-paste, but I tend to have more logic in dealloc than Accessorizer can know about (KVO and NSNotification removal, setting delegates to nil, etc.) and I find it easier to copy this generated dealloc code into an existing method than to use this as a dealloc method and move existing behaviors into it. If you want a full dealloc method, just check the box.

Init and Undo

I’m not sure why, but I still tend to write my own init methods. Someday I’ll explore using Accessorizer for this and Undo registration more fully; until then, you’re on your own.

Defaults Table

The defaults table is used to override the “one size fits all” property generation based on the ivar’s type. I have configured every superclass of “NSMutable<Something>” to default to “copy” instead of the default “retain” in order to avoid holding reference to a mutable object when I’m expecting immutable. (This is explained in Apple’s documentation.) I don’t even use some of these classes, but when I do I don’t want to be surprised. I’m always free to edit the declaration on a case-by-case basis, but this is the behavior I want ninety-some percent of the time.

Another fun feature of the Defaults Table is the “generation” setting. If you have a class type whose behavior you tend to override often, define its generation as “dynamic”. Every time you use that class type, Accessorizer will generate an @dynamic declaration–and the accessor methods for you to use as a starting template. (This is why I check the “generate getter/setter” in the Accessor tab even though it normally won’t do anything.)

Custom Table

I don’t really use this tab, and I don’t believe any of it gets saved into a configuration set since it’s primarily for point-and-click tweaking of behavior on an ivar-by-ivar basis.

Coding Style

As I mentioned, I prefix my ivars with an underscore, so here is where I define that. By defining my ivar Prefix as “_” and Suffix as “none”, Accessorizer automatically recognizes that underscore and strips it when declaring the property. It also properly declares the backing ivar in the @synthesize directive.

• The Argument Prefix is used when generating methods like -initWith{…}. I vacillate between “a” and “none”.
• Formatting Properties: new to 2.0 is the ability to tweak whitespace in declarations more than you could in previous versions. I’m happy because now I can use my preferred “NSString* title” form; I know many others still hew to the “asterisk must bind the the variable, not type” but you’re free to change it for yourself.
• Formatting Methods: Configure the display to generate some accessor methods and experiment with these settings to see which layout you prefer. The “Tight” spacing option is actually more compressed than I like, but I find the “Spaced” option way too spread out (and I’m someone who loves whitespace). Therefore, I default to “Tight” because it’s easier to insert the few spaces I prefer than delete all the ones I don’t.
• Formatting Pragma Marks: I love me some pragma marks, but try not to go overboard with them. Feel free to experiment.
• Init Style: Apparently, “self = [super init]” is the current Apple-approved format. I’m ambivalent.

Collection Accessors, Keyed Archiving, KVO, Locking, Singleton, General and Sort

Most of these tabs are more hands-on generation of code. You need to enter a class name, and it will generate code right there–I don’t use these as frequently as accessor generation, and you can tweak the layout more directly when you do need it. At some point, I may have changed my settings from the defaults you would encounter in a new install, but I don’t really have strong suggestions for you here.

1. As its name suggests, it will generate the getters and setters for ivars you point it at. It will do this using Objective-C 2.0 @property syntax if you specify it. (I use the 2.0 syntax and revert when I want to customize a getter or setter so i can start with a “standard” usage style.)
2. Automatically recognize UIKit and AppKit classes and mark the properties as IBOutlets.
3. Recognize non-object ivars and set their properties as “assign” instead of “retain”.
4. You can configure defaults for ivar classes (all my NSString and NSData properties default to “copy” instead of “retain”).
5. Generate all the methods for collections to be nicely Key-Value Observing compliant.
6. Generate Keyed Archiving and Unarchiving methods for your ivars.
7. Generate template code for a Singleton class.

That’s really just scratching the surface, but it’s the main functionality I use. As a Cocoa developer, you truly do owe it to yourself to check it out.

What makes me (rather selfishly) consider 2.0 an awesome update, though, is a feature I requested: Configuration Sets. The request grew partly out of encountering co-workers at contracting gigs who didn’t use Accessorizer. There are so many items to customize in the application, a first use could be daunting. If I can say, “Here’s my configuration to get you started,” and pass along my exported Configuration, they’re more likely to use it. (It also helps that they can now feel confident that they can revert after experimenting with settings.)

If I’m working on multiple projects with multiple clients, I can save their specific formatting requirements and switch between Configuration Sets when I change between projects.

If your company has defined formatting standards for the aspects Accessorizer can generate, standardizing with a Configuration Set allows you to quickly bring a new team member up to speed and into compliance.

There are more aspects to Configuration Sets I’d like to see, but they fall on the “magical” end of the spectrum; Kevin has done a great job of implementing the (more than) 80% part of it.

Seriously: Why aren’t you using Accessorizer?

- (IBAction) sliderChanged:(id)sender;

For the iPhone, you can even define it without the sender if the method won’t use it:

- (IBAction) sliderChanged;

The annoyance comes when implementing the method–that generic id parameter needs to be cast to the class you usually already know it to be, resulting in either casts all over:

- (IBAction) sliderChanged:(id)sender {
   int progressAsInt = (int)([(UISlider*)sender value] + 0.5f);
   float minValue = [(UISlider*)sender minimumValue];
   float maxValue = [(UISlider*)sender maximumValue];
}

or the use of a local variable whose sole purpose is to hold the pre-cast parameter:

- (IBAction) sliderChanged:(id)sender {
   UISlider* slider = (UISlider*)sender;
   int progressAsInt = (int)([slider value] + 0.5f);
   float minValue = [slider minimumValue];
   float maxValue = [slider maximumValue];
}

Clean it up

The key to cleaning up your IBActions lies in Objective-C’s behavior of treating all objects as id at heart: Declaring a type for an object is really only beneficial to you at compilation time, warning you of possible mistyping. (It also enables autocompletion.) But that’s not a limitation, it’s something to leverage!

When you know the single class (or superclass of the family of classes), declare it in the method signature:

- (IBAction) sliderChanged:(UISlider*)slider {
   int progressAsInt = (int)([slider value] + 0.5f);
   float minValue = [slider minimumValue];
   float maxValue = [slider maximumValue];
}

If you’re one of those (crazy) people who call the action method in code, you will now be warned when trying to pass an unexpected control (e.g. a UISwitch instead of UISlider).

Added bonus: By declaring the action with a specific parameter type in the header, Interface Builder will use that information to filter available connections. Not only will you have a shorter list of actions to choose from when connecting, you won’t even be allowed to accidentally connect a UISwitch to an action expecting a UISlider.

Note: If you do clean up actions in this way for existing projects, verify your nibs afterward. Interface Builder will display a warning icon in the lower right corner of the nib window, but the CompileXIB build phase is not configured to generate these warnings by default.

After cleaning out large copyrighted material (part of a Justin Timberlake song on the title screen and a Star Wars snippet on the XQuery screen) and removing many of the Keynote build animations I like to use but which translate poorly to static images, I have made the presentation available. I didn’t record the audio, so the text may seem more terse than it really was.

• HTML export with most of the animations still intact
• Zipped archive containing:
  • Keynote 09 file
  • PDF export
  • XMLDemo source serving as the examples I showed

But the latest post by Glen Aspeslagh describes Ecamm Network’s usage of a project which seems to deserve increased exposure: Cocotron, “an open source project which aims to implement a cross-platform Objective-C API similar to that described by Apple Inc.’s Cocoa documentation.” Or, as glibly summarized by the Ecammeratus: “Wrote a Cocoa app? Just add a new Xcode target, hit compile and out shoots a Windows version.”

Sure, it doesn’t work perfectly, but Glen’s warts-and-all description sounds promising. If you have a product that could benefit from a Windows equivalent please give Cocotron a look and contribute code–so it will be easier for me to use when I come up with a product that could benefit from it.

Previously, you would add frameworks to the Files panel by selecting the “Existing Frameworks…” item from the “Add” contextual menu, or the “Add to Project…” item of the top Project menu. (These methods are still available in Xcode 3.1.)

Both options bring up a file dialog, allowing you to choose your framework from /System/Library/Frameworks or an SDK subdirectory or anywhere else on your computer. Because of the numerous copies of system frameworks, I have never been completely confident that I’m choosing the correct copy of the framework and won’t run into some really frustrating compatibility bug.

Since Xcode 2.5, Apple has been working to make SDKs more self-contained and swappable. Xcode 3.1 has even added an “Active SDK” submenu next to Active Configuration, Target, Executable and Architecture–you can now dynamically swap between SDK frameworks, but you must avoid the file selection dialog path for frameworks to swap between SDKs.

To use the new method, choose the desired Target (not File Group) and select “Existing Frameworks…” from the “Add” contextual menu. In 3.0 this will give you the same file dialog as before, but in 3.1 it will bring up the Target’s Get Info panel to the General tab. The bottom portion of this pane shows the Target’s Linked Libraries. Clicking the “+” button beneath the list will bring up a list of known frameworks for the active SDK.

Choose from the list and you will not only gain the confidence that you have selected the appropriate version of the framework for your current SDK, but Xcode will be as smart as it can about automatically selecting the appropriate version of the framework if and when you target a different SDK.

(You can also get to this panel by double-clicking the Target, or selecting “Get Info” from the Target’s contextual menu, then selecting the General tab–it’s just more direct from the Existing Frameworks contextual menu item.)

	hand : palm :: foot : sole

you would break out each of the replaceable elements into separate strings and replace them in the format string with the placeholder ‘%@’. (There are many other format specifiers–look up printf()–but ‘%@’ is very common in Cocoa since it specifies an Objective-C object, not just a simple number or C null-terminated string.)

	NSString * format = @"%@ : %@ :: %@ : %@";

To create the desired string:

	NSString * myString =
	   [NSString stringWithFormat:format,
	                              @"hand",
	                              @"palm",
	                              @"foot",
	                              @"sole",
	                              nil];

If you want to create a different analogy string, just call stringWithFormat: again, using the same format string but different parameters following it.

The stringWithFormat: method takes a list of objects, and the nil parameter indicates the end of the list. If you want to manage the list of substitution parameters, though, you shouldn’t need that nil since NSArray knows how many elements it contains. Unfortunately, there isn’t a method like stringWithFormat: which takes an NSArray instead of a list of objects; there also doesn’t seem to be a simple way to convert the contents of an NSArray to a nil-terminated parameter list.

How then can you make this templating more dynamic at runtime by storing the list in an NSArray?

If you wanted to promote the list to an NSArray, your first attempt might look like:

	NSArray * analogy =
	   [NSArray arrayWithObjects:@"hand",
	                             @"palm",
	                             @"foot",
	                             @"sole",
	                             nil];
	NSString * myString =
	   [NSString stringWithFormat:format, analogy];

As someone currently working in Perl, that is the idiom I would like to see, but trust me, this doesn’t work. If you’re lucky, you get the value of [analogy description] in the first placeholder and nothing (or garbage) in the rest–but usually you will just crash hard.

You could do a bunch of [string appendWithFormat:] calls, adding one element at a time, but that obscures the desired output in the code, and ties you to the position of elements in the array: With a format, you can flip the analogies with a format string of @”%3$@ : %4$@ :: %1$@ : %2$@” and that’s a very powerful piece of functionality which should not be readily tossed aside.

I searched the web for help; there are a number of instances of this question of “how can I use NSArray with stringWithFormat:?” but no solution. So I started dredging up almost-forgotten memories of ANSI C, and found something that works. For a single stringWithFormat-for-NSArray invocation:

	// allocate a C array with the same number of elements as array
	id args[ [analogy count] ];
	NSUInteger index = 0;
	// copy the object pointers from NSArray to C array
	for ( id item in analogy ) {
	   args[ index++ ] = item;
	}

	NSString * myString =
	   [[NSString alloc] initWithFormat:format
	                          arguments:(va_list)args];

(As much as I dislike casts, I dislike compiler warnings even more: The cast to (va_list) appears to be safe in this case and eliminates the warning of “warning: passing argument 2 of ‘initWithFormat:arguments:’ from incompatible pointer type.”)

Note that this solution uses initWithFormat:arguments: instead of the more common stringWithFormat: or even initWithFormat:–this technique only works when passing the format and arguments separately. Be aware, then, that this is not an autoreleased object–you will be responsible for releasing the resultant string.

This technique does have a couple drawbacks:

• You can’t use primitives as arguments. Then again, NSArrays only hold objects, not primitives, so that turns out to be a non-issue.
• There seems to be no way to pre-flight the format string and ensure there are enough arguments. This isn’t any more problematic than mismatched argument lists built at compile time, but the flexibility of using an NSArray may increase the likelihood of mismatch instances.
• Even though it would seem reasonable to assume so, I see no guarantees that the memory layout of an array will always match that of passed parameters. This has been tested on 32-bit PPC and Intel, but not 64-bit.

But it also has the advantage of being able to use a well-known powerful syntax, without having to create yet another templating language (yet).

Now you finally have the flexibility to apply a choice of format strings to multiple objects. If you have a list of analogy “objects” to print out:

	NSArray * analogies =
	   [NSArray arrayWithObjects:
	      [NSArray arrayWithObjects:@"hand",
	                                @"palm",
	                                @"foot",
	                                @"sole",
	                                nil],
	      [NSArray arrayWithObjects:@"color",
	                                @"spectrum",
	                                @"tone",
	                                @"scale",
	                                nil],
	      [NSArray arrayWithObjects:@"lawyer",
	                                @"courtroom",
	                                @"gladiator",
	                                @"arena",
	                                nil],
	      [NSArray arrayWithObjects:@"frugal",
	                                @"miserly",
	                                @"confident",
	                                @"arrogant",
	                                nil],
	   nil];
	NSArray * formats =
	   [NSArray arrayWithObjects:
	      @"analogy: %@ : %@ :: %@ : %@",
	      @"reverse: %3$@ : %4$@ :: %1$@ : %2$@",
	      @"as text: '%@' is to '%@' as '%@' is to '%@'",
	      nil];

	for ( NSArray * analogy in analogies ) {
	   id args[ [analogy count] ];
	   NSUInteger index = 0;
	   // copy the object pointers from NSArray to C array
	   for ( id item in analogy ) {
	      args[ index++ ] = item;
	   }

	   // print this analogy with multiple formats
	   for ( NSString * format in formats ) {
	      NSString * myString =
	         [[NSString alloc] initWithFormat:format
	                                arguments:(va_list)args];
	      NSLog( @"%@", myString );
	      [myString release];
	   }
	}

There you go. Now feel free to throw it into your own method, or create a category on NSArray to allow you to write code like:

	for ( NSArray * analogy in analogies ) {
	   for ( NSString * format in formats ) {
	      NSLog( @"%@", [analogy myStringWithFormat:format];
	   }
	}