Opções de desenvolvimento para aplicações Desktop

Boa tarde a todos(as)!

Preciso muito de umas idéias. :idea:

Eu possuo um sistema rodando em um cliente que fora feito em Visual Basic 6.
Sinceramente, o sistema está rodando muito bem. Recentemente, houve necessidade de desenvolver umas melhorias, e confesso…penei, esqueci até como faz um if.

Fora isso, o sistema tem muita dependencia, é necessário instalar o client ODBC do banco em cada estação, mapear um compartilhamento no servidor, o setup da aplicação é imenso devido as DLLs… e o pior, o Visual Basic 6 não roda corretamente nas versões posteriores ao XP, mesmo desabilitando o UAC.

Resumindo, há a necessidade de atualizar essa aplicação para uma plataforma de desenvolvimento mais recente.

Com base nisso, fiz um “lab” com Swing, criei uma CRUD básico. Realmente é bem mais trabalhoso, mas vejo como uma boa alternativa.

Alguém com experiência em aplicação Desktop poderia me dar alguma sugestão??
JSwing, JavaFx…

Desde já agradeço.

Cara eu passei por isso e a migração foi feita tbm de um sistema em VB6, no nosso sistema utilizamos javaFX2 e confesso que ele estava no inicio e penei muito para trabalhar com ele, não posso te dizer como ele está hoje mais com swing tenho certeza que vc irá implantar muito rápido, ainda mais se utilizar o netbeans que ja tem os componentes na mão.
Tenta usar como persistencia o hibernate para agilizar seu trabalho, tenta criar um sistema MVC para separar as coisas e boa sorte.

Refizemos aqui sistemas usando o SWT!
Primeiramente desenvolvemos uma arquitetura e alguns componentes para deixar a aplicação com layout agradável!
Depois fizemos o sistema seguindo a arquitetura, inclusive reaproveitando as camadas de negócio em módulos web.

O resultando foi muito satisfatório. Tirando o consumo de memória que por ser em Java é um pouco maior, o sistema roda perfeitamente em Linux e Windows (e acredito que possa rodar sem problemas em MAC), somente tendo que trocar a DLL nativa do SWT. Mas o tempo de resposta foi igual o muito melhor que do antigo VB. Sem dizer qualidade de código, ambiente de desenvolvimento e até mesmo usabilidade devido aos componentes que criamos.

Para auxiliar nas telas mais simples usamos o WindowBuilder e desenvolvemos tudo com Eclipse.

Na época fiz diversos testes com diversas tecnologias e como tinham telas muito pesadas praticamente impossiveis de se fazer em Web, o SWT por ser um toolkit nativo foi o que se saiu melhor!
Recomendo!!

Desenvolver em Swing não é difícil. Mas se quiser facilitar mais ainda as coisas, use o Netbeans, o desenvolvimento com ele será tão fácil quanto o Visual Studio para VB.

Migrar uma aplicação Desktop VB para Java não é tão trivial quanto você está pensando. Acontece que essas aplicações legadas costumam ter muitas dependencias com o Windows e outras coisas, como dispositivos seriais, impressoras fiscais, componentes de banco de dados obsoletos e outras coisas. Nesses casos, ao invés de Java, eu recomendaria migrar para .NET. Com .NET você consegue ter acesso a DLL’s, funcões de bibliotecas do Windows, portas seriais e outras coisas que com Java é demasiadamente complicada (acessar essas coisas com JNI não é um trabalho cristão e cria mais problemas do que resolve). Por tanto, se seu sistema tiver muitas dependências, considere migrá-lo para C# ao invés de Java.

Nao seria melhor aproveitar e fazer web? Tem algum requisito que impeça ser?

Aplicações com muitas dependências, como as que eu citei no meu post anterior, normalmente não são boas candidatas para serem web. Além do mais, por incrível que pareça, tem gente que não quer manter uma estrutura de servidor e acaba optando por soluções desktop, obviamente se a arquitetura da aplicação permitir essa escolha.

Quais dependências você se refere exatamente?

Pois é, tem TI que pára no tempo.

O JavaFX é para web. No seu caso como a idéia é um sistema Desktop pode utilizar o WindowBuilder.
Não gosto do Netbeans para parte gráfica embora muitos acima estão sugerindo.
O Netbeans suja muito o código dificultando a leitura.
Como você está acostumado com o VB desenvolva em Eclipse código limpo e interface do WindowBuilder parecida com o VB.

Bom dia,

Dei continuidade em um pequeno case CRUD usando Swing puro, tive que implementar um AbstratTableModel para manipular o JTable de forma mais simples, também houve a necessidade de criar componentes que facilitem o “Input” de valores como data, moeda.

Resumindo, dá um pouco mais de trabalho devido a necessidade de “personalizar” alguns componentes nativos do Swing.

Andei lendo e vi que existem os projetos OpenSwing e SwingX. Alguém que os conheça poderia definir melhor para mim ? No meu caso, que se trata de uma aplicação ERP seria recomendável ?

Qualquer sugestão para essa minha necessidade é bem vinda.

Desde já agradeço

Alguma consideração ou impedimentos sobre o que foi sugerido: SWT, JavaFx e Web(HTML)? Swing pode não ser a melhor das escolhas, dependendo do que detalhar mais sobre seu caso. Do mesmo jeito que Swing não é a melhor opção para IDEs.

E se o seu ambiente é Windows pode avaliar também .NET usando linguagem C# de preferência. Tipos de aplicações desktop no .NET: Windows Forms (similar a SWT) e WPF (similar a JavaFx). Web: ASP.NET MVC.

