2013-06-21 1 views
0

У меня есть NSObject, который прослушивает ~ 30 строковых сигналов. Я хочу опубликовать любое количество строк для этого объекта. Но сначала я хочу проверить, проверяет ли она текущую строку.Тест, если NSObject наблюдает строку

Документация для [NSNotificationCenter][1] не предполагает, что это возможно. Есть только add/remove remove observer и методы уведомления.

Документация для KVO заставляет меня думать, что это возможно, используя метод [[NSNotificationCenter defaultCenter] observationInfo]. Я не знаю, как использовать возвращаемый void*. В документации говорится, возвращаемое значение:

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

Я особенно ценю «и так далее». Это была самая полезная часть ... вздох.

Учитывая количество сигналов, обрабатываемых объектом, я не хочу вручную проверять каждую строку. Есть ли изящный способ проверить, является ли объект наблюдением за строкой (try/catch не подходит) на уровне NSObject или уровне KVO, который не использует частный API?

Спасибо.

ответ

1

Указатель, используемый -observationInfo, непрозрачен (т. Е. Не имеет смысла); это всего лишь токен. Из заголовка (курсив мой):

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

Кроме того, наблюдения KVO и наблюдения NSNotificationCenter представляют собой два совершенно разных механизма без какой-либо связи между ними. Ни один публичный API не предлагает для выяснения того, кто что наблюдает. Единственный способ, с помощью которого можно отслеживать наблюдения, - это переопределить методы добавления/удаления (либо с переопределением метода для KVO, либо путем swizzling методов в NSNotificationCenter), а затем самостоятельно отслеживать информацию о наблюдениях.

Я не хочу быть «тем парнем», но хочу знать, кто наблюдает за тем, что обычно является красным флагом, что что-то не так хорошо архивировано. Если вы беспокоитесь о производительности, я бы этого не сделал. KVO и NSNotificationCenter являются довольно быстрыми/низкими служебными механизмами. ~ 30 наблюдений не означают ни того, ни другого. Я бы не стал беспокоиться об этом.

+0

попробуйте/поймите. :) Спасибо за понимание! – stephen

+0

Не знаете, почему попытка/улов будет задействована, честно. Если вы вызываете 'will/didChangeValueForKey', и никто не слушает, это не-op. Аналогично, если вы отправляете уведомление в NSNotificationCenter, и никто его не слушает, ничего не происходит. В обоих случаях не следует исключать никаких исключений. – ipmcc

+0

У меня есть [App] Socket, который специализируется на XMLMessageSocket, который специализируется на TCPSocket. Когда XMLMessageSocket решает, что он получил полное xml-сообщение, он получает имя сигнала и отправляет ему сообщение. Если [App] Socket не отвечает на сообщение, генерируется исключение. – stephen

 Смежные вопросы

  • Нет связанных вопросов^_^