Arquivos com a Tag: Tecnologia Push

Gestão de inventário de dispositivos móveis

Postado por
Comoentário

Uma das primeiras funcionalidades de MDM (Mobile Device Management) a agregar valor à gerência de dispositivos em uma organização é a gestão de inventário. Esta nos abre a possibilidade de entender melhor as características dos dispositivos da rede corporativa, nos permitindo oferecer melhores serviços de TI e inclusive nos apoiando na redução de custos.

Imagine os contratos de telefonia. As empresas possuem custos significativos com telefonia móvel. Contratos de smartphones, tablets, chips, dados, voz e outros. As necessidades de cada departamento/setor são diferentes, funcionários vão e vem… Aparelhos e chips são perdidos/estragados/extraviados… No início parece fácil, mas a eficiente gestão desdes custos é bastante complexa. Os dispositivos e limites contratados estão sendo devidamente utilizados, ou parte está ociosa? Quais são os dispositivos que não estão em uso? Foram perdidos? Quem é o responsável? Todas estas questões podem ser respondidas com a correta gestão do inventário, e decisões de upgrade ou mudança de planos para otimização de custos são melhor suportadas. E estamos citando um caso onde a gestão do inventário pode contribuir com otimização de contratos e custos da empresa. Melhorias significativas também podem ser vistas nas áreas de segurança da informação, suporte e outras.

Em meu post anterior sobre as áreas chave de plataformas de MDM, descrevi a gestão de inventário como não só a identificação das características do dispositivo, mas também o provisionamento e o suporte remoto a estes. Há um grande conjunto de funcionalidades importantes na gestão de inventário de um sistema de MDM, a considerar:

Inventário das características dos dispositivos

Refere-se a catalogação e pesquisa das características dos dispositivos da rede corporativa. É importante perceber que parte das características de um dispositivo pode mudar com o tempo (ex. versão do SO após uma atualização), e é importante que a plataforma de MDM identifique estas mudanças automaticamente.

Exemplo de conjunto de informações de sistema de um dispositivo Android, relevantes para identificação de suas características e potenciais vulnerabilidades de segurança
Informações de telefonia, importantes para correta gestão de TEM (Telecom Expense Management)

Configuração do dispositivo

É a capacidade de configurar diversos atributos relevantes do dispositivo, como gerenciamento da bateria, menus, redes de dados 3G e Wi-Fi e configurações regionais, entre outros. Com os dispositivos dispersos geograficamente, é importantíssimo que a plataforma de MDM ofereça a capacidade de configuração remota. Outra característica desejável é a presença de infraestrutura de Push na plataforma, de forma que estas configurações possam ser aplicadas em tempo real.

Monitoramento

O monitoramento de propriedades dinâmicas dos dispositivos é extremamente útil para o suporte aos usuários, e ajuda a prevenir problemas de mau uso e indisponibilidade de serviços para os colaboradores. Exemplos de atributos a serem monitorados são a vida útil da bateria, a memória disponível e o desempenho adequado do dispositivo. É importante a rápida identificação e notificação automática das inconformidades, de forma que ações preventivas possam ser tomadas e os dispositivos não deixem de operar corretamente.

Bloqueio de recursos de hardware

Também é considerado recurso da gestão de inventário. A plataforma de MDM deve oferecer a possibilidade de bloqueio de recursos de hardware como câmera, cartão de memória, bluetooth, wi-fi e outros.

Localização e recuperação de dispositivos

A localização de dispositivos é importante principalmente para a recuperação (do hardware ou de informações) de dispositivos perdidos ou extraviados.

Aqui há duas observações importantes a serem feitas:

  1. É muito útil que a plataforma de MDM combine esta função de localização com recursos de segurança, como Lock & Wipe remoto. A área de gestão de segurança tratarei em um post futuro.
  2. Os serviços de localização oferecidos pela plataforma podem ir além do básico necessário para a gestão de inventário, e podem ser muito interessantes no apoio de aplicações verticais baseadas em localização geográfica.
Exemplo de mapa de localização de dispositivo.

Conclusões

