Концепция NSNotification - какой код кода идет где?

Question

Часть меня думает, что я понимаю концепцию NSNotification. Это централизованная система вещания со строковыми уведомлениями. Сообщение на одной стороне, наблюдайте на одной или нескольких других сторонах и действуйте соответствующим образом. Другая часть меня, хотя, часть, которая должна написать код, путается каждый раз, когда мне нужно уведомление. Какая часть кода входит в заголовок/реализацию, какие файлы фактически выполняют наблюдение и как я держу его в беспорядке? Время, чтобы выправить это, поможете мне проверить эти предположения? Я довольно уверен до числа 4, но номер 5 попадает в джекпот с путаницей.

---

1. NSNotifications созданы с помощью от [NSNotification defaultCenter], один не Alloc/инициализации в NSNotification. Верный?
2. Объект, выполняющий postNofification feat, всегда пропускает self в код сообщения: [[NSNotificationCenter defaultCenter] postNotificationName:@"note name" object:self]. Верный?
3. Событие барботирования существует на других языках, но не в Objective-C с NSNotification. Вы не передаете уведомления, вы делаете имя уведомления достаточно определенным для глобальной трансляции. Верный?
4. Если вы все еще хотите передать уведомление, отправленное объектом A, вы наблюдаете его в B, обрабатываете его и публикуете новое, более конкретное уведомление для объекта C для наблюдения. Например. @"MenuItemTapped" от A до B и @"NavigateTo" от B до C. Правильно?
5. Имя уведомления - NSString. Поскольку как плакат, так и наблюдатель хотят избежать опечаток, мы сохраняем константу NSString в [extern const | define | class method | none of the above]. Не могли бы вы помочь мне выбрать один?
   • Одной из попыток было создать что-то вроде файла NotificationNames.h, в котором будут содержаться все объявления extern NSString *const NOTE_NAME. Тем не менее это подрывает переносимость уведомления.
   • Еще одна попытка заключалась в подклассе NSNotification (с шаблоном XCode для быстрого сохранения), но поскольку эта концепция взята из подкласса класса Event в AS3, она показалась очень не объективной-c-ish. Там также странность, которую вы не можете назвать [super init] в NSNotification, поэтому все стало из-под контроля.
   • Мои проблемы с этим возникают из-за громоздких заявлений #import. Как свести к минимуму опечатки, но сохранить константы/определяет переносимость?

Answer 1

В основном вы его получили. Ваши номера 1-3, как правило, правильны.

• Вам не нужно будет выделять свой собственный объект NSNotification.
• Вы обычно передаете «я» как «объект» уведомления, как вы говорите, но вы также можете передать что-то еще, если вы уведомляете «от имени» что-то еще, концептуально. Но это будет менее распространенный случай.
• Уведомления не совпадают с «событиями» в пользовательском интерфейсе. У какао есть события; они являются событиями мыши/клавиатуры/касания, и они «пузыряют» «цепочку ответчиков» через объекты пользовательского интерфейса. Уведомления являются полностью независимым механизмом, который не привязан к пользовательскому интерфейсу, и используется для общедоступной широковещательной передачи среди других развязанных/независимых объектов. Это больше похоже на наличие нескольких делегатов для объекта.
• Да, вы должны определить имя уведомления где-нибудь, что могут видеть все, кто его использует.В самом какао обычно это общедоступный заголовок с объявлением вроде extern NSString *const UIKeyboardDidShowNotification. В каком-то частном файле реализации это определение.

Особое примечание относительно вашего # 4 выше. Учитывайте уведомления как , а не как инструкции. Обычно они фиксируют изменения состояния или широко интересные события. «MenuItemTapped» - это разумная вещь, о которой следует уведомлять, но «NavigateTo» обычно нет, потому что подразумевается, что вы указываете какой-то конкретный объект для навигации где-то. Если это так, то этот объект должен, вероятно, быть делегатом (или должен быть имуществом) вещи, которая хочет навигации, и вы должны заставить ее произойти напрямую. Разумеется, это не является требованием, и вы можете использовать механизм для того, что хотите. Но шаблоны дизайна Cocoa обычно не используют уведомления для «рассказывания объектов о том, что делать», только для того, чтобы «рассказать, кто бы ни заботился о том, что произойдет/что произойдет». Имеют смысл?

Наконец, в частности, повторите следующие примеры: # # # # # # # # # # # # # # # # # # # # # # # # #################################################################################################################

Answer 2

1. Вы можете создать NSNotification объектов, если хотите. postNotificationName:object: - это просто удобный метод, который создает, настраивает и размещает объект уведомления для вас.

2. Вы можете передать любой интересующий вас объект. Его цель - разрешить подписчикам уведомлений получать уведомления только о конкретном объекте, поэтому в идеале вы передаете объект, о котором идет уведомление, которое часто, но не всегда, должно быть self.

3. Игнорирование - это не события. Это глобальные трансляции в приложении.

4. Вы не отправляете уведомления о конкретном объекте - они транслируются. Если вы хотите отправить сообщение определенному объекту, вы просто вызываете метод для этого объекта.

5. Внешние элементы в файле заголовка в порядке.