J2ME e desenvolvimento de aplicação para celular (Controle de requisições para agentes de campo)

Com o objetivo do lançamento de novos produtos Omnidata que empregam J2ME, eu deveria dominar a tecnologia e desenvolver aplicações-piloto visando futuras apresentações a possíveis clientes. De início, estudei a tecnologia principalmente a partir da leitura de [2]. Como ambiente de desenvolvimento, utilizei o Sun One Studio Mobile Edition [10]. Para executar programas sem a necessidade de instalá-los no celular, utilizei emuladores incluídos no J2ME Wireless Toolkit [9] e no Siemens Mobility Toolkit [8]. Após um razoável domínio das classes relacionadas com a interface ao usuário, testei as classes relacionadas a conectividade (TCP, UDP, etc), mas os testes não foram completos pois ainda não havia na empresa nenhum celular habilitado para executar aplicações Java. Nessa etapa inicial, não havia um prazo estipulado para conclusão. De fato, nem havia a intenção de desenvolvimento de uma aplicação específica. Também ouvi de meu chefe algumas idéias para um possível produto.

Essa etapa de aprendizado perdurou por algumas semanas. Após isso, só tive contato novamente com J2ME meses depois. Somente nesse momento, meu chefe havia pensado numa aplicação razoável para ser lançada como um produto. De fato a idéia era uma generalização de outras que ele já havia mencionado, envolvendo automação de controle de requisições para agentes em campo. De modo geral, aplicações dessa natureza devem modelar as seguintes situações:

  • Agente de campo solicita requisições para serem atendidas
  • Se houver alguma requisição, o agente recebe a descrição da mesma, juntamente com os dados pertinentes, como o endereço, nome do cliente, etc
  • Agente envia relatório com informações sobre a conclusão, bem sucedida ou não, da tarefa

Evidentemente, de acordo com a dinâmica e o tipo de requisição para os agentes de campo, outros detalhes são pertinentes. Mas com uma aplicação mais simples desenvolvida, pode-se usá-la em demonstrações para possíveis clientes e especializá-la de acordo com as características do negócio.

O servidor

A solução completa envolve não apenas a aplicação no celular, mas também o servidor. Para desenvolver o servidor, modifiquei uma aplicação de código aberto feita em Java, chamada Scarab [19], um sistema de Issue Tracking. Issue Tracking (acompanhamento de requisições) é uma generalização à idéia do Bugzilla [7], ferramenta inicialmente desenvolvida para o acompanhamento de bugs do projeto Mozilla com o objetivo de facilitar a comunicação entre todos os interessados no projeto, sejam eles usuários do sistema, desenvolvedores e gerentes, em que usuários podem, por exemplo, enviar relatórios de bugs e, por sua vez, desenvolvedores são notificados a respeito disso. A inovação no Scarab é a possibilidade de acompanhamento não apenas de bugs, mas de qualquer tipo de requisição (issue): o administrador do sistema define as informações pertinentes aos tipos de requisição passíveis de serem enviadas por usuários.

O aspecto mais gratificante em ter modificado esse sistema foi a oportunidade de conhecer idéias de outros desenvolvedores, além de novas tecnologias. Scarab agrega projetos de grande potencial e utilidade:

  • Turbine [20], um arcabouço para desenvolvimento de aplicações web, que inclui vários componentes e serviços, inclusive alguns dos citados abaixo
  • Velocity [21], um projeto para o desenvolvimento de templates. Pode-se por exemplo, separar a criação do modelo visual de um site da lógica de negócio
  • Fulcrum [22], um repositório de componentes reutilizáveis para o Turbine
  • Torque [23], ferramenta que disponibiliza uma abstração para persistência de dados, permitindo a manipulação de dados independentemente do sistema de banco de dados escolhido. No momento da geração dos pacotes da aplicação, a ferramenta gera as classes específicas ao banco de dados a ser utilizado.
  • Commons [24], mais um conjunto de componentes reutilizáveis
  • Maven, a única tecnologia que eu já conhecia

Com o Scarab, operadores do sistema adicionam novas requisições. Por sua vez, agentes de campo, equipados com celulares habilitados para executar programas J2ME, solicitam o envio de requisições remotamente, descartando a necessidade de deslocamento até o local onde estão os registros das requisições.

Esforços iniciais foram necessários para compreender o modo de instalação do Scarab, a configuração do banco de dados e de alguns parâmetros necessários para a aplicação. A tarefa não foi muito complexa, já que algumas etapas já eram automatizadas pelo Maven. A etapa seguinte consistiu na compreensão do uso do sistema.