A área de gestão de inventário é composta por um conjunto de funcionalidades que não são simples mas, se suportadas pela plataforma de MDM e bem utilizadas, oferecem benefícios significativos no gerenciamento dos dispositivos móveis das empresas.

E quando se fala em gestão de inventário, reforço um ponto que estou sempre discutindo. É importantíssimo que todo o sistema seja suportado de forma online, assistido por infraestrutura de Push. Afinal uma boa gestão de inventário não é manual e estática, mas sim automática e dinâmica.

Escrito por Eduardo Klein

Tecnologia Push em sistemas iOS e Windows Phone (Parte 2/2 – MPNS)

Postado por
Comoentário

Na semana passada, nosso post abordou Tecnologia Push em sistemas iOS e Windows Phone. Para darmos continuidade, essa semana vamos conhecer como funcionam as notificações de push no novo sistema operacional mobile da Microsoft, o Windows Phone.

Vamos dar uma passada por todo o ciclo dessa infraestrutura!

Pré-requisitos e Infraestrutura

As notificações de push no Windows Phone podem ser testadas no emulador, dispensando a aquisição de uma licença de desenvolvedor. Entretanto, para uso no dispositivo, é necessário realizar o processo de cadastramento do aparelho no APP HUB da Microsoft. Nesse momento, focaremos nosso exemplo no uso do emulador.

Com esse cenário, também será necessário um servidor ou provider como citado na parte 1 desse post [veja o post], aqui chamado de cloud service.

No Windows Phone, o processo de comunicação entre cloud service e MPNS é bem mais simples. A conexão com o servidor de notificações da Microsoft é feita via HTTP.

Diferentemente do iOS, na plataforma da Microsoft, o cloud service não precisará de um certificado para estabelecer a conexão com o MPNS.

O processo básico desse cenário é o seguinte:

  • No dispositivo, a aplicação com notificações de push ativado estabelece uma conexão com o MPNS via HTTP e recebe um token.  (etapas 1 e 2)
  • Esse token será informado pelo dispositivo ao cloud service. Uma vez atualizado o token no cloud service, o ciclo está completo e as notificações de PUSH podem ser enviadas.
    (etapas 3 e 4)
  • O cloud service envia as notificações de push para o MPNS e esse, por sua vez, analisa o token e encaminha para o respectivo dispositivo. No dispositivo interpreta-se a notificação e toma as ações desejadas.
    (etapas 5 e 6)

Na estrutura desse token existe o endereço para o qual o cloud service deverá fazer a requisição HTTP e o identificador do dispositivo.

Recebendo uma notificação

Existem três tipos de notificações que podem ser enviadas ao dispositivo, cada uma com sua finalidade específica.
São elas RAW, TILE e TOAST.

TILE MESSAGE:

São usadas para atualizar informações de aplicações que estão em PIN (na área de trabalho) do dispositivo. Pode-se atualizar a imagem ou valores da TILE.

Vamos exemplificar com uma aplicação para leitura de RSS. Toda vez que novas notícias estão disponíveis a aplicação pode atualizar a TILE via notificações de push, mostrando quantas novas existem.
Não nos aprofundaremos nesse tipo de mensagem pois vamos dar foco à TOAST MESSAGE.

RAW MESSAGE:

Mensagens que chegam silenciosamente ao dispositivo. Imperceptível ao usuário, só será processada se a aplicação estiver em execução, caso contrário é descartada.

TOAST MESSAGE:

Se a sua aplicação não está em execução, será exibida uma mensagem de alerta no topo da tela do dispositivo informando o recebimento da notificação. O usuário pode tocar na alert bar para que a aplicação seja executada e a notificação processada.

Caso transcorram alguns segundos sem que o usuário toque na alert bar, a notificação será descartada.
Se a aplicação já estiver em execução, a notificação é recebida sem o alerta na alert bar e é imediatamente processada sem necessidade de intervenção do usuário.

 Abaixo segue trecho do método responsável pela construção da mensagem e envio:

...
//token recebido anteriormente na abertura do canal do dispositivo com MPNS
string subscriptionUrl = _token;

