Modelos de atualizações via rede
Com o avanço do uso de smartphones e com o aumento do número de aplicações que utilizam a Internet para se conectarem a servidores, questões que envolvem a otimização da transfência de dados entre servidor e aplicação surgem. Em uma troca de informações que ocorre entre cliente e servidor, os dados em transferência podem possuir um tamanho grande a ponto de causar lentidão no fluxo e somado ao número de acessos do cliente ao servidor podem se tornar uma sobrecarga para ambas as partes. Mas esses pontos e outros mais não seriam um problema se não houvesse a limitação de rede e hardware que há hoje.
O foco na melhoria de troca de dados é causado pela limitação que dispositivos móveis possuem. Autonomia da bateria e largura insatisfatória da banda da forma acesso mais comum a internet, que é através dos pacotes de dados oferecidos pelas operadoras de telefonia, são uns dos problemas mais comuns enfrentados pelo desenvolvedores de aplicações para dispositivos móveis e as protagonistas em impulsionar a comunidade a utilizar modelos de atualização via rede mais convenientes possíveis.
Dentre os problemas citados que um fluxo de dados pode causar em um cliente limitado em hardware e rede como os smartphones, o projeto focou em utilizar o modelo que melhor proporcione redução no número de requisições do cliente ao servidor. Exemplo de situações onde esse foco é cabível são os aplicativos de notícias e de bate-papo que se destacam não no tamanho dos dados trafegados, mas no número de transferências realizadas em um intervalo de tempo e na necessidade de estar constantemente procurando atualizações no servidor.
Sendo assim, como manter uma aplicação atualizada com dados vindos do servidor da maneira que possua um menor número de requisições possível? Existem duas técnicas que podem ser utilizadas para que haja troca de dados entre o servidor e uma aplicação, Pulling e Pushing. Porém, entre as duas, apenas uma consegue trazer um resultado satisfatórios para o foco abordado.
Pulling
O Pulling ou Client Pull é uma técnica de comunicação de rede fácil de implementar entre cliente e servidor onde o primeiro passo parte do lado cliente. Para que o cliente identifique que há novos dados para receber, deverá solicitar ao servidor novos dados, podendo receber os novos dados ou então fazer uma requisição inválida caso não haja dados a receber.
Contextualizando a técnica para exemplificar seu funcionamento, imaginemos um aplicativo executando em um smartphone e de tempos em tempos consultando um Webservice a fim de obter possíveis novas notícias.
Haverá uma grande porcentagem de requisições inválidas se comparado o número de respostas negativas com as positivas. O aplicativo fará demasiadas requisições ao servidor que terão como resposta uma identificação que não há novas notícias, já que é mais fácil não haver novas notícias a ter em um intervalo de tempo, agravando ainda mais a medida que encurtarmos o espaço de tempo.
Isso acarreta problemas de gasto desnecessário de energia no cliente e sobrecarrega do servidor, que pode estar atendendo a centenas de clientes. Sendo assim, lembrando que as questões levantadas no início envolvem exatamente esses pontos negativos do Pulling, essa técnica deixa de ser eficaz em plataformas mobile.
Pushing
O Pushing ou Server Push é das duas técnicas a mais eficiente apesar de ser tão eficaz quanto o Pulling. A grande diferença entre as duas é que com o uso da técnica Pushing o dispositivo deixa de estar a todo instante verificando no servidor se há algum novo dado, se tornando ocioso enquanto o servidor tem o papel de notificar quando houver um novo dado. Quando o cliente for notificado pelo servidor, esse se despertará e fará uma solicitação de novos dados, certo de que haverá um retorno positivo.
O número de requisições reduz de forma expressiva se compararmos a primeira técnica explicada com essa nova. Usando o mesmo contexto antes criado, o aplicativo fará apenas uma única requisição ao webservice por novas notícias que acontecerá após ser avisado que há novas notícias, tendo a requisição sempre um retorno válido.
Se dispositivos móveis forem responsáveis pelo papel de cliente na técnica de Pushing, é possível implementar a notificação do servidor ao cliente usando SMS como meio, porém, se torna caro e inviável. A Google, vendo a necessidade de um serviço que implemente o Pushing e que consequentemente otimize as conexão das aplicações do Android com servidores, lançou o Google Cloud Messaging.
GCM e seus concorrentes
Google Cloud Messaging ou GCM é um serviço gratuito obviamente disponibilizado pela Google que auxilia os programadores a implementarem uma comunicação entre cliente-servidor de uma maneira otimizada através da técnica de Pushing. O GCM pode ter como cliente aplicações Android ou aplicações para o Google Chrome e no lado servidor a aplicação pode ser implementada em qualquer linguagem que seja capaz de realizar conexão através do protocolo HTTP.
O beta desse serviço foi lançado com o nome de Android Cloud to Device Messaging ou C2DM, que era voltada para aplicações Android, mas, agora em sua nova versão, o serviço permite também a comunicação com aplicações para o Google Chrome.
Entre as principais características do GCM está que a aplicação Android não precisa estar em execução para que as mensagens possam ser recebidas, o serviço não garante a ordem e entrega da mensagem, não é feito tratamento algum nos dados enviados e não há uma interface gráfica para gerência.
Além disso é importante adicionar que esse serviço usa a mesma conexão dos outros serviços Google, como por exemplo, Gmail e Contatos. O serviço requer que o aparelho possua o sistema operacional Android acima da versão 2.2 que possua o Google Play Store, e também requer que caso a versão do sistema operacional seja inferior a 4.0.4 que uma conta Google seja registrada no dispositivo.
Uma mensagem de alerta do serviço para o dispositivo pode ser de dois tipos, uma messagem Send-to-Sync, que é uma mensagem que avisa ao dispositivo que há dados a serem obtido no servidor, como tradicionalmente na técnica de Pushing, e também há uma mensagem que já carrega consigo os novos dados. Ou seja, o GCM pode avisar que há dados a serem obtidos como tradicionalmente na técnica de Pushing ou pode já diretamente enviar esses dados, inovando ao incrementar a técnica.
Se é possível já enviar esses dados de imediato, porque a possibilidade de simplesmente avisar que há dados a serem transferidos e exigir que o dispositivo solicite, custando uma requisição? Isso porque o segundo tipo de mensagem, que é o próprio dado sendo transferido, possui um tamanho máximo de 4kb. Sendo assim, se o servidor deseja transferir um arquivo por exemplo de tamanho acima de 4kb, ele usará o Google Cloud Messaging para simplesmente avisar ao cliente que há um vídeo a ser transferido, para assim então abrir uma requisição de tamanho suficiente para obter o vídeo.
O serviço do Google Cloud Messaging de se comunicar através de mensagens com o aplicativo em um dispositivo móvel é usado por uma aplicação servidor, podendo ser um webservice, uma tarefa agendada por uma rotina no sistema operacional, ou mesmo um site. Esse terceiro personagem na história é quem deseja, por exemplo, notificar algo a um aplicativo contido em um dispositivo específico e não é capaz de forma natural realizar isso. Essa notificação pode ser para que o aplicativo vá buscar novos dados, pode ser para que o aplicativo execute alguma rotina interna e outras inúmeras possibilidades, já que a mensagem poderá ser qualquer informação que terá qualquer interpretação pelo lado cliente.
Seguindo o segundo tipo de mensagem, o webservice pode já enviar diretamente o dado dentro ao GCM para que ele envie transmita ao aplicativo específico. Sendo assim, não será necessário que a aplicação faça a requisição após ser informada como no primeiro tipo.
Tássio Auad 