Совместное использование NSOperationQueue через контроллеры представления?

Я просто помнил другой прием, который я раньше узнавал, какие статические библиотеки плохо вели себя: 'grep' через статические библиотеки для строки '21022'. ОДНАКО не используйте 'нормальные' grep инструменты как wingrep, потому что они не покажут Вам эти строки (они думают, что это - двоичный файл, и ищите сырые данные, non-unicode строка). Используйте 'строковую' утилиту от набора ресурса (теперь в сайте Russinovich, я думаю). Тот будет grep через двоичные файлы хорошо. Таким образом, Вы позволяете, это 'представляет в виде строки', проходят Ваше целое исходное дерево, и Вы будете видеть двоичные файлы (dlls и статические библиотеки), которые содержат ссылки на неправильную декларацию (или на декларацию с неверной версией в нем).

13
задан 31 August 2009 в 10:45
поделиться

3 ответа

Я решил эту проблему, добавив метод класса в 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
14
ответ дан 1 December 2019 в 23:48
поделиться

Я лично предпочитаю иметь синглтон, который управляет всеми HTTP-запросами. Затем каждое представление будет запрашивать одноэлементный объект для выполнения http-вызова, передавая себя в качестве делегата для этого вызова, затем одноэлементные руки, которые делегируют и вызывают NSOperation, а затем NSOperation выполняет обратный вызов после завершения вызова.

3
ответ дан 1 December 2019 в 23:48
поделиться

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

Я полагаю, что вы хотите сделать что-то вроде: a) view (Controller) передает url (+ data) объекту обработки сервера, b) объекты обработки сервера создают операцию и помещают ее в очередь, которую он и только он имеет указатель на.

Трудно понять, почему это не сработало, если вы не предоставите более подробную информацию.

Я настоятельно рекомендую взглянуть на ASIHTTPRequest , который предоставляет класс NetworkQueue для справиться с такой задачей. В нем есть несколько удобных полей делегатов, которые позволяют вам регистрироваться, чтобы отслеживать прогресс, знать, когда загрузка или загрузка завершилась и т. Д.

0
ответ дан 1 December 2019 в 23:48
поделиться
Другие вопросы по тегам:

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