Colegas,
Preciso desenvolver uma aplicação que deverá rodar nas
plataformas J2SE e J2ME. Sou totalmente inexperiente em
J2ME mas, pelo que pude ver nas primeiras pesquisas que
fiz, a codificação da interface gráfica é muito diferente.
Então penso que devo montar a arquitetura desta aplicação
de maneira a deixar bem separada a parte de montagem
das telas para que o resto da aplicação seja igual, correto ?
Então a minha dúvida é se o design pattern que devo
empregar é o Command.
É este mesmo o caminho a seguir ? Alguma outra sugestão ?
Alguém já passou por este mesmo problema ? Como fez ?
Oque estudar J2EE vai ajudar para SE/ME? Não muito. Mas j2me muito menos.
maxsen, tentar usar o mesmo código em ambas plataformas vai ser muito dificil, pq ou voce vai estar matando seu dispositivo pequeno, ou limitando seu desktop.
Compartilhar interfaces e pouca coisa do código é viavel, mas nada muito alem daquilo que é reuso normal de código.
Ano passado desenvolvi uma aplicação que uma funcionalidade era compartilhada por um palm xumbrega e um desktop, não tive como reaproveitar muita coisa alem de algumas poucas classes básicas e as interfaces. Isso pq eu tinha 512mb ram + 1ghz de cpu no desktop e 4mb + 40mhz no palm (m515 é isso?).
Ou seja, enquanto no desktop posso abusar de collections, objetos gordos, gui rica, já no palm tenho que contar nos dedos os objetos criados e o tamanho deles.
Eu logo vi que a interface gráfica do j2me é bem ruinzinha
e que teria de fazer praticamente tudo em separado.
Na verdade as funcionalidades de UI desta aplicação são mais
simples mesmo mas não tinha prestado muita atenção nesse lance de
vigiar bem de perto o número de objetos na memória e coisas
do gênero…
E pelo andar da carruagem do j2me, ainda tá longe de se
aproximar do j2se, né, se é que vai se aproximar algum dia.
Eu tinha ouvido falar que o PersonalJava é bem mais parrudão
mas me parece que ele foi jogado para escanteio…
Colegas, alguém mais vivenciou situação parecida ?
O que o louds disse tem bastante sentido, e eu concordo com ele no geral, mas acho que faltou falar do maior motivo para nao se reaproveitar uma UI desktop num palm ou celular. Vou fazer uma comparacao rapida aqui entre o meu celular (que tem suporte a j2me) e o notebook que eu estou usando pra digitar esse post.
Celular:
Teclas de controle: 18
Teclas de entrada de dados: 12
Resolucao da tela: 176x208 (36.608 pixels)
Notebook:
Teclas de controle: 43
Teclas de entrada de dados: 45
Resolucao da tela: 1280x1024 (1.310.720 pixels)
Alias, vamos aproveitar pra comparar com um Palm bom (Tungsten T3, o sonho de consumo do Paulo):
Teclas de controle: 13
Teclas de entrada de dados: 0 (reconhecimento de escrita)
Resolucao da tela: 320x480 (153.600 pixels)
Concorda que sao usos totalmente diferentes? Mesmo que pareca ser uma boa ideia reaproveitar, nesse caso reaproveitar codigo custa mais caro: ou vc acaba com uma UI desktop ruim, ou com uma J2ME impossivel de usar.
Tem um pessoal que estuda componentes adaptativos e gosta de fazer softwares que “conhecem o ambiente em que rodam e podem adaptar-se a ele, escolhendo protocolos, algoritmos, formatos, etc baseado nos recursos disponíveis”.
Se vc tá com tempo de pastar um pouco, vc pode colocar as várias GUIs num JAR só (ou fazer o esquema core.jar + desktop.jar + micro.jar), e escolher o que vc quer usar baseado no ambiente que vc está rodando.
Minha sugestão é padronizar o “esqueleto” do programa de modo que a funcionalidade independa da interface gráfica, e carregar a GUI com reflection. Mas falar é fácil, e “there is no free lunch”.
Boa sorte mesmo, não da nem pra emular reflection, já que as JVMS CLDC não tem suporte nem a class loaders.
Fazer a seleção em runtime é inutil, dado que nunca vão existir 2 opções.
Nem São Nunca vai fazer teu dispositivo j2me carregar javax.swing ou teu desktop com j2se javax.microedition.
Esta minha aplicação é bem simples no que tange à UI, olhem só :
É um tipo de questões de prova, ou seja, voce tem um textarea com
uma pergunta e depois uns radio groups com as possíveis
respostas, e por aí vai até o fim da prova. Depois tem a
correção das questões. Então não é muito complicado.
Claro que se pode incrementar um bocado, colocando cronômetro,
dicas e etc mas isso ficaria para depois.
E o ambiente j2me será somente Palm, nada de celular, pelo
menos por enquanto.
O que eu tinha pensado no início seria uma coisa menos ao estilo
de reflection, como por exemplo ler um arquivo de properties para
saber em qual ambiente estou daí pedir para montar a UI de um
j2me ou então pedir para montar uma UI de j2se.
Por isso tinha pensado que entraria aí o design pattern Command.
Aí, as respostas dos usuários chegariam sempre por um mesmo
lugar e as classes de negócio as processariam “normalmente”…
Mas já vi também que j2me não tem a api de properties.
Embora não tenha properties, você pode criar uma classe Properties se baseando no código fonte do J2SE, e internamente trabalhando com Recordstore. Nada difícel de se fazer.
Quanto a design patterns para J2ME, existe raros links sobre o assunto.
No site Javaworld você encontrará um que traz 4 abordagens no gerenciamento de telas.
Eu mesmo aos trancos e barrancos, na medida do possível estou estudando os design patterns e procurando aplicá-los no desenvolvimento em J2ME.
Por exemplo, na controle das telas, eu noto que a maioria esmagadora dos exemplo, cria todas as telas e objetos logo na inicialização da midlet.
Acho isto ruim, devido a não necessidade de todas as telas logo de cara, além do consumo de memória e lentidão na inicialização. Imagina a pessoa sair e entrar na aplicação várias vezes ao dia ?
Por isto neste caso, eu uso o Factory Pattern, com um cache que guarda as telas instanciadas para reuso e com isto consigo gerenciar a criação delas, evitando mais de uma instância durante o ciclo de execução da aplicação e também aplicar a técnica lazy instation, que é de só criar os objetos somente quando necessário.
Continue estudando os designs patterns. Realmente vale a pena!
Pois é, embora a SUN e os evangélicos do Java façam um barulho
enorme em relação ao J2ME, aplicações para celulares, palms
e algum dia até para a sua bicicleta , neste meu primeiro
contato e pesquisas tenho tido algumas surpresas desagradáveis.
Um outro pattern que estou adaptando é para a comunicação entre o celular e o webserver.
Vou usar o Chain of Responsability, onde terei filtros que irao processar o conteudo, tipo, adicionando encritação e compactação, seriam os primeiros usos…
Fica facil depois desabilitar estas coisas para efeito de debug ou mesmo colocar novos filtros…
Falando sobre o Factory ele me ajuda pois nas chamadas as telas, eu uso o Factory para mostrar a janela. Se ela existir ele pega do cache e devolve a referencia, se nao, instancia e guarda no cache e tb me devolve uma referencia. Uma tela só acessa outra atraves da Factory. Nunca através de setDisplay.
Na verdade melhor dizendo é que eu tenho uma funcao showWindow que recebe o nome da classe da janela e pede a Factory que devolva uma referencia a esta janela.
A factory ou retorna do cache uma se existir ou cria e retorna.
A Factory gerencia as telas e a funcao centraliza as chamadas.
Faço isto porque quando se fala em midlet, é facil facil termos mais de uma instancia de uma janela se nao tivermos cuidado com o new…
E instancias a toa na memoria nao é um luxo que dá para se ter em se tratando de midlet…
Mesmo que pareca ser uma boa ideia reaproveitar, nesse caso reaproveitar codigo custa mais caro: ou vc acaba com uma UI desktop ruim, ou com uma J2ME impossivel de usar.