За и против Слушателя/Наблюдателя приближаются для уведомления Образцовых изменений
В любом типичном приложении для iPhone будут образцовые классы, которые ответственны за загрузку данных / парсинг. После завершения загрузки данных / задачи анализа, затронутые контроллеры должны были быть уведомлены относительно изменения в модели и обновить представление соответственно.
Существует несколько подходов слушателя/наблюдателя для этого в разработке приложения для iPhone. Каковы профессионалы/недостатки и причины использования каждого из следующих подходов?
- KVO
- NSNotification
- Делегат
- Любой другой известный подход
1 ответ
По моему собственному опыту:
Delegation:
- PRO: использовать только когда у вас есть один объект для уведомления;
- PRO: используя явный протокол, вы можете четко документировать свои намерения;
- CON: может быть источником аварий и утечек памяти при неправильном использовании (совет: не удерживать делегатов, назначать их и не забывать о деассигнации делегатов, когда / если они освобождаются! )
Я писал о проблемах управления памятью, возникающих при делегировании, в этой статье на своем блоге:
http://akosma.com/2009/01/28/10-iphone-memory-management-tips/
NSNotification:
- PRO: лучше, когда у вас есть несколько объектов для уведомления;
- PRO: очень гибкий, приводит к слабосвязанным классам;
- CON: уведомления посылаются синхронно (поэтому убедитесь, что ваши отдельные обработчики уведомлений делают очень мало)
- CON: иногда их сложно документировать и сопровождать. Обязательно объясните в заголовочных документах, что означает каждое уведомление и когда оно отправляется.
KVO:
- Аналогичные проблемы с NSNotifications;
- CON: еще более непонятны для документирования. Обязательно добавьте больше заголовочных документов или архитектурных подсказок к вашим комментариям, чтобы объяснить, кто что слушает. Лично я бы не стал использовать KVO для загрузки или разбора данных.
Лично я, имея дело с сетевыми приложениями, разговаривающими с удаленным веб-сервисом, использую однокнопочный класс загрузчика данных (обертывание ASIHTTPRequest и обработка всех задач сериализации и десериализации), который выдает всплывающие уведомления, когда что-то происходит. Таким образом, я могу попросить делегата приложения самостоятельно обрабатывать ошибки подключения (всплывающие уведомления и т.п. при необходимости), и каждый контроллер заботится только о тех ответах, которые он хочет получить.
Конечно, такой подход зависит от приложения, но эта общая архитектура может стать отправной точкой для вашего собственного кода.