Objective C. Практика. События

Событийно-ориентированная логика в Objective C держится на трех китах — протоколы, notification center и key-value observing. Традиционо протоколы используются для расширения функционала базовых классов без наследования, key-value observing – для взаимодействия между визуальной и логической частью приложения, а notification center — для обработкий событий пользователя.

Естественно, все это благообразие можно спокойно использовать для построения сложных приложений. Никакой реальной необходимости в изобретении собственных велосипедов, конечно же, нет. Однако мне, как человеку пришедшему в разработку Objective C приложений из мира .NET, показалось очень неприятным то, что notification center, который я планировал использовать для событий, разраывает стек приложения, записывая произошедшее событие в очередь в UI thread, а протоколы в классическом представлении не слишком удобны, посему для удобства я решил соорудить себе механизм, который был бы гораздо больше похож на то, чем мы привыкли обходиться в мире .NET. Так родился родилась идея реализации модели множественных подписантов через специальный класс, названный AWHandlersList.

Данная статья рассчитана на программистов, которые имеют определенный опыт в создании приложений на Objective C и уже писали подобные велосипеды, либо решали похожие задачи стандартными способами. Данный вариант не является silver bullet, но показал себя как удобный механизм, минимизирующий написание кода для обарботки множеств событий с разными интерфейсами и параметрами.

Идея класса довольно проста — он содержит в себе список подписантов, каждый элемент которого состоит из двух компонентов — target и selector.

Для чего создан этот велосипед? Мне показалось, что он удобнее, чем все представленные стандартные модели, для некоторой логики, связанной с передачей событий. Может быть, он кому-то поможет облегчить жизнь.

В .NET привычная модель событийной логики предлагает делегат с двумя параметрами — sender типа object и args типа, наследуемого от EventArgs. Чтобы не ломать себе мозг, сделаем то же самое. Для начала, определим пустой класс EventArgs, от которого будут наследоваться все аргументы событий.

@interface AWEventArgs : NSObject  @end

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

@interface AWEventHandler : NSObject { 	@private 	NSString *_description; }  @property (nonatomic, assign) id target; @property (nonatomic, assign) SEL method;  +(AWEventHandler *)handlerWithTarget:(id)target method:(SEL)method;  @end  @implementation AWEventHandler  @synthesize method, target;  -(id)initWithTarget:(id)t method:(SEL)m; { 	self = [super init]; 	if(self) 	{ 		target = t; 		method = m; 		_description = [[NSString alloc] initWithFormat:@"EventHandler, Target=%@, Method=%@", NSStringFromClass([target class]), NSStringFromSelector(method)]; 	} 	return self; }  -(NSString *)description { 	return _description; }  -(void)dealloc { 	[_description release]; 	 	[super dealloc]; }  +(AWEventHandler *)handlerWithTarget:(id)target method:(SEL)method { 	AWEventHandler *handler = [[[AWEventHandler alloc] initWithTarget:target method:method] autorelease]; 	return handler; }  @end

Как видите, и target, и method по сути представляют собой слабые ссылки. Это вполне закономерно — слабые ссылки повсеместно используются в мире Objective C для того, чтобы избежть circular references и дать возможность автоматически освобождать объекты. К сожалению, это приводит к тому, что при небрежном кодировании повсеместно появляются «мертвые» указатели на объекты, которые роняют приложение, поэтому я чуть дальше покажу один красивый механизм, который позволяет предупреждать и устранять их появление.

Теперь, наконец, перейдем к нашему основному классу — списку подписантов. В коде есть нетривиальные моменты, но они решаются чтением документации, а если желания разбираться в вопросе нет — то его можно просто использовать, код полностью рабочий и вынут из «боевого» проекта.

@interface AWEventHandlersList : NSObject { 	NSMutableArray *_handlers; }  @property (nonatomic, copy) NSString *name;  -(void)addReceiver:(id)receiver delegate:(SEL)delegate; -(void)removeReceiver:(id)receiver delegate:(SEL)delegate;  -(void)clearReceivers; -(void)invoke; -(void)invokeWithSender:(id)sender; -(void)invokeWithSender:(id)sender args:(AWEventArgs *)event;  @property (nonatomic, retain) NSRunLoop *runLoop;  @end

Вкратце поясню, зачем нужны поля данного класса.

Первое — это name. Я предпочитаю именовать события, чтобы можно было увидеть в логах, какое именно событие было вызвано. Обычно в качестве имени события я использую имя класса вкупе с именем вызываемого в нем для выбрасывания (raise) метода. Это удобная практика, так как позволяет не рыскать судорожно по стеку в поисках того, кто событие выбросил, а просто в консоли отладки посмотреть это значение.

Методы addReceiver и removeRecevier логичны — они принимают объект и селектор, которые в дальнейшем будут принимать вызовы.

Методы invoke должны выбрасывать событие, передавая его для обработки в подписанные объекты. Они даются в трех вариантах — для того, чтобы не передавать пустые значения nil в том случае, если в каикх-то параметрах события нет нужды.

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

Наконец, свойство runLoop необходимо в том случае, если вы собираетесь делать так, чтобы некоторые события были привязаны к определенному потоку (thread). Например, это необходимо, если существует какой-то код в worker thread должен обновлять визуальную часть приложения, либо наоборот — из UI thread должен быть доступ к какому-либо worker thread, синхронизируемому через очередь сообщений, то есть если есть необходимость выбрасывать события и обрабатывать их в разных потоках.

Реализация класса идейно тривиальна, однако требует некоторого понимания того, как работают селекторы. Сложные моменты я проясню в комментариях в самом коде.

