Swing Application Framework (JSR-296) - Parte 3

A terceira parte do artigo sobre o Swing Application Framework trata sobre a execução de tarefas em background.

A primeira parte discorre sobre a JSR-296, gerenciamento de ciclo de vida e inicialização do aplicativo, o armazenamento do estado da GUI entre sessões e persistência local. A segunda parte apresentou a injeção de recursos e a definição, gerenciamento e binding de Action’s.

Para uma total compreensão dessa terceira parte, é necessária a leitura da segunda parte do artigo e do texto O Básico sobre SwingWorker.

Tarefas em Background

Task estende SwingWorker, o que equivale a dizer que representa uma tarefa que executa em [uma thread em] background. De acordo com sua documentação, Task adiciona [à SwingWorker]:

• uma série de propriedades descritivas que podem ser mostradas aos usuários;
• um novo conjunto de métodos para customizar o término de uma tarefa;
• possibilidade de bloquear entrada (input) à GUI enquanto a tarefa está executando; e
• um TaskListener que permite monitorar os três métodos chaves de SwingWorker: doInBackground, process e done.
  

Done

O método abstrato doInBackground é a principal questão a ser considerada ao implementar tanto uma subclasse de SwingWorker quanto de Task, já que é sua responsabilidade definir exatamente o que irá ser executado em background.

O método done, porém, é final em Task. done é utilizado para executar atividades complementares na event dispatch thread (EDT) após o termino do método doInBackground. Em Task, done invoca os métodos succeeded, cancelled, interrupted ou failed quando a worker thread termina, respectivamente, com sucesso, porque foi cancelado, interrompido ou por alguma falha de execução.

Independentemente do resultado, done sempre invoca finished ao terminar sua execução, mesmo que uma exceção seja lançada. Por padrão, failed grava o erro em questão num arquivo de log; os demais métodos nada fazem. Como done executa na EDT, todos esses métodos também correrão nessa mesma thread.

Task in Action

Como mostrado em O Básico sobre SwingWorker, obter as entidades cadastradas num banco de dados dificilmente deve ocorrer na EDT, sob pena de congelamento da GUI. Aquele artigo mostra o uso de SwingWorker para resolver essa situação, enquanto esse texto irá mostrar o mesmo com Task, por suas facilidades adicionais.

private class LoadEntitiesWithTask extends Task<List<EntityClass>, Void> {

.....LoadEntitiesWithTask() {
..........super();
..........setLoadEnabled(false);
..........setStopEnabled(true);
.....}

.....protected List<EntityClass> doInBackground() {
..........setMessage("Obtendo " + entityName + "s cadastrados...");
..........return domainManager.findAll();
.....}

.....protected void succeeded(final List<EntityClass> newEntities) {
..........synchronized(this) {
...............if (!entities.isEmpty()) {
....................clear();
...............}
...............entities.add(0, EMPTY_ENTITY);
...............entities.addAll(newEntities);
..........}
..........fireContentsChanged(this, 0, entities.size() - 1);
..........setMessage(
...................."Feito: lista de " + entityName + "s obtida com êxito em "
....................+ getExecutionDuration(TimeUnit.MILLISECONDS) + "ms.");
.....}

.....protected void cancelled() {
..........setMessage("Operação cancelada.");
.....}

.....protected void interrupted(final InterruptedException ex) {
..........setMessage("Operação cancelada.");
.....}

.....protected void failed(final Throwable ex) {
..........setMessage("Erro: não foi possível obter " + entityName + "s cadastrados.");
.....}

.....protected void finished() {
..........setLoadEnabled(true);
..........setStopEnabled(false);
.....}
}

As mudanças mais significativas em relação à sua equivalente com SwingWorker são referentes aos métodos succeeded (no lugar de done), cancelled, interrupted, e failed que enviam mensagens a componentes específicos, como statusbar (mais sobre isso depois), e ao método finished.

Task pode ser utilizada em conjunto com @Action's (sobre Action's, ver parte 2) para definir tarefas que iniciam a partir de eventos gerados pela GUI.

@Action(block=BlockingScope.ACTION, enabledProperty="loadEnabled")
public Task load() {
.....loadEntitiesTask = new DefaultEntityModel.LoadEntitiesWithTask();
.....return loadEntitiesTask;
}

