Is it reasonable to isolate iPhone/iPad event handlers in separate .m files and then #import them in the viewcontroller @implementation?

Total newbie here on iPhone/iPad development, so forgive me if 开发者_如何学运维this seems like a strange question.

Given that most objects (or group of objects) in a view within a UIViewController need to have an event callback defined, would it seem reasonable to group the callbacks into separate .m files and then #import them after the @implementation of the viewcontroller?

This way, the standard methods, initWithNibName:, -viewDidLoad, shouldAutoRotateInterfaceOrientation:, didReceiveMemoryWarning:, -viewDidUnload and dealloc (as provided by Xcode) would be the only methods defined in your viewcontroller.m file. The viewcontroller.m file would not become this monolithic monstrosity of event callbacks and would be simpler to maintain. I'm thinking you put them after your @synthesize outlets.

Thoughts?

While it may seem like you are making a monolithic file, the ViewController is really the place for all of this stuff. If you do what you propose (which is entirely possible), you will end up with a bunch of files that do little.

One way to keep organized in a large file is to separate groups of methods with pragma marks like so:

#pragma mark lifecycle methods

-(void)dealloc{}
-(id)init{}
-(id)initWithCoder:

#pragma mark target-action

-(id)doSomethingAction:(id)sender{}
-(id)doSometingElse:(id)sender{}

Xcode will parse the pragma marks and group the methods for you in the pull down item bar for easy access. Notice that the methods in this list are also listed in alphabetical order.

here's an illustration of one alternative, this uses an objc category:

/* File: Header A */
@interface MONViewController : NSViewController
{
    unsigned anIvar;
}

@property (nonatomic, readonly) unsigned anIvar;

- (id)initWithNibName:(NSString *)nibName bundle:(NSBundle *)bundle;
- (void)dealloc;

- (void)viewDidLoad;
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation;

/* (continued) */

@end

/* File: Header A or Header B, depending on how you want to organize it */

@interface MONViewController (EventCallbacks)

- (IBAction)triviaButtonWasPressed:(id)sender;

/* (continued) */

@end

/* File: Imp A */
@implementation MONViewController

- (id)initWithNibName:(NSString *)nibName bundle:(NSBundle *)bundle { /* ... */ }
- (void)dealloc { /* ... */ }
- (unsigned)anIvar { /* ... */ }

- (void)viewDidLoad { /* ... */ }
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation { /* ... */ }

/* (continued) */

@end

/* File: Imp A or Imp B, depending on how you want to organize it */

@implementation MONViewController (EventCallbacks)

- (IBAction)triviaButtonWasPressed:(id)sender { /* ... */ }

/* (continued) */

@end

fortunately, the compiler verifies that you've defined all your declarations when a category is defined, as is performed in a class. some things must be defined in the proper class implementation, such as protocols.

be careful if you divide this into a ton of smaller files - your build times can really suffer. also, it's somewhat inevitable in this case (since your subclassing) but scalability issues in this regard should serve as reminders that your interfaces/classes are attempting to do too much, and should be divided into smaller components. good luck!

The issue I see with separating them out is that most of the callbacks will have to work with class local variables, and it's just handier to have them declared in the corresponding header file for the @implementation you are working with. To me it makes more sense to keep event handling stuff in the view controller, and move any other functionality left out into some separate file...

But anything you break out may have to use the same class instance variables as well, meaning that you may have to make some class variables public you might not otherwise.

The category breakout Justin presented solves that issue but to me, using class instance variables you cannot technically "see" just seems weird.