aplicação desktop e Web são quase os mesmo conceitos?

Oi Rodrigo,

Como tenho bastante experiência com java desktop e web, acho que posso te ajudar. Até onde consigo ver, java web realmente parece ser mais usado do que java desktop, mas mesmo assim eu não acho que este último seja pouco popular. Existem incontáveis trabalhos para a parte desktop do java e o nível das interfaces tem ficado tão alto que, as vezes, espanta até os mais otimistas.

Para entender melhor do que estou falando, veja as telas desse sistema aqui: http://nexvu.com/monarch_tour/

Telas como essas são feitas com um Look-and-Feel profissional e acompanhadas por designer talentosos. Mas, no fundo, isso é Swing nu e cru. Portanto, acho que vale a pena aprender java desktop sim, principalmente pelo poder de embelezamento disponível, algo que muitas outras linguagens não vão te proporcionar.

Quanto à parte web, os conceitos começam a mudar, e você infelizmente não vai conseguir aproveitar muito do Swing. Mas nada está perdido. O Google está lançando uma API chamada Google Web Toolkit (GWT), que permite desenvolver telas web usando componentes que lembram o lado desktop do java. Esse código, na verdade, é compilado para javascript e roda localmente no browser do cliente. Vale a pena conferir!

Esse mês tem um artigo meu na revista Java Magazine que fala de java desktop, além de um outro artigo sobre o GWT escrito por Douglas José Rodrigues.

Grande abraço,
Hugo.

Olá

Hugo, bem vindo ao GUJ.

Eu continuo não me conformando quando alguém divide aplicação desktop de aplicação web como a própria Sun faz.

Para mim a divisão é outra:

1 - Aplicação web = aplicação que usa protocolo web e troca informações com um servidor web. Exemplos: Firefox, messenger, qualquer aplicação que use servlets seja com cara de browser, swing, thinlet, swt, etc.

2 - Aplicação isolada = aplicação que funciona confinada em uma rede local. Exemplos: programas em clipper, VB, Microsoft Office, Winzip, etc.

Como todo mundo que me conhece no GUJ já sabe, na minha opinião não há nenhum sentido escrever aplicações do tipo 2 a menos que seja um programinha simples tipo utilitário.

Rodrigo

Respondendo a sua pergunta, minha sugestão é que comece aprendendo Java e orientação a objetos. Procure antes dominar Java, conhecer threads, saber escrever exceptions, saber usar principalmente as APIs de java.lang, java.util, Collections, IO, NIO e concurrent. Leia livros tais como o Effective java. Depois estude servlets, HTTP e XML. Com estes conhecimentos então pode optar com mais clareza o caminho a seguir.

Não faça como a maioria que tenta aprender desenvolvimento Java para web sem saber servlets, sem entender nada de HTTP, com poucos conhecimentos de OO e praticamente sem saber Java.

[]s
Luca

Nossa !!!, Valeu e muito as dicas, muito obrigado mesmo pelas respostas, ficou bem mais claro as coisas pra mim agora, 2 feras responderam… Irei seguir a risca o que me falaram, exemplos, livros e tudo mais… Obrigado pelas dicas

Bom dia Luca.

Sempre que vejo seus posts advogando para a utilização de aplicações web com swing, fico com uma dúvida:

Você aconselha que as trocas de mensagem entre o aplicativo swing e o servidor web sejam feitas por serialização? XML? SOAP? Algum framework proprietário que facilite a vida?

Em tempo, fiz uns testes com serialização (a aplicação será java servlet - java swing/httpclient) passando o objeto por HTTP e gostei. Não sei se isso acarretará problemas ou se estou fazendo da forma mais díficil.

Alguma idéia?

Olá

Guilherme

Não é bem que eu seja defensor do Swing. O que afirmo sempre é que o Swing é apenas um meio de fazer a camada de apresentação e não um meio de isolar o sistema do mundo como era o caso do Clipper e do Delphi e VB antigos.

Para a troca de mensagens se deve usar o que for mais adequado em cada caso. Se no lado servidor estiver um servlet container então não há nenhuma vantagem de usar um protocolo de mensagens feito especialmente para interoperabilidade como é o caso do SOAP.

Você pode usar CSV, XML e outros protocolos específicos como o ISO8583 do mundo financeiro para passar os valores. Passando só os valores as mensagens costumam ficar mais compactas. Em geral, quanto mais simples as mensagens mais rapidamente podem ser processadas.

Eu já participei do desenvolvimento de sistemas em que se optou por passar objetos serializados (em XML ou não). Mas a escolha não foi por performance do sistema. A opção foi feita para ganhar tempo e facilitar o desenvolvimento do lado servidor que acabou ficando bem pequeno por ser genérico (dentro do domínio da aplicação). Mas nem sempre o throughput exigido da aplicação permite trocar objetos serializados. Caso permita, o XStream pode ser útil. A única vantagem de usar XML puro ou na serialização é que a depuração das mensagens fica muito mais fácil e com isto se ganha um bom tempo na finalização do desenvolvimento.

[]s
Luca