Matt прав.
то, Для чего авторизация, должно показать, что им позволяют выполнить ту функцию - что Вы пытаетесь сделать, говорят, могут ли они выполнить функцию для того конкретного идентификатора.
Так два решения:
, Но отвечать на вопрос, Авторизация только для высказывания "да, Этот человек может использовать изменить пользовательское действие", не на основе вводимого параметра.
другой путь состоит в том, что Вы могли заставить его проверить, что пользователь получил == текущий пользователь или перенаправление к другому действию, говоря, что они не могут отредактировать того пользователя - но было бы лучше только обеспечить действие, которое не берет идентификатор, и просто добирается, ток вошел в систему пользователь.
Предположим, вы запускаете все (асинхронные) соединения в одном потоке, тогда все сообщения делегатов будут отправлены в цикл выполнения этого потока. Следовательно, делегат должен иметь возможность обрабатывать только одно сообщение одновременно; цикл выполнения будет передавать по одному сообщению за раз. Это означает, что хотя порядок сообщений делегата неизвестен, и следующее сообщение может поступить от любого объекта соединения, одновременное выполнение ваших методов делегата не будет.
Однако если вы на самом деле пытались использовать один и тот же объект делегата через несколько потоков, а не просто использование асинхронной природы API, тогда вам потребуется иметь дело с параллельными методами делегирования.
Да возможно иметь несколько подключений. объект уведомления содержит указатель на NSURLConnection
, который инициировал уведомление.
Внутренне, я думаю, NSURLConnection
прослушивает сокет и делает что-то подобное, когда у него есть данные.
[your_delegate
performSelectorOnMainThread:@selector(connectionCallback:)
withObject:self
waitUntilDone:NO];
], поэтому вам не нужно беспокоиться о многопоточности, NSURLConnection
позаботится об этом. Для простоты я написал self, в реальном мире дается объект NSNotification
.
Вам не нужно выполнять никаких проверок, связанных с многопоточностью.
Я улучшил библиотеку Three20, чтобы реализовать асинхронные соединения между несколькими потоками для извлечения данных, даже если пользователь играл с пользовательским интерфейсом. После многих часов поиска случайных утечек памяти, обнаруженных в рамках CFNetwork, я, наконец, получил root права, вызвав проблему. Иногда я терял отслеживание ответов и данных.
Любые структуры данных, к которым обращается несколько потоков, должны быть защищены соответствующей блокировкой. Если вы не используете блокировки для доступа к совместно используемым структурам данных взаимоисключающим образом, вы не являетесь потокобезопасным. См. Раздел « Использование блокировок » в Руководстве по программированию потоков Apple .
Лучшее решение - создать подкласс NSURLConnection и добавить переменные экземпляра для хранения связанных с ним ответов и данных ответов. Затем в каждом методе делегата соединения вы приводите NSURLConnection к своему подклассу и получаете доступ к этим переменным экземпляра. Это гарантированно будет взаимоисключающим, потому что каждое соединение будет связано с собственным ответом и данными. Я настоятельно рекомендую попробовать это, поскольку это самое чистое решение. Вот код моей реализации:
@interface TTURLConnection : NSURLConnection {
NSHTTPURLResponse* _response;
NSMutableData* _responseData;
}
@property(nonatomic,retain) NSHTTPURLResponse* response;
@property(nonatomic,retain) NSMutableData* responseData;
@end
@implementation TTURLConnection
@synthesize response = _response, responseData = _responseData;
- (id)initWithRequest:(NSURLRequest *)request delegate:(id)delegate {
NSAssert(self != nil, @"self is nil!");
// Initialize the ivars before initializing with the request
// because the connection is asynchronous and may start
// calling the delegates before we even return from this
// function.
self.response = nil;
self.responseData = nil;
self = [super initWithRequest:request delegate:delegate];
return self;
}
- (void)dealloc {
[self.response release];
[self.responseData release];
[super dealloc];
}
@end
/////////////////////////////////////////////////////////////////
////// NSURLConnectionDelegate
- (void)connection:(NSURLConnection*)connection
didReceiveResponse:(NSHTTPURLResponse*)response {
TTURLConnection* ttConnection = (TTURLConnection*)connection;
ttConnection.response = response;
ttConnection.responseData = [NSMutableData
dataWithCapacity:contentLength];
}
- (void)connection:(NSURLConnection*)connection
didReceiveData:(NSData*)data {
TTURLConnection* ttConnection = (TTURLConnection*)connection;
[ttConnection.responseData appendData:data];
}
- (void)connectionDidFinishLoading:(NSURLConnection *)connection {
TTURLConnection* ttConnection = (TTURLConnection*)connection;
if (ttConnection.response.statusCode == 200) {
// Connection success
}
}
- (void)connection:(NSURLConnection *)connection
didFailWithError:(NSError *)error {
TTURLConnection* ttConnection = (TTURLConnection*)connection;
// Handle the error
}