estou com uma duvida conceitual na hora de implementar uma comunicação entre threads.
Seguinte:
Minha View (formulario do Swing), ao clicar no botão de submit do formulario, aciona um listener que por sua vez chama o controller.
O controller roteiaa requisição e instancia uma Thread do modelo, pra que o processamento seja executado com sucesso.
Problema:
Preciso que ao final da Thread da classe de modelo, o botão seja destravado (ou seja, a view precisa ser alterada mediante a alteração no modelo). Pode ser diretamente ou via controller (mvc1 ou 2…), tanto faz nesse caso.
A questão é, como fazer pra que a minha thread (que esta executando o codigo do controller), ao instanciar a thread do modelo se torne ouvinte da mesma ? Tentei fazer com wait() e notify() mas acho que acabei meio que me enrolando nos conceitos. Alguem tem alguma ideia ?
Criar uma interface contendo o método que vai ser chamado no final da thread, a idéia é que:
A classe que implementa essa interface limite-se a disparar um evento que vai ser ouvido na View e destravar o botão.
A classe que implementa essa interface deve ser criada fora do contexto da thread, de preferência do local onde vc está criando a thread, para que vc possa fazer essa comunicação(a variável terá que ser final).
Acredito que dessa forma funcione, a idéia básica é trabalhar com eventos, evitando assim acoplamento.
Bom, aproveitando o tópico de Threads, gostaria de saber se tem como o seguinte:
Tenho uma classe main, que aciona threads… Eu preciso que ao final da operação dos threads, os mesmo devolvam uma mensagem a classe main para que essa tome outras decisões baseadas nas respostas dos threads…
Atualmente eu informo a classe main sobre o resultado do thread através de sockets, mas como são muitas conexões, acho que seria mais eficaz se a comunicação pudesse ser feita diretamente com a classe main. Pois venho tendo alguns erros inexplicáveis e intermitentes…
Existe alguma outra forma de prover essa comunicação?
fabiolanza: você já trabalhou com o padrão Observer (que nas classes padrão do Java também é freqüentemente chamado de Listener)? Você pode registrar Listener’s na sua Thread, de modo que esses Listener’s sejam notificados quando ocorrer algum evento relevante na Thread. O Listener, no seu caso, será a classe Main.
E usar sockets foi mesmo uma péssima idéia. Socket é para comunicação entre duas aplicações diferentes.
Dentro de uma mesma aplicação, use listeners, compartilhe memória, etc.
Valeu galera… muito boas as sugestões. Future e Callable parecem atender exatamente o que eu preciso. E concordo que sockets são um overhead muito grande pra comunicação entre duas aplicações na mesma maquina (nao faz nem muito sentido isso).
GraveDigger, a idéia é boa porem so discordo de um ponto: que a Thread ao final da execução tenha que chamar um metodo que chame a view pra destravar o botão. Acho que dessa forma voce estaria amarrando a Thread uma responsabilidade que não é dela (isso na minha opiniao). Acho que seria melhor quando ela finalizar o trabalho, alguem ser notificado (no caso, o controller, que esta no contexto especifico daquela tarefa) e então esse chamar o metodo que destrava o botão. Valeu pela idéia!