Navegando pela documentacao da api Java ME, notei que não existe os recursos readObject(); e writeObject(); e talvez não seja possivel enviar ou receber objetos via socket. Minha dúvida é: Realmente não existe mesmo uma forma de fazer isso, ou existe alguma técnica, maneira… de faze-lo. Alguém já fez ou sabe como se faz?
Obrigado.
Serializa esse objeto e manda bala… 
[]'s.
Ele já é serializado, vem de um servidor Desktop. O servidor já o envia utilizando writeObject(meuObjeto); , porém não sei como recupera-lo do lado cliente em Dispositivo Móvel. Estou pesquisando isso, mas se alguém tiver mais alguma dica, será bem vinda.
Att.
Imagino que seja possível ler o objeto como um array de bytes e transformar esse array em um objeto do tipo que foi utilizado e enviado pelo servidor. É possivel?
Crie você mesmo um protocolo. Isso evita diversos problemas, mesmo no caso de aplicações desktop-desktop.
Eu nunca entendi pq o protocolo SIP é um protocolo “human-readable”. Sempre achei que fazer ele em texto um desperdício enorme de banda e de processamento. O volume de dados também é enorme, o que acaba forçando você a recorrer à uma ferramenta que faça um log melhor, como o wireshark (e que anexe também informações de sequenciamento e tempo, não presentes no protocolo por si só).
Ou seja, no final das contas, ser legível não ajuda em nada…
Estou trabalhando com um protocolo chamado FIX que tem mais ou menos o mesmo problema. Ele é assim:
8=FIX.4.4^9=295^35=D^34=20^49=XXX^52=20090414-13:45:59.076^56=XX00^11=1197569911574225^22=8^38=2000000^40=2^44=10^48=999000^54=1^55=XXXX0000^59=0^60=20090414-13:45:58^78=1^79=50020^661=99^207=XXXX^453=5^448=XXX^447=D^452=36^448=50020^447=D^452=7^448=XXX^447=D^452=54^448=XXX^447=D^452=12^448=50020^447=D^452=24^10=125^
onde ^ representa o caracter ASCII SOH (código 1).
Só que, mesmo sendo em modo texto, ele ainda é muito “pesado” para as aplicações. Fomos obrigados a usar uma representação binária, chamada FAST, que apesar do nome não é tão “fast” assim.
O mesmo vale para o protocolo NMEA, de GPS. Ele gera dados assim:
$GPGSA,A,3,04,05,09,12,24,2.5,1.3,2.1*39
Pelo menos é um protocolo leve, mas seria mais leve se fosse binário. Como a maior parte dos dados são números, você precisa fazer diversas conversões. Fora que dados GPS também são muitíssimo volumosos. Se seu interesse é só exibir um ponto num mapa, ok.
Agora, com certeza você terá que passa-los para o formato binário se quiser pós-processa-los.
Eu me baseei na ideia de serialização assim:
http://www.devmedia.com.br/articles/viewcomp.asp?comp=83
ai hj tenhu uma interface “serializavel” com 3 metodos dentro “getNomeClasse” que me retorna o pacote e o nome da classe (util para reflection no server-side), o metodo serializar que retorna um byte[] do conteudo do objeto, o metodo deserializar que recebe um byte[] e popula o objeto.
Uso essa interface tanto para transmissão de dados quanto para armazenamento de objetos em rms (Assim como no tutotial do link acima). Pra mim fica facil receber um objeto e já armazenar, ou resgatar um objeto do rms e já transmitir.
Mudei varias coisas de acordo com a necessidade e hj quase não tenho trabalho sobre isso, ainda mais porque fizemos um programa que gera o conteudo dos metodos serializar e deserializar. alem de classes especiais de input e output, que escrevem serializaveis e vetores de objetos seriais.
Abraços
Ricoldi
É que, basicamente, por parte do servidor, não vai dar pra fazer muita coisa, provavelmente nada. Pois a aplicação já é utilizada também por clientes desktop.
Se você pode mexer nos programas clientes, pode utilizar esse padrão neles tb e sempre transmitir só bytes.
Ou se você utilizou o padrão MVC pode usar uma porta/endereço para conversar via bytes.
Nesse caso, você terá que estudar mesmo como foi feita a serialização e desfazer o processo manualmente. Não conheço muito das APIs para mobile por aí, mas será que você não acha isso já implementado?
É, vou dar uma estdada com mais calma aki, estudar o material passado pelo ricoldi e vamo s ver no que que dá.