@implementation AWEventHandlersList  @synthesize runLoop = _runLoop;  @synthesize name = _name;  -(id)init { 	self = [super init]; 	if(!self) 		return nil; 	 	_handlers = [[NSMutableArray alloc] init]; 	 	return self; }  -(void)addReceiver:(id)receiver delegate:(SEL)delegate { 	/* Этот код можно убрать, если вы гарантируете, что каждый объект будет подписываться на событие только один раз, либо 	 * вам необходимо множественное подписание. Я предпочитаю работать со страховкой */ 	[self removeReceiver:receiver delegate:delegate];   	[_handlers addObject:[AWEventHandler handlerWithTarget:receiver method:delegate]]; }  -(void)removeReceiver:(id)receiver delegate:(SEL)delegate { 	/* В идеале снятие копии со списка, сделанное для поддержки многопоточности, должно производитсья в критической секции 	 * (NSLock), однако я опустил этот момент, как как у меня подписание на события всегда происходит в одном потоке,  	 * а копия списка берется для того, чтобы в будущем достаточно было обернуть вызов в NSLock */ 	for(AWEventHandler *handler in [[_handlers copy] autorelease]) 		if(handler.method == delegate && handler.target == receiver) 			[_handlers removeObject:handler]; }  -(void)clearReceivers { 	[_handlers removeAllObjects]; }  -(void)invoke { 	[self invokeWithSender:nil args:nil]; }  -(void)invokeWithSender:(id)sender { 	[self invokeWithSender:sender args:nil];	 }  -(void)invokeWithSender:(id)sender args:(AWEventArgs *)event { 	[self invokeWithSender:sender args:event runLoop:_runLoop]; }  -(void)invokeWithSender:(id)sender args:(AWEventArgs *)event runLoop:(NSRunLoop *)runLoop { 	/* Вс случае, если к текущему потоку не привязан цикл выборки сообщений, метод вернет null и выполнеие будет 	 * происходить по обычному сценарию */ 	if(!runLoop) 		runLoop = [NSRunLoop currentRunLoop]; 	 	NSUInteger order = 1; 	NSArray *handlersCopy = [NSArray arrayWithArray:_handlers]; 	for(AWEventHandler *handler in handlersCopy) 		if(runLoop == [NSRunLoop currentRunLoop]) 			[self internalInvoke:[NSArray arrayWithObjects:handler, sender == nil ? [NSNull null] : sender, event == nil ? [NSNull null] : event, nil]]; 		else 			[runLoop performSelector:@selector(internalInvoke:) target:self argument:[NSArray arrayWithObjects:handler, sender == nil ? [NSNull null] : sender, event == nil ? [NSNull null] : event, nil] order:order++ modes:[NSArray arrayWithObject:NSDefaultRunLoopMode]]; }  /* Передача объектов производится через массив для возможности работы с потоками через performSelector:target:argument:order:modes: */ -(void)internalInvoke:(NSArray *)data { 	AWEventHandler *handler = [data objectAtIndex:0]; 	 	id sender = [data objectAtIndex:1]; 	if(sender == [NSNull null]) 		sender = nil; 	 	id args = [data objectAtIndex:2]; 	if(args == [NSNull null]) 		args = nil; 	 	/* Данный класс используется для анализа сигнатуры метода и определения потребного числа параметров его вызова */ 	NSMethodSignature *mSig = [handler.target methodSignatureForSelector:handler.method]; 	if([mSig numberOfArguments] == 2) 		[handler.target performSelector:handler.method]; 	else if([mSig numberOfArguments] == 3) 		[handler.target performSelector:handler.method withObject:sender]; 	else if ([mSig numberOfArguments] == 4) 		[handler.target performSelector:handler.method withObject:sender withObject:args]; 	else 		@throw [NSException exceptionWithName:@"Invalid selector type" reason:@"This type of selector is not supported" userInfo:nil]; }  -(void)dealloc { 	self.name = nil;  	[self clearReceivers]; 	[_handlers release];  	[super dealloc]; }  @end

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

#define DEFINE_EVENT(eventName) \ 	-(void)add ## eventName ## Handler:(id)receiver action:(SEL)action; \ 	-(void)remove ## eventName ## Handler:(id)receiver action:(SEL)action   #define DEFINE_EVENT_IMPL(eventName, innerVariable) \ 	-(void)add ## eventName ## Handler:(id)receiver action:(SEL)action \ 	{ \ 		[innerVariable addReceiver:receiver delegate:action]; \ 	} \ 	\ 	-(void)remove ## eventName ## Handler:(id)receiver action:(SEL)action \ 	{ \ 		[innerVariable removeReceiver:receiver delegate:action] ; \ 	} \

Теперь для того, чтобы создать в классе событие, нужно определить внутреннюю списочную переменную:

AWEventHandlersList *_handlers;

Определить событие в интерфейсе

DEFINE_EVENT(Event);

И связать список с событием

DEFINE_EVENT_IMPL(Event, _handlers)

В классе автоматически добавляются два метода — addEventHandler:action: и removeEventHandler:action:, а вызвать событие можно через методы invoke объекта _handlers.

Конечно, не стоит забывать о том, что объект _handlers нужно инициализировать в конструкторе

_handlers = [AWEventHandlersList new];

И уничтожать в деструкторе объекта

[_handlers release];

Во второй части статьи я расскажу, к каким проблемам ведет использование этого подхода и как справляться с трудностями «мертвых» ссылок, которые возникают в любом мало-мальски объемном приложении в результате наших собственных ошибок.