//criando mensagem associando ao token
HttpWebRequest sendNotificationRequest  = (HttpWebRequest)WebRequest.Create(subscriptionUrl);

//cabeçalho da mensagem
sendNotificationRequest.Method = "POST";
sendNotificationRequest.ContentType = "text/xml";
byte[] notificationMessage = new byte[] { };

//chamada do método que constrói mensagem do tipo TOAST
notificationMessage = TOASTMESSAGE(_text1, _text2);

//solicita entrega imediata
sendNotificationRequest.Headers.Add("X-NotificationClass", "2");

//informa o tipo de notificação
sendNotificationRequest.Headers.Add("X-WindowsPhone-Target", "toast");

//informa tamanho da mensagem
sendNotificationRequest.ContentLength = notificationMessage.Length;

//preparando mensagem para envio
using (Stream requestStream = sendNotificationRequest.GetRequestStream())
{
    requestStream.Write(notificationMessage, 0, notificationMessage.Length);
}

//envio da notificação
HttpWebResponse response =
    (HttpWebResponse)sendNotificationRequest.GetResponse();

//conferindo resposta do envio
string notificationStatus = response.Headers["X-NotificationStatus"];
string notificationChannelStatus = response.Headers["X-SubscriptionStatus"];
string deviceConnectionStatus = response.Headers["X-DeviceConnectionStatus"];
...

Estrutura de uma mensagem do tipo TOAST:

<?xml version="1.0" encoding="utf-8"?>
<wp:Notification xmlns:wp="WPNotification">
    <wp:Toast>
        <wp:Text1>{0}</wp:Text1>
        <wp:Text2>{1}</wp:Text2>
    </wp:Toast>
</wp:Notification>

* Onde {0} = header e {1} = payload
** O tamanho máximo para o header é de 1 kb e o payload 3 kb. Mensagens com tamanho superior serão simplesmente descartadas.

Conclusões

É notável que o processo para envio das notificações de push é muito mais simples no Windows Phone, todavia, muito se assemelha ao iOS.
O entendimento de todo o cenário de funcionamento do mecanismo de PUSH é crucial para o seu desenvolvimento e facilita o processo de implementação.

Intrínsecas funcionalidades de MDM (Mobile Device Management) não estão disponíveis na versão do Windows Phone 7, o que acaba sendo um pouco frustrante.

Além disso, a limitação para processar notificações recebidas apenas por aplicações em execução em primeiro plano, também deixam a desejar e tornam a realidade do MDM um pouco distante do ideal, se comparado ao antigo Windows Mobile.

Nesse caso, todo o foco das notificações de push ficam atreladas apenas às aplicações que estão em execução. Por tratar-se de um sistema operacional novo, aguardamos por novidades nas próximas versões.

Por enquanto, jogamos com as cartas da mesa para expor tudo que é possível até o momento, na esperança de que, logo ali na frente, as novidades cheguem e possamos ir mais além!

Participe de nosso blog deixando comentários com sugestões, dúvidas, análises.

Abraço e até o próximo post!

Escrito por Luiz Roberto Lethang Rodolpho

Tecnologia Push em sistemas iOS e Windows Phone (Parte 1/2 – APNS)

Postado por
2

Você já viu aqui no blog como a tecnologia Push pode ser implementada em dispositivos que permitem que uma aplicação execute em background sem restrições. Na verdade, existem várias formas de se prover comunicação em tempo real em aplicações de mobilidade do tipo cliente-servidor. A mais recente tendência em sistemas móveis é a disponibilização de uma infraestrutura nativa à plataforma que possibilite o desenvolvimento de aplicações com essa característica. Essa tecnologia se baseia em um serviço disponibilizado na nuvem pelo fabricante do sistema operacional onde um servidor, chamado de provider, pode se conectar e enviar as notificações que deseja entregar, e a entrega ao dispositivo fica a cargo do servidor do fabricante. Atualmente, a Apple, desde o iOS 3, e a Microsoft, desde o Windows Phone 7, disponibilizam serviços deste tipo, chamados respectivamente de Apple Push Notification Service (APNS) e Microsoft Push Notification Service (MPNS). Neste post vamos abordar as infraestruturas de Push da Apple e da Microsoft, desde os pré-requisitos até a forma de tratar as notificações no dispositivo. Nesta primeira parte vamos falar do APNS, e a segunda tratará do MPNS.

