We all know how to define an IBAction:
- (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.
