Предпочтительный шаблон проектирования для блокировки интерфейса

Question

У меня есть приложение, которое выполняет различные задачи, которые могут занимать до минуты каждая. Я хотел убедиться, что я установил приложение в «рабочее состояние» согласованным образом, поэтому я настроил класс (назовем его «LockI»), который при инициализации записывает текущее состояние различных вещей ( курсор, строка состояния, обновление экрана и т. д.). Затем, когда вызывается метод restrict, он переводит все в рабочее состояние. В деструкторе класса все исходные настройки восстанавливаются, поэтому мне не нужно беспокоиться об ошибке (или о том, что кто-то забыл вызвать метод восстановления), когда приложение полностью заблокировано. Кроме того, поскольку приложение восстанавливает состояние, в котором оно было найдено, при повторном обращении к классу мне не нужно беспокоиться о том, что оно случайно разблокирует приложение, когда класс, находящийся глубже в стеке, будет уничтожен.

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

Уточнение: Чтобы быть более кратким ... Принимая во внимание следующее:

1. Для более длительных действий вам понадобится экземпляр класса Lock, доступный для обновления индикатора выполнения.
2. Возможно, вы вызываете более одной процедуры (если вы не направили их через процедуру верхнего уровня).
3. Вы не будете отображать строку состояния для всех процедур (поскольку иногда это просто не нужно и фактически замедляет работу).

Лучше ли создавать экземпляр класса в обработчике кликов, а затем передавать его вызываемой процедуре (-ам) по мере необходимости или создавать экземпляр класса в вызываемой процедуре, и если вам нужно вызывать несколько процедур, установите «воронку»

Answer 1

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

В качестве альтернативы, вы можете использовать подход «действовать и блокировать», подобный тому, который вы описываете, когда система предотвращает все дальнейшие взаимодействия после каждого действия, которое выполняет пользователь. Это полезно, если есть четкая последовательность действий, которые нужно выполнить (не как заполнение формы, где вы можете начать где угодно), если они занимают относительно много времени (дольше, чем ввод нескольких символов в текстовом поле!), И если зависимости между одним действием и следующим являются критическими (то есть одно действие не может быть выполнено, если предыдущее не было проверено). В этом случае рекомендуется использовать схему «действовать и заблокировать». Это надежно и потенциально уменьшает количество ошибок, если хорошо реализовано. В современных графических интерфейсах, где многопоточная поддержка легко доступна, вы можете просто заблокировать окно, в котором выполняются действия; Кроме того, вы можете заблокировать все приложение. Это не так элегантно, но обычно проще в разработке. В любом случае, информационное сообщение необходимо, и какой-либо индикатор выполнения настоятельно рекомендуется.

Редактировать. По вопросам имплементации я бы создал класс ModalInteractor на своем уровне представления (GUI) и создал бы объект этого класса всякий раз, когда я хочу начать новое модальное взаимодействие с пользователем. Этот класс имеет следующие области повторной ответственности: (a) блокировка и разблокировка соответствующих элементов пользовательского интерфейса, (b) сигнализация прогресса и (c) управление отменой. Вы можете легко определить, какие методы свойств вам понадобятся для каждой из этих областей. Семантически, ModalInteractor является частью логики, которая управляет или управляет вашим GUI («контроллер», некоторые скажут). Всякий раз, когда пользователь нажимает кнопку, которая запускает длительный процесс, создайте новый объект ModalInteractor и передайте ссылку на текущее окно в конструкторе. Сконфигурируйте объект с несколькими делегатами, чтобы он знал, какой метод вызывать, чтобы начать длительный процесс, какие методы в окне вызывать для уведомления о ходе выполнения и на какое событие реагировать, когда пользователь нажимает Cancel.

Надеюсь, это поможет.

Answer 2

Я думаю, что ваша жизнь была бы намного проще (и жизнь пользователя менее разочаровывающей), если вместо этого вы открыли модальное диалоговое окно с индикатором выполнения, сообщением о состоянии и кнопкой отмены.