Подтвердить что ты не робот

GWT: классы таймера и планировщика

Возможный дубликат:
Использование планировщика GWT

Я читал эту страницу несколько раз, и я просто не вижу некоторых неотъемлемых различий между GWT Timer и Scheduler классов. Я ищу варианты использования и применимость каждого из следующих:

  • Timer, Timer::schedule и Timer::scheduleRepeating
  • Scheduler::scheduleDeferred
  • Scheduler::scheduleIncremental
  • IncrementalCommand
  • DeferredCommand

Все они, похоже, делают одно и то же, более или менее, и кажется, что вы можете выполнить одни и те же задачи со всеми из них. Разве это просто способ GWT обеспечивает несколько способов сделать то же самое? Если нет, пожалуйста, помогите мне понять, когда и где каждый из них надлежащим образом используется. Спасибо заранее!

4b9b3361

Ответ 1

Используйте Планировщик, когда вам нужен браузер, чтобы завершить все, что он делает сейчас, прежде чем вы скажете ему сделать что-то еще. Например:

myDialogBox.show();
Scheduler.get().scheduleDeferred(new ScheduledCommand() {

    @Override
    public void execute() {
        myTextBox.setFocus();
    }
});

В этом примере фокус не будет установлен до тех пор, пока браузер не завершит визуализацию диалога, поэтому вы сообщите программе, что она будет ждать, пока браузер не будет готов.

Используйте Таймер, если вы хотите, чтобы какое-то действие произошло через определенный период времени. Например:

 notificationPanel.show();
 Timer timer = new Timer() {
     @Override
     public void run() {
         notificationPanel.hide();
     }
 };
 timer.schedule(10000);

Этот код покажет notificationPanel, а затем он скроет его через 10 секунд.

Ответ 2

Как говорит JavaDoc, DeferredCommand устарел в пользу Scheduler. Проблема с DeferredCommand и IncrementalCommand заключается в том, что они имеют статическое состояние (что затрудняет надежное использование в тестах). Более того, их (статические) методы вызывают вызовы JSNI, которые заставляют вас использовать GWTTestCase для проверки вашего кода (статические методы не являются легкомыслимыми). Статические методы также не позволяют их обернуть (например, добавить некоторые записи или что-то еще).
С другой стороны, вы работаете с экземпляром Scheduler (если вы хотите тестируемый код, вы будете использовать зависимость-инъекцию, чтобы получить экземпляр планировщика и никогда не назовете Scheduler.get(), за исключением вашего DI "factory" ). В тесте вы можете затем использовать StubScheduler.

Тогда там Timer, который аналогичен другим, но запланированная задача может быть отменена. Обратите внимание, что Timer использует JSNI тоже, как и DeferredCommand; любой код, который использует Timer, нуждается в тестировании GWTTestCase.