Artigo da WebMobile 4 - Explorando o J2ME

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Artigo da WebMobile 4 - Explorando o J2ME

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

wm_04capa.JPG

Explorando o J2ME

Conhecendo a Wireless Messaging API (Parte 1)

 

Juliano D. Carniel e Clovis Teixeira

Leitura obrigatória: Web Mobile 1, Introdução ao J2ME.

Leitura obrigatória: Web Mobile 2, J2ME: Como começar.

 

Desenvolver aplicações para dispositivos móveis hoje, integrando sistemas e estendendo funcionalidades, está se tornando cada vez mais útil e necessário, e para isso a comunidade e empresas da área têm trabalhado trazendo novas funcionalidades todos os dias para o melhor aproveitamento de seus dispositivos. Conhecer estas funcionalidades torna-se extremamente necessário para novos projetos.

Devido a este fato, este será o primeiro de uma série de artigos que irá abordar o uso de algumas JSR’s e novas funcionalidades do MIDP 2.0 que estão se popularizando no mercado. Neste primeiro, iremos tratar da JSR 120 conhecida como Wireless Message API, que nada mais é que uma API para que aplicações J2ME possam enviar e receber mensagens, possibilitando uma comunicação “peer-to-peer”, ou seja, de celular para celular.

Primeiramente vamos explicar alguns conceitos básicos dessa API e em seguida, descrever o desenvolvimento de um aplicativo que permita demonstrar seu uso prático.

JSR - Java Specification Request

JSR’s são especificações de novas APIs ou funcionalidades para todas as plataformas Java (ver Nota 1). Nesta série de artigos iremos tratar das JSRs específicas para a plataforma J2ME.

 

Nota 1. JSR (Java Specification Request)

Uma JSR consiste em um documento, ou requisição, enviado ao grupo (PMO) que controla o Java Community Process (JCP), propondo que uma nova especificação seja feita ou que alguma já existente seja revisada. Cada nova especificação propõe uma melhoria ou nova funcionalidade à plataforma. Assim que aceita, ela entra em período de desenvolvimento e só depois é aderida à plataforma inteira. Cada nova JSR contém líderes e membros responsáveis pela especificação, mas estes sempre subordinados ao JCP.

Vários fabricantes de celulares participam da especificação e implementação de uma JSR, alguns exemplos são: Siemens, Nokia, Motorola, Sun Microsystems, Symbian, NEC entre outras.

 

Essas novas especificações visam descrever, de forma padronizada, como acessar funcionalidades dos aparelhos que não foram previstas pela especificação geral do J2ME. No nosso caso, os aparelhos são telefones celulares e a especificação J2ME que estaremos utilizando é a CLDC e o MIDP.

A criação dessas JSR ocorre devido ao fato do J2ME se basear no conceito de sand-box, limitando o acesso somente a funcionalidades específicas e básicas dos dispositivos, principalmente por questões de desempenho e segurança. Para que os recursos extras dos celulares sejam explorados por uma aplicação, como  envio de mensagens de texto, acesso à câmera fotográfica, comunicação via bluetooth, acesso a informações contidas no aparelho, dentre outras, é que são criadas as JSRs. Estas podem ou não ser suportadas por celulares, estando a critério do fabricante esta escolha.

Em geral as JSR’s, conforme sua aceitação e popularização no mercado, podem ser incorporadas nas próximas versões de alguma especificação maior, em nosso caso o J2ME (MIDP+CLDC), dando mais flexibilidade à plataforma. Isto termina fazendo com que o fabricante que implementar o J2ME em seu dispositivo tenha que atender a todos aqueles requisitos mínimos.

Pelo fato desta especificação (WMA – JSR 120) não estar implementada em uma Configuration ou em um Profile, o suporte, por enquanto, é de escolha exclusiva do fabricante do aparelho. Geralmente os fabricantes adicionam uma JSR em alguns de seus modelos, considerando custos e características do aparelho. Portanto, antes de pensar em utilizar uma JSR, é necessário verificar se o celular alvo para sua aplicação possui suporte à JSR que você irá utilizar.

Onde usar?

O recurso que a WMA oferece pode ser muito útil, por exemplo, para aplicações que precisem trocar informações entre aparelhos, mas que por diversos motivos não estejam disponíveis (por exemplo, fora de área ou desligados) na rede ao mesmo tempo. A forma utilizada pela WMA para realizar a conexão é oposta à do TCP, que necessita a disponibilidade simultânea dos dois hosts para poder estabelecer uma conexão direta entre as duas pontas e enviar os dados. No caso do TCP,  na ocorrência de falha em um dos hosts, a conexão é perdida assim como os dados que estavam sendo trafegados.

Já a conexão feita pelo WMA é uma comunicação assíncrona, similar ao e-mail. Esta forma de comunicação é conhecida como store-and-forward, ou seja, se o destinatário não estiver disponível para receber a mensagem, ela é armazenada até que ele fique disponível novamente. Lembrando ainda que esta é uma das poucas formas de uma comunicação direta entre dispositivos tendo em vista que eles não têm um endereço IP para conexão, e os únicos que conseguem alcançar os dispositivos são as operadoras.

WMA - Wireless Message API – JSR 120

Esta especificação é responsável pelo uso dos recursos de envio e recebimento de mensagens dos aparelhos celulares, sejam elas de texto ou mensagens de conteúdo binário. WMA é uma API baseada no Generic Connection Framework (GCF), que consiste na definição do padrão de conexão dentro do CLDC. Isto a torna compatível com todos os dispositivos que possuírem J2ME, independentemente da versão do CLDC.

