Я просто помнил другой прием, который я раньше узнавал, какие статические библиотеки плохо вели себя: 'grep' через статические библиотеки для строки '21022'. ОДНАКО не используйте 'нормальные' grep инструменты как wingrep, потому что они не покажут Вам эти строки (они думают, что это - двоичный файл, и ищите сырые данные, non-unicode строка). Используйте 'строковую' утилиту от набора ресурса (теперь в сайте Russinovich, я думаю). Тот будет grep через двоичные файлы хорошо. Таким образом, Вы позволяете, это 'представляет в виде строки', проходят Ваше целое исходное дерево, и Вы будете видеть двоичные файлы (dlls и статические библиотеки), которые содержат ссылки на неправильную декларацию (или на декларацию с неверной версией в нем).
Я решил эту проблему, добавив метод класса в NSOperationQueue, который, как мне кажется, Apple упустила; общая очередь операций. Я добавляю это как категорию в NSOperationQueue следующим образом:
// NSOperationQueue+SharedQueue.h
@interface NSOperationQueue (SharedQueue)
+(NSOperationQueue*)sharedOperationQueue;
@end
// NSOperationQueue+SharedQueue.m
@implementation NSOperationQueue (SharedQueue)
+(NSOperationQueue*)sharedOperationQueue;
{
static NSOperationQueue* sharedQueue = nil;
if (sharedQueue == nil) {
sharedQueue = [[NSOperationQueue alloc] init];
}
return sharedQueue;
}
@end
Таким образом, мне не нужно управлять целой кучей очередей, если мне это действительно не нужно. У меня есть легкий доступ к общей очереди со всех моих контроллеров представления.
Я даже добавил категорию в NSObject, чтобы было еще проще добавлять новые операции в эту общую очередь:
// NSObject+SharedQueue.h
@interface NSObject (SharedQueue)
-(void)performSelectorOnBackgroundQueue:(SEL)aSelector withObject:(id)anObject;
@end
// NSObject+SharedQueue.m
@implementation NSObject (SharedQueue)
-(void)performSelectorOnBackgroundQueue:(SEL)aSelector withObject:(id)anObject;
{
NSOperation* operation = [[NSInvocationOperation alloc] initWithTarget:self
selector:aSelector
object:anObject];
[[NSOperationQueue sharedOperationQueue] addOperation:operation];
[operation release];
}
@end
Я лично предпочитаю иметь синглтон, который управляет всеми HTTP-запросами. Затем каждое представление будет запрашивать одноэлементный объект для выполнения http-вызова, передавая себя в качестве делегата для этого вызова, затем одноэлементные руки, которые делегируют и вызывают NSOperation, а затем NSOperation выполняет обратный вызов после завершения вызова.
Если у вас уже есть указатель на класс, который обрабатывает соединения в каждом контроллере представления / представления, нет причин, по которым вам также может понадобиться указатель на очередь операций.
Я полагаю, что вы хотите сделать что-то вроде: a) view (Controller) передает url (+ data) объекту обработки сервера, b) объекты обработки сервера создают операцию и помещают ее в очередь, которую он и только он имеет указатель на.
Трудно понять, почему это не сработало, если вы не предоставите более подробную информацию.
Я настоятельно рекомендую взглянуть на ASIHTTPRequest , который предоставляет класс NetworkQueue для справиться с такой задачей. В нем есть несколько удобных полей делегатов, которые позволяют вам регистрироваться, чтобы отслеживать прогресс, знать, когда загрузка или загрузка завершилась и т. Д.