Pré-requisitos e Infraestrutura

Se você conhece as necessidades para se tornar um desenvolvedor no mundo Apple, já deve conhecer os developer programs, e como eles afetam as suas possibilidades como desenvolvedor (confira as características do desenvolvimento em iOS em nosso comparativo com a plataforma Android, em breve dedicaremos um post para explicar as diferenças entre cada programa de desenvolvimento da Apple). Ainda não é possível receber uma notificação pelo simulador, o que já exige no mínimo a licença paga de desenvolvedor (U$99 ao ano), pois será preciso testar em um dispositivo (um iPod é suficiente). Também é preciso ter um servidor para atuar como provider. Existem serviços pagos na internet que disponibilizam essa função, ou é possível desenvolver o seu próprio provider. O M3, solução da Mobiltec para integração em mobilidade, já possui a capacidade de atuar como provider tanto para APNS quanto para MPNS.

Como funciona o APNS

A conexão com o servidor de notificações da Apple é feita através de sockets TCP utilizando TSL. Pode parecer estranha a escolha por um protocolo de mais baixo nível, ao invés de utilizar HTTP por exemplo, como no caso do serviço da Microsoft, mas certamente o desempenho foi um fator crucial nessa decisão, já que o serviço concentra todas as notificações para dispositivos iOS no mundo, o que não é pouca coisa. O certificado para que o provider consiga se conectar ao APNS é obtido no portal de desenvolvedores da Apple. Para cada aplicação que receberá notificações há um certificado específico, que será utilizado para abrir a conexão para esta aplicação. O certificado contém o bundle (identificador padrão de aplicativos iOS) e assim o APNS já sabe para qual aplicativo deve entregar a notificação. Falta ainda para o serviço saber para qual dispositivo deve entregar a notificação. Essa identificação é feita através do push token, um identificador único por dispositivo que é obtido pelo aplicativo no aparelho e enviado ao provider. Com estas duas informações já é possível para o APNS rotear a notificação para o par exato de aplicação/dispositivo que irá recebê-la.

“Mas como é esta notificação afinal, e como as informações são passadas?” você deve estar se perguntando. As notificações são pacotes de no máximo 256 bytes cada, e podem ser montadas em dois formatos: simple e enhanced.

Este é o pacote no formato enhanced, que se diferencia do formato simple apenas pela presença de dois campos extras: expiry, que define por quanto tempo o APNS deve tentar enviar a notificação até desistir se não conseguir entregá-la, e identifier, que serve para o provider saber quais notificações não foram aceitas pelo APNS devido a algum erro, como um pacote mal formado ou maior que o limite, por exemplo. Essa informação é passada como resposta ao envio de um conjunto de notificações, no formato da figura abaixo, onde uma resposta é gerada para cada notificação com erro. Se nenhum erro ocorreu, o serviço simplesmente não responde nada.

Os outros campos que formam uma notificação são o command, que indica se é uma notificação no formato simple (0) ou enhanced (1), o token que foi enviado pelo dispositivo e seu tamanho, e o payload e seu tamanho. O payload é onde as informações que serão passadas ao dispositivo são armazenadas. Ele usa o formato JSON, que basicamente codifica um dicionário.

O mínimo que este dicionário deve conter é a chave “aps” com um dicionário como valor. Este dicionário da chave “aps” deve conter no mínimo uma das três formas de notificação: alert, badge ou sound. Opcionalmente podem ser passadas informações personalizadas referentes a lógica da aplicação, criando-se um ou mais dicionários, desde que não seja excedido o limite de 256 bytes para a notificação como um todo. Apesar de ser possível o envio de dados pela notificação, esses dados não devem cruciais para o funcionamento da aplicação, já que a política do APNS é “best effort”, e a entrega da notificação não é garantida. A função principal da notificação é avisar a aplicação para que ela se conecte ao seu provider e realize alguma tarefa.