Existem hoje duas versões baseadas na JSR 120, a 1.0 e a 1.1. A 1.1 traz basicamente o suporte às novas funcionalidades de segurança e PushRegistry do MIDP 2.0 (mais detalhes no tópico sobre segurança), e a implementação das Multipart Message System (JSR 205).

As mensagens do WMA são constituídas principalmente por um cabeçalho e uma área de dados relacionados com a mensagem que está sendo enviada. Para se criar uma mensagem é necessário usar a interface javax.wireless.messaging.Message, que é a interface comum a todas as mensagens. Esta interface especifica métodos para tratamento dos campos de endereço, data e hora, entre outras informações que fazem parte da área de cabeçalho.

A API fornece mecanismos para envio e recebimento de mensagens. Estas funcionalidades são acessadas através de uma interface baseada na Connection da GCF (javax.microedition.io), especificamente a javax.wireless.messaging.MessageConnection. A conexão é obtida como no GCF, através da classe Connector, que é uma Factory, a qual recebe o endereço desejado e retorna uma Connection ou, no caso, uma MessageConnection (a MessageConnection herda de Connection). Se for especificado um endereço de destinatário logo na obtenção da conexão (método open() da classe Connector) essa conexão está fadada a apenas enviar mensagens para este endereço (número de telefone):

 

MessageConnection)Connector.open(“sms://+99887766”);

 

MessageConnection)Connector.open(“sms://+99887766:123”);

 

Para usarmos a conexão tanto para enviar quanto para receber, é necessário passar apenas a string que representa o protocolo de mensagens e a porta. Assim, a conexão aberta pode receber e enviar mensagens, o que é chamado de “Modo Servidor” (ver exemplo abaixo). Caso queiramos usar nosso “servidor” para enviar uma mensagem para um número específico, devemos seta-lo com o método setAddress() do objeto mensagem que iremos enviar.

 

MessageConnection) Connector.open(“sms://:54321”);

 

No exemplo acima estamos abrindo uma conexão dizendo que esperamos mensagens SMS na porta 54321. Neste caso, o recebimento de mensagens é baseado em evento, e para gerenciar esses eventos devemos criar uma classe que implemente a interface javax.wireless.messaging.MessageListener, como veremos em nosso exemplo. A função dessa classe será de ficar esperando o recebimento de uma mensagem, e de processar a mensagem, de acordo com a forma como for definido pelo desenvolvedor.

Vale lembrar que quando abrimos uma conexão para receber mensagens em uma determinada porta, as mensagens serão recebidas somente se tiverem sido destinadas a essa porta. Portanto, as mensagens enviadas pelo recurso normal de envio de mensagens de qualquer celular, por exemplo, não serão aceitas.

Padrões de mensagens

A WMA especifica dois tipos de mensagens: TextMessages e BinaryMessages. Estes dois tipos enquadram-se como Short Message Service (SMS). Infelizmente o padrão SMS não é universal, e existem hoje dois importantes padrões: o GSM SMS e o CDMA SMS. Ambos diferem principalmente no cabeçalho e no tipo de Bitset utilizado.

Além dos padrões de SMS, existe ainda um chamado de Cell Broadcast Short Message Service (CBS). As mensagens CBS são mensagens enviadas em broadcast pela rede, partindo de uma central da rede de telefonia (central da operadora). Este protocolo foi inserido nesta especificação justamente para tratar essas mensagens. Como este protocolo é específico para o recebimento de mensagem CBS, se o método send() da MessageConnection for invocado, ele lançará uma IOException. Isto por que mensagens deste tipo não podem ser enviadas de celulares uma vez que somente operadoras tem acesso a este tipo de serviço.

Segurança

O WMA propõe um modelo de segurança “customizável”, ou seja, pode depender tanto da implementação na máquina virtual java quanto do desenvolvedor. Esse modelo de segurança age tanto na permissão de envio de mensagens, quanto na definição de restrições relacionadas às mensagens que podem ser recebidas pelo aparelho. Como principais restrições têm-se:

·         Aceitar somente mensagens através de uma porta;

·         Aceitar somente mensagens vindas de um remetente específico.

 

A configuração das permissões pode ser observada no tópico “Instalação de Aplicações” e na Figura 6.

Por fim, vale informar que os modelos de permissão das especificações de MIDP 1.0 e 2.0 são diferentes, então a segurança de uma aplicação utilizando WMA irá depender também da versão do MIDP do dispositivo.

 

MIDP 1.0

Para aplicações instaladas em dispositivos contendo a versão 1.0 do MIDP, as conexões estão sujeitas à aprovação do usuário, ou seja, no momento do início do acesso, seja através do Connector.open(), ou MessageConnection.send(), ou ainda MessageConnection.receive(), um pedido de aceitação será mostrado para o usuário. Caso este pedido seja negado (acesso à rede pela aplicação), uma SecurityException será lançada na aplicação do usuário que negou acesso à comunicação e a mensagem não será enviada.

 

MIDP 2.0

O MIDP 2.0 disponibiliza um sistema de permissões mais elaborado, com Permission Types para Protection Domains que equivalem a dar certas permissões para aplicações a serem instaladas.

Com este sistema é possível, por exemplo, restringir que aplicações enviem mensagens, e permitir que somente recebam. Em cima disso, ainda é possível restringir o acesso à somente um endereço de destinatário ou somente de um remetente.

Tudo que não for explicitamente permitido e tentar ser usado lançará uma exceção (SecurityException).

Todas essas informações relacionadas às configurações de segurança, nesta versão, são armazenadas no arquivo de descrição da aplicação (arquivo com extensão jad).

Como usar?                     

Para mostrar todos os recursos do WMA, vamos criar uma aplicação com uma interface gráfica simples, porém dando bastante importância aos aspectos relacionados a funcionalidades da WMA para que fique bem compreendida a forma de utilizá-la.

"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?