Seguinte… estou desenvolvendo um aplicativo utilizando a VM phoneME feature (CLDC) para dispositivos com Windows CE.
Essa minha aplicação faz algumas importações de informações do banco por meio de rede sem fio e as persistem por meio de RMS.
O problema é que quando eu importo essas informações (cerca de 1Mb…por enquanto, pois vai crescer mais) acontece um erro de estouro de memória. (OutOfMemoryError).
Alguém já passou por esse problema?
Alguém tem uma solução?
1- Reveja sua estratégia de comunicação.
2- Procure sempre trabalhar com váriaveis ao invés de objetos.
3 - Se trabalhar com objetos, evite a criação continua e destruição dentro de loops. Não ache que System.gc() vai te salvar a pele, pois pode não ajudar muito.
4 - O que te leva a usar J2ME ao invés do .Net CF ? Sim, sou um eterno defensor de J2ME somente em celulares e nada de PDAs, pois vejo que se em celulares já passamos algumas poucas e boas, imagine no PDA que o suporte é pior…
1 - Aplicativo solicita a informação para um servidor web que realiza uma consulta no banco de dados, filtra a informação e me trás apenas o desejado, porém o desejado é MUITA informação. (Exemplo: tabela com duas colunas e cerca de 40.000 linhas… essa é a maior);
2 - Creio que aqui não seria o ponto pois o problema acontece ao importar os dados os quais pego por meio de uma String JSON;
3 - Estou ciente;
4 - Três pontos:
Primeiro: como é um projeto para a empresa a qual trabalho, existe a idéia de desenvolvimento em uma linguagem a qual a equipe de desenvolvimento conheça (Java).
Segundo: oferece recursos free para o desenvolvimento (ponto forte para decisão da coordenação de desenvolvimento) e
Terceiro: Não que eu não tenha tentado mas foi uma decisão que veio de cima, então…
Creio que quado carrego minha String JSON (com aproximadamente 1MB) na aplicação, a memória estoure antes que eu a possa persistir.
[quote=rafdutra]
Creio que quado carrego minha String JSON (com aproximadamente 1MB) na aplicação, a memória estoure antes que eu a possa persistir.[/quote]
Este é o ponto.
Quando apontei o item 1 (rever a estratégia) significa exatamente que não pode receber 1 MB e encher a memória.
O certo para lidar com qualquer quantidade de dados é ir processando por partes, ou seja, leia da rede 100 kb, processe…depois mais 100, processe…e assim por diante até acabar tudo.
Esta estrategia te permite manipular a quantidade que quiser, pois nunca vai estourar a memoria, pois o teu buffer (o array de recepção de dados, tem tamanho fixo) pode ser reusado em multiplas leituras sem problema.
Bom, se a estratégia que definiram foi esta fazer o que né…com .Net vc tambem desenvolve free (não precisa do visual studio)…é o mesmo que o Java…acho que este argumento cai por terra, mas enfim…
Bom, até pensei em separar por partes menores a minha informação porém não sei como fazer isso =p
Hoje funciona da seguinte maneira:
1- O aplicativo solicita a informação por meio de webservice;
2- Servidor recebe solicitação e realiza consulta no banco;
3- Servidor cria String JSON com informações retornadas da consulta;
4- Servidor devolve a String para o aplicativo (do dispositivo móvel).
O que eu penso em tratar para dividir em partes menores seria o passo 4 onde o servidor devolveria a informação sobre demanda, ou seja, a partir do momento em que o cliente processa a informação. Mas não sei se existe a possibilidade de fazer isso com WebService.
Estou errado??
Caso contrário como faria isso?
Obs:
Boone, programar em .NET realmente não teria custos, porém custos de desenvolvimento, mas haveria custos para treinamentos e no momento não seriam viáveis para uma soluçao isolada como essa!
Muito legal esse tópico, me ajudou a entender algumas coisas, porém nele é discutido aplicativos CDC, usando a phoneME Advanced.
Eu estou usando a Feature para trabalhar com MIDlets. Já tentei usar a DUAL mas não tive sucesso!
Você saberia me dizer como configurar esses parâmetros para phoneME Feature ou Dual??
O lance não é do lado do servidor e sim o cliente. É na midlet que você vai especificar no método read, que quer ler os tal 100Kb, por exemplo.Só isto.
Me expressei mal. O que eu quis dizer com o “devolveria a informação sobre demanda” é exatamente isso, quem controla é o MIDlet, onde ele requisita os primeiros 100k, processa, grava, e depois solicita outros 100k, processa, grava, etc.
O problema é como fazer isso depois que a consulta já foi realizada e a String JSON montada!!
Bom, se tu não consegue consumir as coisas pouco a pouco usando um mega-objeto JSON, pode melhor trocar o protocolo para alguma coisa que lhe deixe processar as coisas pouco a pouco, a la “streaming”.
Me expressei mal. O que eu quis dizer com o “devolveria a informação sobre demanda” é exatamente isso, quem controla é o MIDlet, onde ele requisita os primeiros 100k, processa, grava, e depois solicita outros 100k, processa, grava, etc.
O problema é como fazer isso depois que a consulta já foi realizada e a String JSON montada!!
COMO? Eis a questão![/quote]
Quem vai montar a string JSON é o servidor e ele vai enviar no fluxo.
Vc le trecho-a-trecho com read, grava, le mais um pouco, grava e assim por diante.
Não entendo claramente onde esta o problema.
E do lado midlet quem vai processar este JSON ? Digo, nao existe Javascript, entao qual a vantagem de usar este formato para representar informacao ?
A idéia do Streaming não sei se da certo pois o problema é se eu escrever um pedaço da informação e ao chegar no cliente ela estiver cortada ao meio. Exemplo:
Quando eu mandar o tamanho fixo dai pode acontecer de eu mandar a informação:
Cliente 1
Cliente 2
Clie
Ou eu to viajando?
Boone. O por que de usar JSON é apenas para padronizar (e facilitar) a forma de envio de informação entre o cliente e servidor e também ter uma alternativa menor que XML.
A idéia do Streaming não sei se da certo pois o problema é se eu escrever um pedaço da informação e ao chegar no cliente ela estiver cortada ao meio. Exemplo:
Quando eu mandar o tamanho fixo dai pode acontecer de eu mandar a informação:
Cliente 1
Cliente 2
Clie
Ou eu to viajando?
Boone. O por que de usar JSON é apenas para padronizar (e facilitar) a forma de envio de informação entre o cliente e servidor e também ter uma alternativa menor que XML.
[/quote]
Quanto a rotina receber ‘cortado’ é evidente que vai acontecer, mas cabe a ela, perceber quando tem uma entidade inteira para poder fazer um addRecord, por exemplo. É tranquilinho de tudo fazer isto, mel na chupeta mesmo…
Vou tentar desenvolver o método de chamada no cliente para que seja feito várias chamadas com retornos menores.
Caso não resolva vou tentar implementar o fluxo!!
Mas ainda continuo procurando uma solução para aumentar a memória da VM!!
[quote=rafdutra]Vou tentar desenvolver o método de chamada no cliente para que seja feito várias chamadas com retornos menores.
[/quote]
Nossa…ao invés de resolver o problema vc está contornando-o…credo ! :?
Vc ja tem um fluxo, que é tudo que é lido pelo inputStream.
O que parece que vc não entendeu é que após ter feito o read para os bytes no buffer, vc deve analisar o buffer e ir descobrindo entidades inteiras e colocando no seu banco. Os bytes que sobrarem, se referem a proxima entidade que ainda esta por vir, no proximo read e assim por diante…é só ir concatenando, processando, gravando, lendo de novo e assim vai…