Esse artigo faz parte da revista WebMobile edição 6. Clique aqui para ler todos os artigos desta edição

wm06_capa.JPG

 

No artigo anterior, “WMA - Conhecendo a Wireless Messaging API”, foi abordado alguns conceitos sobre mensagens. Nele foi apresentado onde as mensagens estão situadas na arquitetura do Java ME, os conceitos básicos de segurança e como aplicar na prática a API do WMA.

Como continuação, iremos abordar as modificações que foram introduzidas com a evolução da API de Mensagens para WMA 2.0. Esta nova versão da API não traz grandes mudanças ou adições, apenas complementa o que faltava na primeira versão da WMA, que consiste basicamente na adição da possibilidade de envio de mensagens binárias ou de multimídia, conhecidas como Multimedia Message Service (MMS).

Juntamente com o WMA 2.0, vamos aprender a utilizar o recurso Push Registry, inserido na versão 2.0 do MIDP. Este recurso tem como finalidade gerenciar a execução de aplicações (agendar e controlar o seu início), sem que seja preciso a intervenção do usuário para isso. O uso do Push Registry não é exclusivo à API WMA, ele tem utilidade em outros tipos de aplicações.

Para exemplificarmos o uso da WMA 2.0, mostraremos a implementação de uma MIDlet que permite a troca de mensagens MMS. Além disso, serão utilizadas as facilidades oferecidas pelo Push Registry para que se tenha uma noção de como esse serviço pode ser utilizado em aplicações Java ME.

WMA 2.0

A Wireless Message API é uma API do MIDP que, na sua primeira versão, sua implantação era determinada pelo fabricante do aparelho, mas que a partir da versão 2.0 do MIDP se tornou obrigatória à qualquer tipo de aparelho que execute Java ME.

Essa nova versão contempla todos os tipos de mensagens que conhecemos atualmente: SMS, CBS e MMS. Além disto, visto que ela é uma simples evolução da 1.0, os sistemas feitos para aparelhos com MIDP 1.0 são totalmente compatíveis com os que utilizam o MIDP 2.0.

As mensagens MMS existem a fim de disponibilizar um sistema para envio e recebimento de qualquer tipo de mídia que os celulares suportam, ou seja, tudo o que pode ser transportado por um array de bytes. Esse tipo de mensagem tem por obrigação especificar qual o tipo de arquivo que está sendo transportando, bem como outras informações contidas no cabeçalho e no corpo da mensagem. Caso o aparelho receptor não contenha um interpretador para tal tipo de mídia, a mensagem é recebida, mas simplesmente não é mostrada pois o aparelho não sabe como fazê-lo.

Mensagens MMS, assim como as mensagens SMS, são compostas por um cabeçalho e um corpo de mensagem, como pode ser visto na Figura 1.

O cabeçalho de uma mensagem possui informações oriundas do padrão RFC 822, assim como algumas informações específicas para MMS.

O corpo de uma mensagem MMS é composto por várias partes, conhecidas como MessageParts (javax.wireless.messaging.MessagePart). Cada MessagePart possui um mini-cabeçalho e um corpo (body). Neste cabeçalho encontramos três campos:

·        MIME-Type: possui informações sobre o tipo de arquivo que vai ser enviado na MessagePart. Por exemplo: image/jpeg, text/plain.

·        Content-Location: utilizado para informar o nome do arquivo que estará sendo mandado. Ex: "imagem.png", "texto.txt".

·        Content-ID: identificador único de cada parte que compõe uma mensagem. Além disso, o Content-ID pode ser usado para outros fins quando utilizado com certos tipos de conteúdos.

 

image001.png
O corpo (body) de cada parte (MessagePart) é composto pelos dados da mídia a ser enviada, como podemos ver na Figura 1.

Figura 1. Estrutura de uma mensagem MMS.

 

Para se enviar uma MMS, semelhante ao envio de um SMS, uma conexão deve ser aberta através da classe javax.microedition.io.Connector. Essa classe retorna uma javax.microedition.io.Connection que herda de javax.wireless.messaging.MessageConnection. Logo abaixo veremos em código como fazer esta conexão. A conexão é aberta segundo uma URL, que é passada para a classe factory Connection. Um exemplo de URL seria:

 

- mms://+99887766

- mms://+99887766:meu.pacote.MIDlet

Push Registry

Push trabalha com conceito de eventos. Ele serve para disparar uma aplicação após o recebimento de um evento. Basicamente, o Push Registry é usado para agendar a inicialização em um determinado tempo ou através de um evento de E/S (Entrada e Saída), geralmente conexões.

O mecanismo de Push Registry foi uma das novidades do MIDP 2.0 que mais chamou a atenção, pois ajuda na integração de aplicações Java ME com o sistema operacional do dispositivo alvo. O fato de não haver necessidade da aplicação Java ME estar em execução para receber algum tipo de conexão amplia bastante o campo de atuação de aplicações Java para celulares.