Note que o método load retorna Task. Infelizmente, tanta facilidade tem seu preço. Para alterar o comportamento de LoadEntitiesWithTask de modo que apenas obtenha as entidades se as mesmas não foram previamente carregadas, é preciso estender a classe. (Com SwingWorker, bastaria criar uma variação do método load).

private class LoadEntitiesIfEmpty extends LoadEntitiesWithTask {

.....LoadEntitiesIfEmpty() {
..........super();
.....}

.....protected List<EntityClass> doInBackground() {
..........if (entities.isEmpty()) {
...............return super.doInBackground();
..........}
..........return null;
.....}

.....protected void succeeded(final List<EntityClass> entities) {
..........if (entities == null) {
...............return;
..........}
..........super.succeeded(entities);
.....}
}

O método loadIfEmpty é responsável, sob o ponto de vista de quem o invocar, de carregar as entidades no formulário caso isso ainda não tenha acontecido.

public void loadIfEmpty() {
.....loadEntitiesTask = new DefaultEntityModel.LoadEntitiesIfEmpty();
.....ApplicationContext.
...............getInstance().
...............getTaskService().
...............execute(loadEntitiesTask);
}

Bloqueando a GUI

Ao utilizar a worker thread para executar longas tarefas, pode ser necessário bloquear certos componentes ou o aplicativo inteiro até que a tarefa termine.

Como exemplo, a tarefa de recarregar as entidades cadastradas num banco de dados certamente deve correr em background, e a possibilidade de concorrência dessa mesma tarefa dificilmente teria alguma utilidade. Portanto, bloquear o componente que inicia a tarefa em questão até que termine é interessante.

A opção de bloquear a GUI durante a execução de uma tarefa é feita definindo um valor para a propriedade block da anotação Action. Os possíveis valores para block são obtidos através da enumeração BlockingScope de Task: NONE (o padrão), ACTION, COMPONENT, WINDOW e APPLICATION. O método load, acima, utiliza BlockingScope.ACTION:

@Action(block=BlockingScope.ACTION, . . .)
public Task load() {
...... . .
}

Repare que o botão para carregar as entidades está desabilitado enquanto LoadEntitiesWithTask executa (observe a barra de progresso na statusbar).

BlockingScope.WINDOW e BlockingScope.APPLICATION bloqueiam a janela de nível mais alto e o aplicativo inteiro, respectivamente, por padrão mostrando um dialog indicando que o software está ocupado. O modo como esse bloqueio é feito pode ser customizado implementando a classe abstrata application.Task.InputBlocker e estabelecendo-a como o bloqueador de Task por meio de seu método setInputBlocker.

You've Got a Message

Com o auxílio de application.TaskMonitor, desenhada para ser o model de widgets como barra de estado, e dos métodos de Task setMessage e message, enviar notificações para a GUI sobre o estado da execução das tarefas na worker thread beira o trivial.

setMessage foi utilizado por simplicidade. O modo aconselhável para isso é definir as mensagens num arquivo de propriedade e utilizar o método message (consulte documentação da classe e exemplos que acompanham o framework).


Repare na mensagem avisando sob o término da operação. Além disso, como a operação para carregar as entidades chegou ao fim. o botão para carregar as entidades está habiltado, enquanto o que cancela essa operação está desativado...

Outros Métodos Úteis

A classe Task ainda possui uma série de métodos úteis que incluem, mas não se limitam a:


• getExecutionDuration retorna o tempo de execução da tarefa;
• setProgress tem o objetivo de notificar barras de progresso em statubars que a tarefa teve algum progresso;
• isStarted e isPending complementam os métodos, presentes na classe SwingWorker, isDone e isCancelled.

Mantenha em mente que...

Esse artigo é apenas uma introdução ao assunto. Não deixe de consultar a documentação e até mesmo o código-fonte do projeto, fazer experiências, discutir sobre as funcionalidades do framework.

Veja também:

• Swing Application Framework (JSR-296) - Parte 1
• Swing Application Framework (JSR-296) - Parte 2
• Swing Application Framework: Lifecycle Events
• O Básico sobre SwingWorker
  

Fontes e Referências utilizadas:

• Swing Application Framework Home Page
• JSR 296: Swing Application Framework
• Javadoc e código fonte do Swing Application Framework
• An Introduction to Swing Application Framework API (JSR-296)