Olá,
estou portando uma aplicaÇão feita para SE para o ME (SIM, ESTÁ SENDO UM INFERNO!). E quando eu pensei que estava tudo resolvido, eu não consigo rodar porque é levantada essa exception:
Isso se deve ao fato dessa aplicação usar Sockets.
to virando a net do avesso pra ver se encontro um jeito de me livrar disso. Por enquanto nada. Estou rodando no WTK 2.2 em linux. Já alterei todas as propriedades possíveis e imagináveis do Security, já adicionei permissoes direto no .jad do midlet e até agora nada funcionou.
li em algum lugar que eu teria de “assinar” esse midlet. Alguém sabe como faz isso? Eu só quero testar o meu midlet no simulador… não vou (por enquanto) testar em aparelhos.
Grato por qualquer resposta.
Bom só uma dica…
Nem todos os aparelhos suportam conexão por sockets. E inclusive são bem poucos os que suportam esta opção…
Tenta fazer algum exemplo usando HttpConnection.
Ou ainda tenta rodar o programa no emulador em uma maquina que tenha Windows só por garantia que não seja algo no Linux…
[quote=fabianofrizzo]Bom só uma dica…
Nem todos os aparelhos suportam conexão por sockets. E inclusive são bem poucos os que suportam esta opção…
Tenta fazer algum exemplo usando HttpConnection.
Ou ainda tenta rodar o programa no emulador em uma maquina que tenha Windows só por garantia que não seja algo no Linux…[/quote]
Pois é…o que tem de gente que insiste em usar o socket ao invés do HTTP… :?
Tá certo que a nível de custo, ele leva vantagem, pois você pode desprezar os bytes do protocolo HTTP e criar seu próprio protocolo, fazendo uso mais racional do seu plano de consumo de dados.
Mas o contra é que do outro lado você tem que desenvolver o seu servidor para aceitar a conexão e lidar com este “protocolo” que você criou para receber os dados e persistir.
Por outro lado, o HTTP funciona desde o MIDP 1.0 e todos os aparelhos tem implementado !
Além disto basta colocar um Apache com PHP, Tomcat ou qualquer outra coisa e é muito fácil de você implementar rapidamente algo do lado do servidor.
O lado ruim é que se você tiver 10 bytes para enviar, só os bytes do protocolo vão dar mais que o que você efetivamente vai usar na outra ponta.Enfim, você ganha na facilidade de uso mas perde no custo, que no caso do Socket é menor.
[quote=boone]
Pois é…o que tem de gente que insiste em usar o socket ao invés do HTTP… :?
Tá certo que a nível de custo, ele leva vantagem, pois você pode desprezar os bytes do protocolo HTTP e criar seu próprio protocolo, fazendo uso mais racional do seu plano de consumo de dados.
Mas o contra é que do outro lado você tem que desenvolver o seu servidor para aceitar a conexão e lidar com este “protocolo” que você criou para receber os dados e persistir.
Por outro lado, o HTTP funciona desde o MIDP 1.0 e todos os aparelhos tem implementado !
Além disto basta colocar um Apache com PHP, Tomcat ou qualquer outra coisa e é muito fácil de você implementar rapidamente algo do lado do servidor.
O lado ruim é que se você tiver 10 bytes para enviar, só os bytes do protocolo vão dar mais que o que você efetivamente vai usar na outra ponta.Enfim, você ganha na facilidade de uso mas perde no custo, que no caso do Socket é menor.[/quote]
É nesta parte concordo com vc em todos os pontos…
resumindo: vocês não sabem como corrigir o problema.
Em resumo:
Você não foi atrás da dica implícita que o fabianofrizzo deu, e foi ver se o te aparelho suporta socket.
Socket é do MIDP 2.0, mas pode também em aparecer em alguns MIDP 1.0 embora isto não seja obrigatório do fabricante implementar.
Quanto a questão de SecurityException ela normalmente vai dar quando há uma recusa por parte do usuário em não te autorizar o acesso a algum recurso ou mesmo o próprio aparelho se a aplicação estiver configurada assim.
Ex: Se o usuário configura no aparelho para que tua aplicação seja negada de acessar a rede, nem a famosa perguntinha que o celular faz ao usuário perguntando se permitesse acesso, vai aparecer. É SecurityException na cabeça e ponto !
Em vários aparelhos existe as configurações: Perguntar sempre, perguntar a 1a vez e nunca perguntar.
@recoma obrigado pelos links.
@boone no meu primeiro post eu disse que não testaria em aparelhos, pelo menos não por enquanto.
se eu resolver o problema eu volto aqui pra postar a solução.