Bindings
Привязка какого-либо значения из модели к элементу представления. При изменении значения на любой из сторон отношения сразу же меняется значение на другой стороне.
Привязка идет через контроллер.
С помощью привязок сеть отношений между объектами модели можно расширить на контроллеры и далее на элементы представления.
Для работы с привязкой нужно, чтобы классы поддерживали key-value coding and key-value observing.
Обычный способ взаимодействия объектов - отправка сообщений. Но, чтобы этот способ работал, отправитель сообщения должен знать получателя сообщения и быть увереным, что он сможет его обработать.
Широковещательная рассылка уведомлений - способ уменьшить связанность подсистем. Наблюдателей может быть несколько, а отправитель может о них не знать.
Вводится центральный элемент - диспетчер событий.
Наблюдатель должен знать имя ожидаемого сообщения и ключи для доступа к словарю, которым владеет отправитель.
Сравнение уведомления с делегатами.
Преимущества уведомлений (отношения один-ко-многим):
- отправитель не знает получателей, которых может быть много
- уведомления могут быть разного типа
- уведомления могут быть межпроцессные
Преимущества делегатов (отношение один-к-одному):
- делегат может вернуть значение отправителю и повлиять на само событие (например, отменить его)
Преимущества привязок по сравнению с уведомлениями:
- Привязки также можно рассматривать как аналоги уведомлений, причем это более дешевый способ, т.к. не тратятся ресурсы на переодические отправки уведомлений и содержание посредника.
Преимущества уведомлений по сравнению с привязками:
- уведомления могут сообщать об изменении не только свойств,
- может быть неудобно делать классы KVO, KVB совместимыми.
Обработка уведомлений - достаточно дорогая вещь, особенно потому, что отправка уведомления происходит синхронно и пока оно не будет обработано, отправитель ничего сделать не сможет.
Рекомендации по использованию уведомлений:
- применять выборочно
- в наблюдателях реализовывать обработчики эффективно и коротко
- назначать событиям ясные названия
- избегать множественных наблюдателей, лучше иметь промежутного наблюдателя, который будет сообщать результаты наблюдений заинтересованным в них объектам.
The Notification Object
NSNotification. Содержит имя (тег) уведомления, объект, который может быть любым объектом, который отправитель хочет отправить наблюдателю. Обычно - это сам объект отправителя (аналог sender). Также содержит словарь для передачи вспомогательной информации.
Notification Centers
NSNotificationCenter. Диспетчер уведомлений от отправителей к наблюдателям.
Notification Queues
Содержит очередь уведомлений.
Очередь может очищаться от одинаковых уведомлений. Для определения одинаковости вводятся несколько критериев (по имени, по отправителю и т.д.).
Уведомление может иметь индикатор для перемещения из очереди в центр уведомлений. Сам центр может находиться также в нескольких состояниях. Перемещение уведомления из очереди в центр происходит при совпадении индикатора уведомления и состояния центра.
Способы освобождения очереди (перемещения уведомлений в центр)
NSPostASAP - Posting As Soon As Possible. Уведомления в центре обслуживаются в цикле. При этом способе уведомление перещается в центр сразу же после окончания очередной итерации.
Пример: запросы на отрисовку составного изображения на поверхности окна. Запросы поступают из многих источников. Окончательное изображение формируется на сервере. Было бы накладно отправлять поверхность на сервер после обслуживания каждой операции. Поэтому все отправители, рисующий на поверхности, ставят в очередь уведомление FlushTheServer. Дубликаты этих уведомлений удаляются. Это уведомление имеет атрибут NSPostASAP. Как только текущий цикл обработки запросов на рисование будет выполнен, одно уведомление FlushTheServer будет передано в центр и выполнено, т.е. поверхность будет передана на сервер и отображена в окне.
NSPostWhenIdle - Posting When Idle. Уведомление уходит в центр, если он находится в состоянии ожидания. Время жизни входов центра может закончиться и он перестанет находиться в состоянии ожидания. В этом случае уведомление не будет отправлено.
NSPostNow - Posting Immediately. Синхронный способ передачи. Центр обслужит уведомление и сообщит, что наблюдатели его обработали.
Ownership of Delegates, Observers, and Targets
Владеть делегатами, наблюдателями и целевыми объектами для отправки им действий должны клиенты, а не хост-классы, центр уведомлений и ячейки. Конечно, на них устанавливаются т.н. слабые указатели (без владения, т.е. увеличения счетчика ссылок). Запрет на владение устанавливается, чтобы избежать циклического владения, когда два объекта владеют друг другом. Они не будут никогда удалены.
Если создается класс, производный от класса фрейворка, в котором есть делегат, источник данных, наблюдатель или цель, то производный класс не должен обладать этими объектами.
Поэтому при архивировании сохранять все эти объекты нужно явно.
Комментариев нет:
Отправить комментарий