Pedro, entendo seu ponto de vista e concordaria sobre a reinvenção da roda, mas eu ja tinha tudo pronto no projeto que falei. Não descordo nem desgosto de nenhuma tecnologia sugerida aqui, aliás utilizo várias em outros projetos, mas como são muitas, temos que escolher uma, certo? (a finalidade da discussão é realmente para não escolhermos uma que não atenda.)
Em sexta-feira, 4 de abril de 2014 13h28min28s UTC-3, Pedro Subutzki escreveu:
-- No final das contas, tudo vai passar por um socket:
Ex.
1. REST -> HTTP -> TCP-IP.
2. WebService -> WSDL -> XML -> SOAP -> HTTP -> TCP-IP
3. Google Cloud Message -> NUM SEI QUE LÁ -> TCP-IP.
Web Services por exemplo é uma das mais interessantes que já utilizei, mas para este projeto que estou trabalhando, não dá pra utilizar um monte de camadas só para enviar alguns bytes. Só o cabeçalho da mensagem seria maior do que a própria mensagem. Fora isso a conexão com o Web Services é stateless.
Visitei alguns concorrentes em Automação residencial e alguns utilizam tecnologias que faz um clique levar 6seg pra acender uma lâmpada. Achei inviável.
No caso do socket dá pra manter a conexão persistente, trafegar só o que realmente preciso e, cara, tá funcionando maneiro! Clicou acendeu. Só não estou feliz em ter um Client indo ao servidor a cada segundo, achei fora de padrão, o ServerSocket seria uma boa se funcionasse assim. Daí eu faria a comunicação bi-direcional.
De acordo com as sugestões dos colegas aqui, estou quase convencido em utilizar o GCM para as notificações.
Mas vamu lá! Comentem aê! Tudo ainda pode mudar.
Abraço.
Renato Gaúna
Em sexta-feira, 4 de abril de 2014 13h28min28s UTC-3, Pedro Subutzki escreveu:
Renato,Desculpe mas acho que você está reinventando a roda. :)Abraços,
Pedro Subutzki
__________________________________________ HADI - Makes SQLite in Android easy and simple
https://github.com/PepeuCps/Hadi Em 4 de abril de 2014 11:08, Renato Gaúna <renat...@gmail.com> escreveu:Lúcio,Trata-se de um serviço rodando em segundo plano com ClientSocket. Ele fica a cada 5seg tentando conectar ao servidor. Como é um serviço, não foi necessário acordar o SO. Fiz um teste com o servidor ligado e o android "dormindo": a mensagem chega. Acredite a bateria caiu só os 4% que falei.Realmente gostaria muito da comunicação nos dois sentidos, mas não fico confortável de depender de um serviço na nuvem, pelos motivos que citei nos posts anteriores...
Em sexta-feira, 4 de abril de 2014 09h16min30s UTC-3, luciofm escreveu:Você estava usando um wakelock? garantiu que acordou o OS a cada 5 segundos? esse numero de uso de bateria não faz sentido para mim.Quanto a uma comunicação mais "interligada" você pode usar o GCM Cloud Connection Server, dessa maneira a comunicação é nos 2 sentidos...Lúcio Maciel
luc...@gmail.com2014-04-04 9:03 GMT-03:00 Renato Gaúna <renat...@gmail.com>:TESTE DO CONSUMO DA BATERIA!Galera, testei o consumo da APP. Dei carga total na bateria e deixei a noite inteira com a APP procurando o servidor fora do ar a cada 5seg. Os 100% de carga caíram para 96. Parece bom. Esta noite farei um novo teste, deixando o servidor no ar e a APP fazendo consulta a cada seg. Depois posto o resultado.Abraço!
Em quinta-feira, 3 de abril de 2014 16h15min19s UTC-3, Jonas Alves escreveu:Como eu já disse, se não usar GCM, você vai drenar a bateria.
Sugiro usar GCM pra receber notificações e HTTP/REST para enviar comandos ao seu servidor. Socket não é uma boa solução para o seu caso.
Em 03/04/2014 16:09, "Renato Gaúna" <renat...@gmail.com> escreveu:Maneiro demais, Jonas!!!Como podem ver, estou estudando a plataforma Android há pouco tempo, embora possua alguns anos de mercado na área de desenvolvimento.A Google pensou em tudo mesmo! Mas o que realmente preciso vai um pouco mais além do que entregar mensagens. Como se trata de um software ligado a automação residencial, preciso também que o Android mantenha uma conexão persistente com servidor para receber mensagens de aviso e enviar mensagens (com comandos) para controlar a automação. Claro, poderia utilizar essa solução para atender o envio das notificações, mas vou tentar fazer algo um pouco mais interligado, digo, sem utilizar uma tecnologia para cada tipo de necessidade, tipo: socket ou Webservices para enviar comandos e GCM para receber mensagens. Pretendo fazer tudo isso usando o socket. Mas certamente vou guardar essa dica para implementação do próximo projeto.Valeu!
Em quinta-feira, 3 de abril de 2014 14h32min41s UTC-3, Jonas Alves escreveu:Você precisa do GCM: http://developer.android.com/g
oogle/gcm/index.html
Essa é a única forma de ter notificações instantâneas sem drenar a bateria.Em 03/04/2014 12:55, "Renato Gaúna" <renat...@gmail.com> escreveu:Estranho! Respondi ontem e o post não funfou... Aí vai novamente.--Geovani, não preciso categoricamente de um ServerSocket no Android, só achei que fosse uma prática normal. Pensava que o WhatsApp, por exemplo, por ser tão rápido, utilizava essa estrutura. Fico impressionado como você posta um vídeo para várias pessoas de redes diferentes e quase no mesmo segundo a mensagem pipoca lá no Android do destinatário. Já descartei a idéia do Server no Android...Vou ler mais sobre as sugestões que você postou...Minha necessidade é a seguinte: meu negócio é automação residencial. Estou testando um protótipo que dispara um Notification no Android quando um evento ocorre na casa: abertura de janela, sensor de movimento das câmeras, quando começa uma chuva, (descarga no vaso... hehehe...), etc.Escolhi sockets pq uma vez desenvolvi um projeto numa empresa que trabalhei que tinha que atender os requisitos: 100% conectado, alta velocidade, e pouco consumo de tráfego. Como eu tenho as classes genéricas já prontas, foi rápido utilizar essa solução. Não teria problema eu utilizar outras como REST, WebServices e qualquer outra da sua sugestão. Foi só por conveniência e realmente sockets atendem muito bem esses requisitos que citei.Já estou testando a alteração que fiz: ClientSocket no Android com ServerSocket no servidor PC (este está ligado a automação). To gostando dos resultados... mas vou realmente dar uma atenção ao que você sugeriu...Obrigado!
Em quarta-feira, 2 de abril de 2014 16h26min24s UTC-3, Renato Gaúna escreveu:
Em quarta-feira, 2 de abril de 2014 12h52min51s UTC-3, Renato Gaúna escreveu:Olá, criei um ServerSocket que fica escutando uma porta e funciona perfeitamente no wi-fi utilizando ip da rede local.Quando testo utilizando o 3G não funciona. Na verdade não chegam ping nem tracert para o ip do celular quando está no 3G.Obtive o IP do meu android no site meuip.com.br. Alguém sabe dizer se a operadora bloqueia a chegada no IP do cel? Se sim, como o WhatsApp por exemplo faz troca de mensagens IP. Será que ele não possui um server e sim um ClientSocket que fica consultando um servidor a cada segundo?Valeu!
You received this message because you are subscribed to the Google Groups "Android Brasil - Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to androidbrasil-...@googlegroups.com .
For more options, visit https://groups.google.com/d/optout .
--
You received this message because you are subscribed to the Google Groups "Android Brasil - Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to androidbrasil-...@googlegroups.com .
For more options, visit https://groups.google.com/d/optout .
--
You received this message because you are subscribed to the Google Groups "Android Brasil - Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to androidbrasil-...@googlegroups.com .
For more options, visit https://groups.google.com/d/optout .
You received this message because you are subscribed to the Google Groups "Android Brasil - Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to androidbrasil-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
0 comentários:
Postar um comentário