Boa tarde pessoal!
Alguém conhece alguma API para JME de Interface Gráfica no estilo de Vaadin ou Flex?
Boa tarde pessoal!
Alguém conhece alguma API para JME de Interface Gráfica no estilo de Vaadin ou Flex?
LWUIT, se tiver um aparelho potente, pois consome muito processamento.
Uma boa alternativa é vc estudar canvas e fazer sua própria API.
[quote=j0nny]LWUIT, se tiver um aparelho potente, pois consome muito processamento.
Uma boa alternativa é vc estudar canvas e fazer sua própria API.[/quote]
Os aparelhos de hoje em dia suportam bem o LWUIT e mesmo assim vc não precisa ter um aparelho tão potente assim para rodá-lo . Hoje em dia o LWUIT está na versão 1.3 e está mais rápido e leve que a primeira versão(1.1) além de novas funcionalidades como teclado virtual e algumas outras otimizações para aparelhos touchscreen. E vc tb não é obrigado a utilizar todos os seus recursos, basta criar uma aplicação sem efeitos e temas simples caso deseje uma aplicação mais leve. Tb algumas pessoas reclamam do tamanho do .jar que ele gera, para aliviar esse problema vc pode utilizar um ofuscador de código, que reduz em até 40% o tamanho do .jar.
De fato, o bom utilizamento do framework vai depender da criatividade do programador, eu particularmente acho bem melhor utilizar o LWUIT do que ficar desenhando tela em Canvas, ainda mais tendo em vista que hoje em dia temos celulares com Android e o IPhone que possuem interfaces ricas proporcionando uma experiência ao usuário incrível, e o LWUIT é arma da sun não para fazer frente, mas pelo menos para não ficar muito atrás dessas novas tecnologias e evitar a “morte” do Java ME.
Site do LWUIT:
http://java.sun.com/javame/technology/lwuit/
Blog de um dos criadores do framework:
http://lwuit.blogspot.com/
[quote=OliveirakunJava][quote=j0nny]LWUIT, se tiver um aparelho potente, pois consome muito processamento.
Uma boa alternativa é vc estudar canvas e fazer sua própria API.[/quote]
Os aparelhos de hoje em dia suportam bem o LWUIT e mesmo assim vc não precisa ter um aparelho tão potente assim para rodá-lo . Hoje em dia o LWUIT está na versão 1.3 e está mais rápido e leve que a primeira versão(1.1) além de novas funcionalidades como teclado virtual e algumas outras otimizações para aparelhos touchscreen. E vc tb não é obrigado a utilizar todos os seus recursos, basta criar uma aplicação sem efeitos e temas simples caso deseje uma aplicação mais leve. Tb algumas pessoas reclamam do tamanho do .jar que ele gera, para aliviar esse problema vc pode utilizar um ofuscador de código, que reduz em até 40% o tamanho do .jar.
De fato, o bom utilizamento do framework vai depender da criatividade do programador, eu particularmente acho bem melhor utilizar o LWUIT do que ficar desenhando tela em Canvas, ainda mais tendo em vista que hoje em dia temos celulares com Android e o IPhone que possuem interfaces ricas proporcionando uma experiência ao usuário incrível, e o LWUIT é arma da sun não para fazer frente, mas pelo menos para não ficar muito atrás dessas novas tecnologias e evitar a “morte” do Java ME.
Site do LWUIT:
http://java.sun.com/javame/technology/lwuit/
Blog de um dos criadores do framework:
http://lwuit.blogspot.com/[/quote]
Bom, se for fazer para smartphone não vai sentir a diferença, mas rode em um celular mais popular pra vc sentir a realidade.
Bom, quem quer faz, e posso falar uma coisa, fazendo vc msm com Canvas, vc conseguira muito mais desempenho com muito mais qualidade visual.
[quote=j0nny]
Bom, se for fazer para smartphone não vai sentir a diferença, mas rode em um celular mais popular pra vc sentir a realidade.
Bom, quem quer faz, e posso falar uma coisa, fazendo vc msm com Canvas, vc conseguira muito mais desempenho com muito mais qualidade visual.[/quote]
Mas vale lembrar que a tendência é as pessoas trocarem seus aparelhos por modelos mais novos. Se vc ja tem sua própria api em canvas, então tudo bem, mas pra quem ta começando eu não vejo sentido em estudar uma tecnologia que ja está ultrapassada. O desempenho em Canvas pode até ser melhor, mas atingir a mesma qualidade visual do LWUIT é bem difícil hein…
[quote=OliveirakunJava][quote=j0nny]
Bom, se for fazer para smartphone não vai sentir a diferença, mas rode em um celular mais popular pra vc sentir a realidade.
Bom, quem quer faz, e posso falar uma coisa, fazendo vc msm com Canvas, vc conseguira muito mais desempenho com muito mais qualidade visual.[/quote]
Mas vale lembrar que a tendência é as pessoas trocarem seus aparelhos por modelos mais novos. Se vc ja tem sua própria api em canvas, então tudo bem, mas pra quem ta começando eu não vejo sentido em estudar uma tecnologia que ja está ultrapassada. O desempenho em Canvas pode até ser melhor, mas atingir a mesma qualidade visual do LWUIT é bem difícil hein… [/quote]
E o que impedirira do Canvas funcionar?
Olha, sinceramente, o visual do LWUIT não é la grandes coisas, já vi várias pessoas com aplicações em Canvas que dão um show no LWUIT, não gosto de ficar babando ovo por um framework, até pq, testado em celulares mais populares, percebe-se a quantidade de processamento que ele consomo. E não são apenas testes meus, pessoas + experientes aqui no GUJ tbm relatam isso. :thumbup:
E uma pergunta, vc axa que o LWUIT é feito com o que? :lol:
Eu sei que ele é feito com Canvas, mas pq vou criar algo que já existe? Seria o mesmo que tentar reiventar a roda. Se vc ja tem suas apis prontas em Canvas, então use-as, sem problema.
Eu particularmente só desenvolveria algo em Canvas se fosse para algum fim específico ou se desenvolvesse aplicativos voltados para o mercado de celulares populares de baixo custo. Caso contrário acharia melhor utilizar este tempo estudando tecnologias mais novas como desenvolvimento para Android, IPhone ou o próprio LWUIT. Bom essa é a minha opinião 
[quote=OliveirakunJava]Eu sei que ele é feito com Canvas, mas pq vou criar algo que já existe? Seria o mesmo que tentar reiventar a roda. Se vc ja tem suas apis prontas em Canvas, então use-as, sem problema.
Eu particularmente só desenvolveria algo em Canvas se fosse para algum fim específico ou se desenvolvesse aplicativos voltados para o mercado de celulares populares de baixo custo. Caso contrário acharia melhor utilizar este tempo estudando tecnologias mais novas como desenvolvimento para Android, IPhone ou o próprio LWUIT. Bom essa é a minha opinião
[/quote]
A minha resposta é:
Pq nem sempre disponho de tanto processamento, e quando disponho, prefiro utilizá-lo para outros fins na aplicação.
E vamos e viemos, o LWUIT é feinho.
A questão nem é tanto feiura e sim overhead. Vc usa 1 classe e vem no JAR tantas outras que esta q usou depende delas…
Ou seja, faça uma app de 1 Kb, que nos finalmente vira 350 Kb e mande o usuário baixar ela em 300 celulares. A operadora vai adorar te cobrar…
Se vc “reinventa a roda”, fazendo seus próprios componentes, economiza neste tamanho final, caindo para 5 Kb, o que acaba posteriormente economizando din-din.
Além disto, a performance da aplicação tb é melhor.
Deu para perceber que também não gosto do LWUIT, né ?
Pois é…os benefícios alegados ao meu ver não compensam para os desenvolvedores e usuários brasileiros…
[quote=boone]A questão nem é tanto feiura e sim overhead. Vc usa 1 classe e vem no JAR tantas outras que esta q usou depende delas…
Ou seja, faça uma app de 1 Kb, que nos finalmente vira 350 Kb e mande o usuário baixar ela em 300 celulares. A operadora vai adorar te cobrar…
Se vc “reinventa a roda”, fazendo seus próprios componentes, economiza neste tamanho final, caindo para 5 Kb, o que acaba posteriormente economizando din-din.
Além disto, a performance da aplicação tb é melhor.
Deu para perceber que também não gosto do LWUIT, né ?
Pois é…os benefícios alegados ao meu ver não compensam para os desenvolvedores e usuários brasileiros…[/quote]
Falou tudo!
Eu não vejo problemas também em fazer algumas costumizações de componentes utilizando Canvas ou CustomItem. O LWUIT o processamente dele lente, testei em algumas smarthphones e vi que não é la grande coisa. Então eu prefiro utilizar a API padrão e customizar os meus proprios componentes.
[quote=boone]A questão nem é tanto feiura e sim overhead. Vc usa 1 classe e vem no JAR tantas outras que esta q usou depende delas…
Ou seja, faça uma app de 1 Kb, que nos finalmente vira 350 Kb e mande o usuário baixar ela em 300 celulares. A operadora vai adorar te cobrar…
Se vc “reinventa a roda”, fazendo seus próprios componentes, economiza neste tamanho final, caindo para 5 Kb, o que acaba posteriormente economizando din-din.
Além disto, a performance da aplicação tb é melhor.
Deu para perceber que também não gosto do LWUIT, né ?
Pois é…os benefícios alegados ao meu ver não compensam para os desenvolvedores e usuários brasileiros…[/quote]
Ok boone, eu entendi o seu ponto de vista mas veja bem:
- O usuário pode baixar a aplicação no computador e transferir para o celular via bluetooth ou cabo usb;
- O usuário pode baixar a aplicação via Wi-fi ou 3G(se o celular possuir estes recursos, óbvio..)
Se o usuário utilizar algum dos modos que citei acima(e dependendo do plano dele, no caso do 3G) ele foge da tarifação das operadoras e o tamanho do jar não vai ser um empecilho. Eu percebi que o pessoal que está acostumado a desenvolver em canvas não gostou muito do LWUIT, mas tudo bem, eu respeito o ponto de vista de vcs mas como ja disse antes, eu tenho uma opinião diferente.
[quote=OliveirakunJava][quote=boone]A questão nem é tanto feiura e sim overhead. Vc usa 1 classe e vem no JAR tantas outras que esta q usou depende delas…
Ou seja, faça uma app de 1 Kb, que nos finalmente vira 350 Kb e mande o usuário baixar ela em 300 celulares. A operadora vai adorar te cobrar…
Se vc “reinventa a roda”, fazendo seus próprios componentes, economiza neste tamanho final, caindo para 5 Kb, o que acaba posteriormente economizando din-din.
Além disto, a performance da aplicação tb é melhor.
Deu para perceber que também não gosto do LWUIT, né ?
Pois é…os benefícios alegados ao meu ver não compensam para os desenvolvedores e usuários brasileiros…[/quote]
Ok boone, eu entendi o seu ponto de vista mas veja bem:
- O usuário pode baixar a aplicação no computador e transferir para o celular via bluetooth ou cabo usb;
- O usuário pode baixar a aplicação via Wi-fi ou 3G(se o celular possuir estes recursos, óbvio..)
Se o usuário utilizar algum dos modos que citei acima(e dependendo do plano dele, no caso do 3G) ele foge da tarifação das operadoras e o tamanho do jar não vai ser um empecilho. Eu percebi que o pessoal que está acostumado a desenvolver em canvas não gostou muito do LWUIT, mas tudo bem, eu respeito o ponto de vista de vcs mas como ja disse antes, eu tenho uma opinião diferente.
[/quote]
Mas no desenvolvimento mobile, geralmente as aplicações são disponibilizadas num servidor e baixadas via WAP, etc.
Pois é esta a realidade…
…o que o Oliveira cita é que não é o comum…
Bom,
vou dar minha opinião baseada em um teste de conceito que fiz recentemente sobre o LWUIT.
Eu fiz uma aplicação de teste que tinha 46 classes + 1 arquivo .res(32kb) + 6 imagens .png (4kb) e o jar ficou com 359Kb.
Testei essa aplicação nos seguintes celulares: Nokia E71, Nokia E65, Sony Ericson w580i e Motorola W396.
Claro que o desempenho no motorola não foi igual ao do E71, mas a aplicação rodou.
Nos mais potentes, eu sequer senti a aplicação lenta. A versão 1.3 ta muito boa (não usei as anteriores).
Acho que como tudo na vida, depende de cada caso. Se há mais de uma versao do software a ser mantida e poucos recursos humanos e de tempo, porque manter uma aplicação e uma biblioteca pra GUI sabendo que existe um framework que poderia reduzir metade do trabalho?
Claro que dá pra economizar os recursos que o LWUIT gastar se fizesse tudo com Canvas e investir em um numero maior de funcionalidades, mas se formos pensar assim, poderiamos voltar a programar com C/C++ pra economizar os recursos de processamento que a JVM gasta (esse era o discurso de um professor que eu tive e que era extremamente contra-java… hehehehe).
O que eu queria dizer é: Dependendo das suas necessidades, o LWUIT vai atender ou nao. Pra saber isso, faça um teste!
[quote=ketemartinsrufino]Bom,
vou dar minha opinião baseada em um teste de conceito que fiz recentemente sobre o LWUIT.
Eu fiz uma aplicação de teste que tinha 46 classes + 1 arquivo .res(32kb) + 6 imagens .png (4kb) e o jar ficou com 359Kb.
Testei essa aplicação nos seguintes celulares: Nokia E71, Nokia E65, Sony Ericson w580i e Motorola W396.
Claro que o desempenho no motorola não foi igual ao do E71, mas a aplicação rodou.
Nos mais potentes, eu sequer senti a aplicação lenta. A versão 1.3 ta muito boa (não usei as anteriores).
Acho que como tudo na vida, depende de cada caso. Se há mais de uma versao do software a ser mantida e poucos recursos humanos e de tempo, porque manter uma aplicação e uma biblioteca pra GUI sabendo que existe um framework que poderia reduzir metade do trabalho?
Claro que dá pra economizar os recursos que o LWUIT gastar se fizesse tudo com Canvas e investir em um numero maior de funcionalidades, mas se formos pensar assim, poderiamos voltar a programar com C/C++ pra economizar os recursos de processamento que a JVM gasta (esse era o discurso de um professor que eu tive e que era extremamente contra-java… hehehehe).
O que eu queria dizer é: Dependendo das suas necessidades, o LWUIT vai atender ou nao. Pra saber isso, faça um teste![/quote]
Ah claro, testando num Nokia E71 tudo fica rápido, é apelação né?
Teste num Nokia 2720 :lol:
Esses dias testei uma aplicação que desenvolvi com lwuit em um celular xing-ling e rodou perfeitamente! Fiquei até com vontade de comprar um desses só pra testes mesmo, apesar deles suportarem somente as APIs básicas. Mas esses celulares realmente me surpreenderam 
Putz…
Eu coloquei 4 modelos de celulares, que iam desde uns excelentes até uns mais populares.
Só pra constar, o desempenho com o motorola w396, que tem 7.5 Mb de memoria interna (o Nokia 2720 tem 32Mb), foi regular. Com isso quero dizer, que do jeito que tá dá pra usar. Além disso, meu código não está exatamente otimizado ( :oops: )…
Ahhh, e eu esqueci, eu tb testei com o Nokia E62 e com o HTC Touch Dual P5530, o touch funcionou sem eu precisar configurar nada, e o suporte i18n deles tá ótimo. É só setar um atributo pra true e ele inverte os textos, os menus, os checkbox…
Mas como nosso amigo disse: se for pra rodar com um xing-ling e o sistema precisar fazer suco de laranja, é melhor usar o Canvas mesmo e pintar pixel a pixel na tela.
Eu só queria que quem estiver pensando em uma ferramente de fácil utilização para construção de GUI em JME, dessem uma olhada no LWUIT antes de desistirem ao verem um “Não presta.”, “É lento demais.”.
Até! 
Existem mais opniões contra do que a favor deste framework, mas isto não significa que ele é de todo mal, mas sim que não atende a parcela brasileira dos desenvolvedores pelo simples fato de ser desenvolvido para celulares cujo padrão é de 1o mundo.