A 3 anos, eu pesquisei sobre j2me(nome usado na epoca!) para uma solução em palm, fiz meu dever de casa com uma pequena app usando a j9 da ibm e outra com o superwaba, no final escolhi superweba por questões de performance.
bem hoje tenho que fazer uma app. para celular e terei que usar jme mesmo, como apenas pesquisei na epoca mas não fiz uma app completa gostaria de saber:
como esta jme hoje? (recursos.melhorias)
posso usar classes com get e set ( na epoca o pessoal recomandava tudo public para ganhar perfomance)
posso modularizar a app tipo uma classe por tela? ou tudo num .java só? ( isso tambem referente a perfomance e capacidade do jme)
posso criar algo em background? threads etc
Não sei como estava a 3 anos, afinal eu programo em j2me apenas a 1 ano. Obviamente depende muito do vai querer fazer com ele. Atualmente creio que os celulares (E digo isso porque utilizo N modelos diferentes desde v3, n95, Sansung SGHi617, sony K750) estão muito mais completos em relações a JSR’s e na propria KVM (normalmente MIDP 2.0) OK!
[quote]posso usar classes com get e set ( na epoca o pessoal recomandava tudo public para ganhar perfomance)
posso modularizar a app tipo uma classe por tela? ou tudo num .java só? ( isso tambem referente a perfomance e capacidade do jme)[/quote]
Eu utilizo encapsulamento tranquilamente em todas as aplicações que faço, e não só encapsulamento, uso herança, polimorfismoe todas as outras, só não consigo usar reflection com obliteração de código.
Cada tela minha extende uma classe, seja form, list, canvas, ou alguma que eu fiz que herda de canvas tambem.
e roda tranquilamente. OK!
Em todas as chamadas de comandAction que faço coloco em threads, fora as threads que costumo rodar para melhorar tempos de resposta. OK!
Não só performance, mas tamanho da aplicação.
No passado era recomendado não usar, não que não podia.
Hoje tá mais tranquilo afinal os celulares estão mais poderosos.
Sempre fiz isto…e não tem problema, tirando que isto impacta no tamanho do JAR…quanto mais classes/telas, maior o JAR
Pode, mas só precisa realmente para operações que envolva leitura/escrita no sistema de arquivos, comunicação HTTP/Bluetooth ou melhorar o tempo de resposta devolvendo rapidamente o controle da UI para o usuário ao invés de esperar estando bloqueado por uma operação demorada.
Não mudou muita coisa. Surgira novas plataformas de desenvolvimento, mas o J2ME em si continua a mesma coisa. Não me lembro de alguma API muito expresiva que tenha surgido nesse meio tempo, mas sempre surgem algumas pequenas ferramentas que ajudam em alguma coisa. As IDEs, por exemplo, melhoraram bastante a compatibilidade com J2ME.
Alias, a Sun lançou recentemente uma nova versão da plataforma de desenvolvimento do J2ME e estamos todos na torcida para que saia a especificação da MIDP 3.0, mas isso arece que ainda vai dar “pano para manga”.
Tornar tudo público e diminuir o número de classes sempre vai melhorar a performance, porém isto já não impacta taaannnto nos novos aparelhos.
Rico? com certeza ainda mais se falando em preços de aparelhos que suportem a Lightweight… creio que a maioria das pessoas não possuem celulares com capacidade de processamento para a suportar a Lightweight aqui no brasil. Em casos de programas especificos para determinados aparelhos, pode-se analisar a carga do Lightweight, porem mesmo em aplicações para aparelhos robustos, particularmente aqui na empresa optamos por construir em canvas, visto que a interface fica totalmente personalizada e sem falhas devido ao aparelho especifico. Porem em casos de programas para aparelhos variados, vejo um grande problema na Lightweight como eu já tinha comentado acima.
Talvez a solução seja disponibilizar diferentes versões do mesmo .jar para cada conjunto de aparelhos…[/quote]
Dependendo do aplicativo a solução é essa.
Mas a questão é o uso da LWUIT que fica descartada na maioria dos aparelhos, como eu disse, prefiro canvas…(Apesar de ficar mais complicado trabalhar com varias resoluções).