| Autor |
Mensagem |
|
|
Ontem, antes desta sua resposta ter vindo, eu já tinha iniciado por conta própria o teste da instalação conforme vc citou...tb cheguei a mesma conclusão, o tamanho máximo é 32Kb.
Quanto ao Oxygen, vc conhece algo free ? Pois ele é pago...
Realmente não estão usando o obfuscator pois como é uma etapa opcional e realizo execuções seguidas do meu script Ant, quero que ele seja rápido e portanto preferi só deixar as etapas que eram necessárias.
Vou usá-lo sim e outra decisão que tomei foi que devido ao prazo que tenho para concluir, vou partir para uma programação menos elegante do que a que eu tinha, que usava design patterns, tudo, objetivando reduzir o código da aplicação, já que do jeito que está hoje tenho 10Kb e não tenho quase nada, portanto se eu quiser deslanchar, vou ter que nesta primeira versão, não querer ser tão perfeccionista e optar pelo código enxuto e direto.
Quanto a uma midlet chamar outra, como faz isto ?
Elas devem estar na mesma midlet-suite ?
valeu !
|
 |
|
|
Olá tanque,
No momento acabo de receber um 2280 para uso.
Gostaria de saber onde você viu que o tamanho da midlet não pode ultrapassar 32k.
E o tamanho máximo de um recordstore, vc tem idéia ?
Se isto for verdade vou ter que dar uma boa enxugada na aplicação pois ela do jeito que está (10 % feita, talvez) já beira 10k !
E isto porquê hoje tirei uma imagem do form principal justamente para dar uma aliviada no tamanho da aplicação por causa da cobrança que é feita em cima do tráfego gerado (tarifação). Quanto menos bytes, menos gasto.
Nunca tinha ouvido falar do Oxygen, mas vou dar uma olhada.
Instalei algumas midlets no 2280, tipo JBenchmark, Asteroids e outros e aparentemente está tudo certo.
A Nokia Brasil está pouco se importando com os desenvolvedores.
Já não é de hoje que vejo gente como eu, a deriva, buscando auxilio em qualquer outro lugar que não esta fabricante.
A que ponto chegamos !
Agora veja o caso da Nextel. Ela não fabrica, mas como operadora tem dado um bom suporte e divulgação a tecnologia e cada vez mais abocanhando os clientes corporativos.
Veja este exemplo:
http://www.nextel.com.br/w_mapa_rotas_br.htm
É ou não é legal que já se tenha algo desta maturidade aqui no Brasil ?
|
|
|
|
Me preocupo com isto pois quero rodar minha aplicação e uma máquina multi-processada e não gostaria que a JVM fizesse uso das green threads, visto elas não enxergarem mais de uma CPU...
Eu quero Native...
|
|
|
|
|
Tem.
|
|
|
|
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...
|
|
|
|
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.
|
|
|
|
Pois é...
Me dá uma ajuda:
Quero pegar o fonte dos arquivos FilterChain.java e Filter.java.
Eles estão no J2EE SDK ou em soft tipo o Tomcat ?
Quero adaptar elas para as minhas necessidades, pois pretendo ter filtros processando conteúdo que vem de um HttpConnection.
Na verdade uma classe seria a FilterManager que registro os filtros, a Filter que é a interface, e outras classes seriam propriamente a implementação do filtro.
Penso por enquanto em ter um filtro que comprime o stream e outro filtro que encrypta.
Alguma sugestão para isto e onde encontro o fonte dos arquivos acima?
valeu ! 
|
|
|
|
Li num site que o padrão Chain of Responsability, espera que somente um objeto na cadeia, manipule uma requisição, por exemplo.
Qual o padrão parecido com este, onde eu desejo que "n" objetos que implementam uma interface comum, processem a mesma requisição ?
Preciso implementar um tipo de cadeia de filtro, onde existe um objeto para ser processado por "n" filtros diferentes, cada um alterando ou não o conteúdo do objeto recebido e finalmente este objeto "transformado", vai ser passado para outro que vai usá-lo, e não vai saber destas transformações, ou seja, independente de haver filtros ativos ou não, ele sabe manipular o objeto recebido.
Eu tava vendo servelet filter e é isto que eu queria implementar..
obrigado.
|
|
|
|
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!
|
|
|
|
Tem como saber qual é implementação de Threads (Green ou Native) na JVM 1.4 para Windows ?
Li na Java Magazine que para máquinas mono-processadas, as green threads levariam mais vantagens sobre as native.
O artigo não esclarece o porquê. Alguém sabe ?
Sempre pensei que implementações nativas fossem mais rápidas do que emular isto, como é o caso das greens.
Se esta JVM implementa as 2 versões, qual o critério que ela usa para usar uma ou outra e como influenciar isto para o uso que se quer ?
Dentro da aplicação tem como saber que a máquina tem mais de um processador, para se não, avisar o usuário ou tomar alguma outra atitude ?
obrigado.
|
|
|
|
Olha, vc não precisa fazer o acoplamento, basta apenas instalar os módulos *.nbm ou via o Update Center...(São 4 ao todo, procure no site por J2ME).
Eu tentei usar o Netbeans para desenvolvimento em J2ME, mas fico frustrado, pois ele é por demais "pesado".
A única vantagem que leva em relação ao Gel (?) e ao Eclipse, é o debug da midlet, coisa que nem tive como testar pra valer.
Desisti e voltei ao usar o Eclipse com o Ant.
Tô pensando em abrir mão deste e para deixar as coisas mais rápidas, usar o Gel mesmo...
|
|
|
|
Acontece que você partir deste princípio, tardiamente estará familiarizado com a tecnologia...
Vou dar um exemplo:
Anos atrás eu ouvi falar sobre Java, mas assim como outras tecnologias, achei que seria modismo e nem dei muita importância, me concentrando em aprender outras coisas.
Um exemplo que me veio agora mesmo: Visual Objects e o dbFast - Computer Associates
Hoje a situação é bem diferente.
Se naquela época eu não tivesse parado de estudar, hoje eu taria dominando muito Java..
É a mesma coisa J2ME..se eu não comprasse um celular com suporte e não caisse de cabeça no assunto, e deixar para daqui algum tempo quando as coisas "estiverem mais fáceis", novamente vou estar em desvantagem.
Não adianta acreditar que só com o WTK você já poderá fazer suas aplicalções e testá-las pois não é bem por aí.
Nada como ter um celular real na mão para você sentir que o ambiente real é muito mais duro do que o virtual, e vc terá que brigar com sua operadora por preço do equipamento, preço da tarifa, suporte técnico,etc...coisas que quem usa emulador nem tem que se preocupar...no entanto, o mundo real é onde você realmente vai usar aquilo que desenvolveu.
Prefiro quebrar a cabeça agora do que novamente ficar pra trás.
Além de ter começado aprender por mim mesmo J2ME, no trabalho agora pintou a possibilidade de usar a tecnologia num projeto real.
Imagine a dor de cabeça que estou tendo, pois são muitos detalhes e no mercado poucos são os que dominam, poucas são as empresas que fornecem algum tipo de solução que realmente seja útil, os fabricantes de celular não te ajudam, enfim, mesmo com tantas dificuldades, vislumbro conseguir alcançar meu objetivo, num prazo curtíssimo, diga de passagem. Não que eu seja bom no assunto, mas com o que eu aprendi até aqui, com os colegas e por estudo próprio, vejo que meu problema não é um grande bicho papão...
Mesmo que aqui no fórum poucos são os que mexem realmente com J2ME, a ajuda que já tive até aqui tem me sido útil.
Embora sinta a falta por aqui de gente que realmente já implementou algo realmente e não ficou só naquela de usar o emulador, aqui tem sido um local muito bom para quem quer trocar idéias e buscar informações sobre o mercado brasileiro, que dificilmente você encontraria em outro lugar.
|
|
|
|
Cara vc não queria saber o parto que é ligar no Call Center da Nokia para "tentar" conseguir estas informações...
Além da demora, você encontra gente despreparada ou que não tem as mãos, TODAS as características dos produtos que a empresa fabrica !
Fiz três perguntinhas a respeito dos três modelos e constato no final, que não dá para confiar nos dados que foram passados.
Vejam só o que perguntei:
1) Qual a capacidade de memória total em Kb que o celular tem para armazenar aplicativos Java ?
2) Qual o tamanho máximo que um aplicativo Java pode ter ?
3) Qual as APIs suportadas e versões ? (CLDC, MIDP, Nokia UI API ?)
Enfim, as informações passadas são duvidosas e mais uma vez, vou preferir confiar nos colegas do que na própria fabricante, pois tenho notado que quem conhece mesmo são os usuários e estes sim, pode ajudar a quem tem dúvida.
Lamentável....
|
|
|
|
Alguém tem a capacidade de memória dos modelos Nokia 2280, 3586 e 6585 ?
Estou fazendo um levantamento de aparelhos CDMA que suportam Java para um projeto que estou envolvido e estou precisando destes dados.
Já li o manual, mas como de praxe, os fabricantes "esquecem"  de colocar isto nos manuais, dificultando ainda mais a vida de usuários e principalmente desenvolvedores.
Gostaria de saber a memória total, aquela que eu vou ter disponível, quando jogo fora todo os opcionais que já vem de fábrica como ícones, ringtones,agenda,etc, ficando a memória totalmente livre para usar para as midlets.
obrigado por qualquer ajuda.
|
|
|
|
Obrigado pelas respostas.
Não posso depender de API proprietária do fabricante X ou Y, até porquê, para determinar em run-time qual é o fabricante ou modelo do celular,não existe um modo padrão via MIDP.
Será que ninguém do fórum aqui desenvolve aplicações tendo por base celulares CDMA ?
|
|
|
|
|
|