Vimos no primeiro artigo que a forma de comunicação entre celulares a longa distância só é possível através de WMA. Sua empresa pode ter, por exemplo, técnicos em campo trabalhando, e você pode querer ativar um envio de informações sobre as tarefas diárias de seus técnicos em um certo período do dia. Para isto bastaria enviar uma mensagem, e o mecanismo de Push acionaria a aplicação e enviaria estes dados. Ou ainda, atualizaria dados da aplicação do técnico, com os dados mandados por você. E tudo isto sem que seja necessária a intervenção do usuário

Push Registry faz parte do Application Management System (AMS), que é o gerenciador de aplicações Java ME do sistema operacional do dispositivo (Figura 2). O AMS é responsável pelo ciclo de vida das aplicações, ou seja, ela gerencia a inicialização, pausa e finalização das aplicações. O Push Registry possibilita que o gerenciador inicialize aplicações através de eventos previamente registrados, ou seja, sem a intervenção do usuário. A Figura 2 mostra que uma aplicação que utiliza as funcionalidades oferecidas pelo Push Registry. Ela pode ser iniciada de três maneiras:

·          Através do usuário: o usuário inicia a aplicação normalmente;

·          Através de um evento: por exemplo, uma Mensagem MMS chegando em uma certa porta registrada para uma certa aplicação (mais detalhes a seguir);

·          Através de um Alarm: a aplicação registra um Alarm para que seja executado num determinado intervalo de tempo, ou em um horário específico.

image003.png

 

Figura 2. Ciclo de vida de uma aplicação Java ME.

 

Existem basicamente dois modos de se fazer o registro de uma aplicação no sistema de Push:

·          Static Registration: que é feito no arquivo de descrição da aplicação (JAD File), ou seja, quando uma aplicação é instalada, automaticamente a aplicação é registrada no mecanismo de Push conforme a descrição feita no arquivo .JAD. Por exemplo:

 

MIDlet-Push-1: , ,

 

·          Dynamic Registration: é quando um aplicativo registra um Push durante sua execução. Este modo é feito através da classe PushRegistry.

 

Para registrarmos um Push Dinâmico pode ser utilizado o seguinte método:

 

PushRegistry.registerConnection(String url, String midletClassName, String allowedSender);

 

Para ambos os exemplos (Static e Dynamic). os parâmetros usados são os mesmos:

?         url: sms://:5000

?         midletClassName: nome da classe que deverá ser chamada. Por exemplo: meu.pacote.MyMIDlet

?         allowedSender: endereço do host que pode acionar a aplicação. Podem ser usados caracteres como “*” e “?” como filtro. Por exemplo:

o       * : todos os hosts podem ativar determinada instrução do push;

o       123.123.123.* : somente os hosts com endereço iniciando com 123.123.123 poderão ativar  a aplicação;

o       123.123.123.12? : somente hosts iniciando em 123.123.123.12 seguido de um outro número poderá ativar a aplicação.

 

Com esses registros garantimos que conexões entrantes sejam corretamente processadas pelas aplicações registradas. Porém, vimos que é possível fazer com que nossa aplicação execute de tempo em tempo sem que seja necessário um evento de conexão para ativá-la. Para tal, temos duas opções:

·   Alarm: faz com que a aplicação execute na data e horário especificados;

·   Timer: serve para que um certo código seja executado de tempos em tempos durante a execução de uma MIDlet.

 

O código abaixo mostra como registrar a MIDlet corrente com um Alarm para 1 hora após seu registro:

String className = this.getClass().getName();

Date time = new Date();

long ret = PushRegistry.registerAlarm( className, time.getTime()+ (60*60*1000) );

        

No exemplo acima obtemos o nome da classe que iremos registrar no Alarm, para posteriormente ser executada. Criamos um objeto do tipo Date (contendo a data atual) que servirá como referência para o registro da aplicação. E por fim, na ultima linha registramos que nossa classe (className) deverá ser executada 1h (60*60*1000), contando a partir do tempo de criação do objeto Date.

É possível somente um Alarm ativo por MIDlet. Quando o método registerAlarm() for chamado novamente, ele sobrescreverá eventuais Alarms antigos. Caso queira desabilitar um Alarm, basta passar o tempo com o valor 0.

Para o registro de um Timer é necessário que se crie uma TimerTask (java.util.TimerTask). Um TimerTask implementa Runnable, ou seja, é usada para se criar uma Thread. O código da Listagem 1 mostra como criar um Timer que seja executado a cada 5 minutos (REPEAT_TIME), sendo executado 1 minuto (FIRST_PERIOD) depois de registrado.

 

long REPEAT_TIME = 5*60*1000;

long FIRST_PERIOD = 1*60*1000;

Timer timer = new Timer();

MyTask myTask = new MyTimerTask();

timer.schedule(myTask, FIRST_PERIOD, REFRESH_TIME);

 

...

 

class MyTimerTask extends TimerTask { ...

Quer ler esse conteúdo completo? Tenha acesso completo