O serviço da Apple é dividido em dois servidores: um de teste, acessado através do endereço gateway.sandbox.push.apple.com, porta TCP 2195, que deve ser utilizado durante a fase de desenvolvimento da aplicação, e o servidor de produção, conectado através do endereço gateweay.push.apple.com, porta TCP 2195. Este último possui políticas mais severas quanto ao bom uso dos recursos que devem ser seguidas pelo provider. Os servidores da Apple monitoram a forma como os providers utilizam o serviço. Se um provider abrir várias conexões com muita frequência, pode ter seu acesso bloqueado. Por isso, a recomendação é de que as notificações sejam agrupadas sempre que possível para envio, e que a conexão seja mantida aberta o maior tempo possível. Além disso, o APNS disponibiliza um serviço de Feedback, que os providers podem (e devem) consultar periodicamente para obter uma lista de dispositivos com os quais o APNS repetidamente não conseguiu se conectar. Isso evita que se tente enviar notificações para dispositivos que não podem mais recebê-las, pelo usuário ter removido a aplicação por exemplo, evitando o desperdício de recursos do serviço.

Recebendo uma notificação

Finalmente você consegue fazer uma notificação chegar ao dispositivo, mas ainda é necessário receber e processar as informações que chegaram. Até o iOS 4.x, existiam três possibilidades de recebimento de notificações do ponto de vista da aplicação: a notificação era recebida em um momento que a aplicação já estava rodando, e o processamento poderia ser feito de forma transparente ao usuário, a noticação chegava enquanto a aplicação não estava rodando, com o usuário aceitando esta notificação, fazendo com que a aplicação seja iniciada, ou, neste mesmo caso, o usuário recusava a notificação, e ela não seria entrege, não sendo possível recuperar as informações enviadas. Além de a entrega da notificação não ser garantida, mesmo após o recebimento no dispositivo, ainda não se pode ter certeza que a notificação chegará à aplicação. Isso é uma característica do sistema de notificações dos dispositivos iOS 4.x , oriunda da política de usabilidade e controle do usuário sobre o dispositivo adotada pela Apple, e a aplicação deve estar preparada para estes fatores e incertezas. O sistema de notificações, no que diz respeito à forma como elas são entregues, foi totalmente reformulado no iOS 5 (o serviço de PNS continua funcionando para quem já tinha notificações sendo entregues em versões anteriores do iOS sem necessidade de alterações segundo a Apple) mas isso será abordado em nossos próximos posts.

No caso da applicação ter sido iniciada devido a uma notificação de Push, as informações do payload podem ser recuperadas na classe AppDelegate, no método chamado ao iniciar uma aplicação, através do dicionário que este método recebe como parâmetro e da chave, que é uma constante do sistema, como mostra o trecho de código abaixo.

 - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    //...
    NSDictionary *remoteNotificationInfo = [launchOptions valueForKey:UIApplicationLaunchOptionsRemoteNotificationKey];
    //...
}

Se a aplicação já estiver rodando no momento que receber uma notificação, o AppDelegate deve ter a implementação do método abaixo.

 - (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo

Conclusões

Prover a funcionalidade de push em uma aplicação não é simples devido a todos os pré-requisitos, principalmente o de um servidor provider, que vai exigir algum esforço de programação ou o custo para usar um servidor pago. Além disso, usar essa tecnologia para aplicativos com funcionalidades de MDM é difícil devido a exigência de interação com o usuário no momento do recebimento das notificações e até a possibilidade de a notificação ser descartada. Mas nesse sentido, o conceito de MDM da Apple também é diferente, disponibilizando, assim como no caso do Push, uma infraestrutura específica. Mesmo o serviço de Push possui um tipo de notificação específica para MDM. Temos muitos assuntos interessantes para tratar sobre a plataforma iOS. Acompanhe o nosso blog que em breve teremos mais posts sobre tecnologias para iOS. E ainda essa semana teremos a segunda parte deste post, sobre a tecnologia de Push para plataforma Windows Phone. Aguarde!

Escrito por Renan Drabach

Referência
http://goo.gl/3ejZh