Целесообразно ли изолировать обработчики событий iPhone / iPad в отдельных файлах .m, а затем импортировать их в viewcontroller @implementation?

Question

Абсолютно новичок в разработке iPhone / iPad, так что простите, если это кажется странным вопросом.

Учитывая, что большинство объектов (или группа объектов) в представлении в пределах UIViewController должны иметьОпределен ли обратный вызов события. Было бы разумным сгруппировать обратные вызовы в отдельные файлы .m, а затем #import их после @implementation viewcontroller?

Таким образом, стандартные методы, i nitWithNibName:-viewDidLoad, shouldAutoRotateInterfaceOrientation:, didReceiveMemoryWarning:, -viewDidUnload и dealloc (как предусмотрено Xcode) будут единственными методами, определенными в вашем файле viewcontroller.m.Файл viewcontroller.m не станет этим монолитным чудовищем обратных вызовов событий и будет проще в обслуживании.Я думаю, что вы положили их после ваших @synthesize торговых точек.

Мысли?

Answer 1

вот иллюстрация одной альтернативы, в которой используется категория objc:

/* 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

к счастью, компилятор проверяет, что вы определили все ваши объявления при определении категории, как это выполняется в классе. некоторые вещи должны быть определены в правильной реализации класса, такие как протоколы.

будьте осторожны, если вы разделите это на тонну более мелких файлов - время вашей сборки действительно может пострадать. Кроме того, это несколько неизбежно в этом случае (с учетом вашего подкласса), но проблемы масштабируемости в этом отношении должны служить напоминанием о том, что ваши интерфейсы / классы пытаются сделать слишком много, и должны быть разделены на более мелкие компоненты. удачи!

Answer 2

Проблема, которую я вижу с их разделением, состоит в том, что большинство обратных вызовов должно работать с локальными переменными класса, и просто удобнее объявить их в соответствующем заголовочном файле для @implementation, с которым вы работаете.Для меня имеет больше смысла хранить вещи обработки событий в контроллере представления и перемещать любые другие функции в отдельный файл ...

Но все, что вы выделяете, может использовать те же самые переменные экземпляра классаКроме того, это означает, что вам, возможно, придется сделать некоторые переменные класса общедоступными, в противном случае вы могли бы не делать этого.

Представление категории, представленное Джастином, решает эту проблему, но для меня использование переменных экземпляра класса, которые вы не можете технически "увидеть", просто кажется странным.

Answer 3

Хотя может показаться, что вы делаете монолитный файл, ViewController действительно является местом для всего этого.Если вы делаете то, что предлагаете (что вполне возможно), вы получите кучу файлов, которые мало что делают.

Один из способов сохранить организацию в большом файле - разделить группы методов с помощью прагматических отметок.вот так:

#pragma mark lifecycle methods

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

#pragma mark target-action

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

Xcode проанализирует прагма и сгруппирует методы для вас в выпадающей панели элементов для быстрого доступа.Обратите внимание, что методы в этом списке также перечислены в алфавитном порядке.