Dispositivos seriais, impressoras fiscais, dependências com funções do Windows e por aí vai.

Eu já trabalhei com Windows Form e WPF. Windows Form é interessante porque a programação é bem fácil. Mas ele não é tão bonito e também não é fácil de customizar. Já o WPF é bem mais poderoso e suporta mais recursos, como data binding, validation rules etc além de ser muito flexível para customizar. O ruim é que a programação em WPF é um pouco mais complexa.

Isso não tem jeito mesmo, as vezes por plugin, mas gera burocracia, então melhor desktop mesmo. Mas é preciso também avaliar quais módulos poderiam ser web e não fazer tudo desktop só por partes dependerem muito do SO, ainda mais se tratando de ERP, existem muitas divisões para cada “departamento”.

Também trabalhei com Windows Forms. Assim como SWT ele não foi feito para customizações, mas para atender padrão de UI do SO, então bonito ou não vai ser o tema do Windows de preferência do usuário. WPF nunca usei profissionalmente por ter me desligado do mundo desktop, mas temos a UI do Visual Studio como exemplo feito em WPF, creio que seja um tanto complexo quanto JavaFx, por seguirem uma mesma linha.

Também concordo que ele deveria mudar para .NET, seria o caminho mais natural e considerando também web para módulos que não houver impedimentos.

Swing é o fácil de não qualidade para o usuário final.

Olá Robinson boa tarde!

Prezado devido a ter pouco conhecimento em Java para me aventurar a fazer um projeto para produção mais sempre pesquisando, achei o OpenSwing o que me fez qse terminar um projeto com relativa agilidade ( que foi o que eu esperava qdo li a respeito do mesmo ) então achei sensasional, a parte ruim? suporte, comprei um livro, vi os tutoriais e acredito que o meu pouco Java me fizeram parar o tal projeto mais, continuo achando ele muito bom.

Há eu também recebi mensagens de erro ao escrever aki hoje.

Um Abraço!

Boa tarde a todos,

Obrigado pelas dicas.

Vamos lá, eu optei por desenvolver em JAVA devido a familiaridade com a linguagem. Eu tenho um conhecimento básico em C#, mas sinceramente, quero me desvicunlar um pouco da MS e deixa a aplicação mais independente de SO, mesmo sabendo que é possível rodar através do MONO(pessoalmente nunca vi).

Outra coisa que me levou a essa opção é o fato de ter que trabalhar com Impressoras Fiscais, portas seriais. Eu sei que é possível criar um applet para isso, mas realmente não quero aumentar tanto a complexidade da aplicação.

Eu já trabalhei com porta Serial no Java e geralmente dá problema. Você tem de disponibilizar o jar da RXTX, que é a biblioteca de manipulação de serial em Java, junto com a sua aplicação, ou seja uma dependência a mais.
E Applets são soluções que nem devem mais ser consideradas, já que o plugin do Java para os navegadores tem várias restrições de segurança.

Eu já cheguei a usar Mono (não profissionalmente, no entanto) e posso dizer que é uma alternativa interessante, caso precise fazer uma aplicação multiplataforma. A diferença é que ao invés de Windows Form, você tem o GTK# como toolkit gráfico. E ele suporta vários recursos, incluindo os mais atuais, como programação assincrona, ASP.NET MVC 3 (ASP.NET MVC 4 está a caminho) e outras coisas.

Bom, deixe-me fazer uma perguntinha. Sua aplicação tem muitas dependências? Poderia dizer quais?

Boa tarde,

Seria acesso serial e impressora fiscal.

Pois é, com C# essas coisas são relativamente triviais de acessar. Eu digo isso porque participei da migração de um sistema imenso escrito em Delphi. Nós migramos para C#. E o sistema fazia uso de porta serial, DLL’s de acesso a hardware, tolkens (aquelas chaves de segurança que parecem um pen driver) e não tivemos praticamente nenhum trabalho para chamar tudo isso no C#.

Sem falar que o Visual Studio é bem produtivo para desenhar as telas, bem parecido com o ambiente do Delphi e do VB.

Eu participei de um projeto em Java em que era necessário integrar o sistema com uma impressora fiscal da Bematech e posso dizer que foi bem trabalhoso. O componente para acessar a porta serial não é nativo do Java, é um projeto da comunidade que está parado há algum tempo. Sem falar que acessar a DLL da impressora no Java requer um bom trabalho com JNI, o que é um porre.

[quote=matheuslmota]Pois é, com C# essas coisas são relativamente triviais de acessar. Eu digo isso porque participei da migração de um sistema imenso escrito em Delphi. Nós migramos para C#. E o sistema fazia uso de porta serial, DLL’s de acesso a hardware, tolkens (aquelas chaves de segurança que parecem um pen driver) e não tivemos praticamente nenhum trabalho para chamar tudo isso no C#.

Sem falar que o Visual Studio é bem produtivo para desenhar as telas, bem parecido com o ambiente do Delphi e do VB.

Eu participei de um projeto em Java em que era necessário integrar o sistema com uma impressora fiscal da Bematech e posso dizer que foi bem trabalhoso. O componente para acessar a porta serial não é nativo do Java, é um projeto da comunidade que está parado há algum tempo. Sem falar que acessar a DLL da impressora no Java requer um bom trabalho com JNI, o que é um porre. [/quote]
Muito bom, foi uma escolha consciente.

Se o ambiente é Windows não tem por que complicar as coisas usando Java pra “se um dia ter Linux”, fora que na maioria das vezes licença de Windows é melhor investimento do que o Linux “de graça”.