У нас есть что-то вроде этого:
private SwingWorkerExecutor swingWorkerExecutor;
//...
protected void runChain(List<SwingWorker<Void>> chainWorkers,
final SwingWorkerExecutor.RunAfter<Void> runAfter,
final SwingWorkerExecutor.RunOnError runOnError)
{
final List<SwingWorker<Void>> remainingWorkers =
chainWorkers.subList(1, chainWorkers.size());
SwingWorkerExecutor.RunAfter<Void> chainRunAfter;
if (chainWorkers.size() > 1)
{
chainRunAfter = new SwingWorkerExecutor.RunAfter<Void>()
{
@Override
public void run(Void value)
{
runChain(remainingWorkers, runAfter, runOnError);
}
};
}
else
{
chainRunAfter = runAfter;
}
currentWorker = chainWorkers.get(0);
swingWorkerExecutor.execute(currentWorker, chainRunAfter, runOnError);
}
Это довольно просто, IMO, потому что в нашем случае SwingWorkerExecutor на самом деле содержит все трудные для понимания вещи:
public class DefaultSwingWorkerExecutor implements SwingWorkerExecutor
{
@Override
public <T> void execute(SwingWorker<T, ?> worker, RunAfter<T> after,
RunOnError onError)
{
worker.addPropertyChangeListener(
new RunAfterHandler<T>(worker, after, onError));
worker.execute();
}
private static class RunAfterHandler<T> implements PropertyChangeListener
{
private final SwingWorker<T, ?> worker;
private final RunAfter<T> after;
private final RunAfter<Throwable> onError;
protected RunAfterHandler(SwingWorker<T, ?> worker, RunAfter<T> after,
RunOnError onError)
{
this.worker = worker;
this.after = after;
this.onError = onError;
}
@Override
public void propertyChange(PropertyChangeEvent evt)
{
if ("state".equals(evt.getPropertyName()) &&
evt.getNewValue() == SwingWorker.StateValue.DONE)
{
if (worker.isCancelled())
{
return;
}
try
{
after.run(worker.get());
}
catch (InterruptedException e)
{
Thread.currentThread().interrupt();
}
catch (ExecutionException e)
{
onError.run(e);
}
}
}
}
}
Есть некоторые недостающие интерфейсы, которые следует написать довольно просто, не видя их здесь.
Наше реальное развертывание SwingWorkerExecutor выполняется с использованием внедренного ExecutorService вместо используемого по умолчанию (это уменьшает количество пулов потоков, необходимых для одного приложения.) Но реальная причина, по которой мы представили SwingWorkerExecutor, заключалась в том, что он упрощает и стандартизирует обработку SwingWorker. условия успеха и ошибки, а также позволяет заменить логику для модульных тестов (которые, как я уверен, вы знаете, намного проще, если они однопоточные.) Как вы можете видеть, есть куча шаблонов, которые обычно необходимы для каждый SwingWorker внутри done (), поэтому вместо этого мы перемещаем работу done () в функцию обратного вызова.
Дополнительным преимуществом является то, что такие вещи, как запуск нескольких работников Swing в цепочке, становятся довольно простыми в реализации.