Após definir um novo tipo de issue no sistema (veja figura abaixo), com campos como nome do cliente, local de atendimento da requisição, tipo de serviço e outros, foi necessário adicionar ao servidor a possibilidade de disponibilizar valores dos campos associados a requisições, para permitir a integração com a aplicação do celular. Sem essa modificação, seria necessário navegar em várias telas para conseguir tal informação, opção inviável, ainda mais para um celular, devido às limitações para o processamento no celular e ao custo inerente ao tráfego de dados com o código HTML das páginas da navegação.





A idéia era enviar informações em um formato simples, em resposta a apenas uma requisição HTTP. XML (eXtensible Markup Language), seria uma opção interessante se a aplicação cliente fosse desktop, já que existem diversas ferramentas para manipular dados nesse formato. De fato, também há algumas ferramentas em J2ME para manipular XML, mas a quantidade de dados trafegados pela rede ainda seria grande. Assim, optei pelo formato CSV (Comma Separated Values - Valores Separados por Vírgula).

Para dar início às modificações, precisei compreender a arquitetura do Scarab e de alguns detalhes de Turbine e Velocity. Consultas a tutoriais na internet e ao livro [6] foram importantes. Para adicionar a funcionalidade em questão, bastava definir uma classe similar a outras já existentes no Scarab. Após descobrir como disponibilizar o serviço, tive que entender os mecanismos de obtenção de registros do banco de dados e de persistência de novas informações. Também foi necessário compreender o relacionamento de tabelas do banco de dados, através da análise de descritores XML usados pelo Torque. Ajustes finais foram feitos para definir o formato das requisições HTTP aceitas pela nova classe, com a escolha de nomes de parâmetros e possíveis valores.

O cliente

Após definir o servidor, comecei a desenvolver a aplicação cliente na plataforma J2ME (MIDP 1.0 - CLDC 1.1). Utilizei o Eclipse como ambiente de desenvolvimento para ambas as aplicações. Para execução dos testes, além de emuladores, utilizei equipamentos reais, uma vez que a empresa já dispunha de celulares habilitados para executar aplicações feitas em Java. Como já havia estudado a tecnologia anteriormente, precisei apenas relembrar alguns conceitos. Também li alguns capítulos de [3].

Uma necessidade indicada pelo meu chefe seria o uso de Maven na aplicação cliente desde o início. Como não havia nenhum plugin específico para J2ME, defini scripts para executar tarefas como compilação, pré-verificação, criação do pacote JAR e uso de ofuscador de código. A tarefa foi simplificada com o uso de Antenna [11], ferramenta que implementa um conjunto de tasks em Ant para executar tarefas comuns em projetos J2ME. Antenna também foi útil na disponibilização pela internet do pacote com a aplicação, pois a ferramenta também tem implementada um servlet para uploads e downloads de aplicações feitas em J2ME, gerando páginas tanto em HTML como em WML (Wireless Markup Language, linguagem compatível com WAP browsers) com aplicações disponíveis para download. Assim, pude adicionar ao script em Maven a opção de implantar a aplicação em um servidor web arbitrário e a partir do celular pude fazer o download da aplicação com extrema facilidade.

Assim como foi proposto, a aplicação cliente ficou relativamente simples, seguindo o paradigma citado anteriormente para automação do controle de requisições para agentes em campo. Apesar da simplicidade, foi necessário bastante cuidado para definir uma interface de fácil utilização, garantindo a apresentação de informações (como barras de progresso e avisos na tela) sobre as tarefas atualmente executadas.

Seguem abaixo algumas figuras da aplicação cliente, executadas em um emulador de Siemens M50:

Ajustes finais

Os ajustes finais foram feitos no servidor, com a configuração do Scarab para o envio de emails aos usuários. A tarefa não estava relacionada diretamente relacionada com a solução, era apenas uma pendência da instalação inicialmente desprezada. Tal atividade não foi simples devido a uma deficiência do Scarab: tal aplicação assume que o servidor SMTP indicado nos arquivos de configuração, necessário para o envio de emails, não impõe autenticação. Como a primeira opção seria utilizar um servidor SMTP de um provedor de internet, característico por exigir autenticação, eu deveria resolver o problema. Para implementar tal funcionalidade, tive que modificar uma biblioteca utilizada pelo Scarab chamada Commons Mail, incluída em Jakarta Commons, e adicionar a bibiloteca com a nova funcionalidade junto ao código-fonte do Scarab. Também foi necessário fazer modificações no código-fonte do Scarab para permitir o uso de autenticação.

Outros comentários

Como não havia clientes envolvidos, não havia um prazo específico para conclusão. Quanto ao método de trabalho, semelhantemente a alguns projetos anteriores, atuei sozinho. Periodicamente, apresentava ao meu chefe o meu progresso.

O projeto foi concluído, mas novas melhorias já foram levantadas:

  • Uso da API de localização (presente apenas em MIDP 2.0), para monitoramento de agentes e logística
  • Uso da API de manipulação de arquivos de imagem e de som.