Рубрика «обработка событий»

Содержание

Вы властны над своим разумом, но не над внешними событиями. Когда вы поймёте это, вы обретёте силу.
Марк Аврелий, «Медитации».

Некоторые программы работают с вводом пользователя, мышью и клавиатурой. Время возникновения такого ввода и последовательность данных нельзя предсказать заранее. Это требует иного подхода к контролю над порядком выполнения программы, чем уже привычный нам.

Обработчики событий

Представьте интерфейс, в котором единственным способом узнать, нажали ли на кнопку клавиатуры, было бы считывание текущего состояния кнопки. Чтобы реагировать на нажатия, вам пришлось бы постоянно считывать состояния кнопок, чтобы вы могли поймать это состояние, пока кнопка не отжалась. Было бы опасно проводить другие подсчёты, отнимающие процессорное время, так как можно было бы пропустить момент нажатия.
Читать полностью »

Здравствуйте, хабрапользователи!
В этой публикации мы расскажем о нашей новой нароботке Events class.
Новый класс реализовывает некую систему событий для ImageCMS. Это механизм, который предоставляет возможность разработчику реагировать на возникновение определенных ситуаций в системе, что станет неотъемлемой составляющей для написания более гибких модулей.
Обработчик событий для ImageCMS
Дальше расскажем подробно о том, как мы видим инженерию и вектор будущих развитий.
Читать полностью »

Многие, вероятно, знают, что при работе с событиями изменения свойств с помощью key-value observing существует очень удобный механизм, предотвращающий появление в приложении «метрвых» объектов, которые представляют собой получателей вызовов. В действительности, первый же мертвый объект «валит» приложение, при поступлении ему события — это закономерно, так как объект уже не существует и никаких методов вызвать у него уже не получится.

Поиск таких объектов мог быть затруднен, если бы не замечательная в отладке вещь под названием NSKVODeallocateBreak, которая позволяет прервать выполнение приложения в момент, когда уничтожается объект, подписанный на события, чтобы отследить время его жизни и убрать проблему.

В процессе работы над классом, который я использовал для событий, мне захотелось создать аналогичный механизм, так как ошибки в событийной логике довольно сложно прогнозировать, и страховка здесь не помешает.

Данная статья рассчитана на разработчиков, имеющих опыт работы с платформой и знающих, каким образом определяется жизненный цикл объекта. Если у вас есть определенные пробелы в этой области (а я неоднократно встречал даже опытных разработчиков, которые не знают, каким образом работает счетчик ссылок и не представляющих, во что разворачивается @synthesize), то вы можете прочитать мою старую статью, посвященную исследованию данного вопроса. Остальных прошу к столу.

Читать полностью »

Событийно-ориентированная логика в Objective C держится на трех китах — протоколы, notification center и key-value observing. Традиционо протоколы используются для расширения функционала базовых классов без наследования, key-value observing – для взаимодействия между визуальной и логической частью приложения, а notification center — для обработкий событий пользователя.

Естественно, все это благообразие можно спокойно использовать для построения сложных приложений. Никакой реальной необходимости в изобретении собственных велосипедов, конечно же, нет. Однако мне, как человеку пришедшему в разработку Objective C приложений из мира .NET, показалось очень неприятным то, что notification center, который я планировал использовать для событий, разраывает стек приложения, записывая произошедшее событие в очередь в UI thread, а протоколы в классическом представлении не слишком удобны, посему для удобства я решил соорудить себе механизм, который был бы гораздо больше похож на то, чем мы привыкли обходиться в мире .NET. Так родился родилась идея реализации модели множественных подписантов через специальный класс, названный AWHandlersList.

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

Читать полностью »

В системе управления сайтами UMI.CMS изначально заложено разделение на основной движок сайта, который не трогается вэб-разработчиком (и который перезаписывается при обновлении системы), и дополнительный (кастомный) функционал, который уже разработчик сайта адаптирует под себя: собственные шаблоны дизайна, макросы (PHP-функции, вызываемые из шаблонов), собственные модули, если необходимо.

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

  • добавить собственную логику импорта данных из XML;
  • выполнить какие-то действия при импорте данных;
  • выполнить какие-то действия при создании или изменении заказа;
  • выполнить какие-то действия по расписанию;
  • … и так далее.

В этом случае приходится либо править системный код движка (что сразу добавляет проблем при обновлении CMS), либо использовать встроенный функционал событий. В документации или на сторонних ресурсах этот вопрос рассмотрен, однако, на мой взгляд, недостаточно подробно. Данная статья является попыткой собрать воедино сведения о работе с событиями в UMI.CMS, а также на основе примера показать, как при помощи обработки событий можно расширить функционал системы.
Читать полностью »