Какао: Проверки, требуемые для нескольких асинхронных NSURLConnections, использующих те же функции делегата?

Matt прав.

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

Так два решения:

  1. Как Matt сказал, сделайте действие, которое не берет идентификатора, но ищет, ток вошел в систему пользователь от информации о сессии и получает их.
  2. Делают действие, которое берет идентификатор, но только предоставьте доступ администраторов - таким образом, они могут изменить другую информацию о пользователях при необходимости.

, Но отвечать на вопрос, Авторизация только для высказывания "да, Этот человек может использовать изменить пользовательское действие", не на основе вводимого параметра.

другой путь состоит в том, что Вы могли заставить его проверить, что пользователь получил == текущий пользователь или перенаправление к другому действию, говоря, что они не могут отредактировать того пользователя - но было бы лучше только обеспечить действие, которое не берет идентификатор, и просто добирается, ток вошел в систему пользователь.

9
задан Community 23 May 2017 в 11:43
поделиться

3 ответа

Предположим, вы запускаете все (асинхронные) соединения в одном потоке, тогда все сообщения делегатов будут отправлены в цикл выполнения этого потока. Следовательно, делегат должен иметь возможность обрабатывать только одно сообщение одновременно; цикл выполнения будет передавать по одному сообщению за раз. Это означает, что хотя порядок сообщений делегата неизвестен, и следующее сообщение может поступить от любого объекта соединения, одновременное выполнение ваших методов делегата не будет.

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

13
ответ дан 4 December 2019 в 07:04
поделиться

Да возможно иметь несколько подключений. объект уведомления содержит указатель на NSURLConnection , который инициировал уведомление.

Внутренне, я думаю, NSURLConnection прослушивает сокет и делает что-то подобное, когда у него есть данные.

[your_delegate 
    performSelectorOnMainThread:@selector(connectionCallback:) 
    withObject:self 
    waitUntilDone:NO];

], поэтому вам не нужно беспокоиться о многопоточности, NSURLConnection позаботится об этом. Для простоты я написал self, в реальном мире дается объект NSNotification .

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

0
ответ дан 4 December 2019 в 07:04
поделиться

Я улучшил библиотеку 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
}
19
ответ дан 4 December 2019 в 07:04
поделиться
Другие вопросы по тегам:

Похожие вопросы: