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

Question

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

---

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

Answer 1

У вас в основном это есть.Ваши цифры 1-3 в целом верны.

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

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

Наконец, конкретно по поводу ваших примеров в # 4 - они звучат как настоящие события пользовательского интерфейса и кажутся, что все это можно обработать с помощью делегирования, если только нет какой-то причины, почему эти объекты должны бытьтак развязан.

Answer 2

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

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

3. Уведомления не являются событиями.Это глобальные трансляции внутри приложения.

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

5. Внешние значения в заголовочном файле вполне подходят.