Caso de uso JME

8/7/2019 Caso de uso JME

1/71

Coordenacao do Curso de Ciencia da Computacao

Universidade Estadual de Mato Grosso do Sul

Desenvolvendo um Estudo de Caso

Utilizando a Plataforma Java ME

Lais Claudia ZanfolimRodolfo Chaves Fernandes

Andre Chastel Lima (Orientador)Celso G. Camilo Jr (Co-orientador)

Dezembro de 2009


2/71

Desenvolvendo um Estudo de CasoUtilizando a Plataforma Java ME

Lais Claudia Zanfolim

Rodolfo Chaves Fernandes

Este exemplar corresponde a redacao final

da monografia da disciplina Projeto Final de

Curso devidamente corrigida e defendida por

Lais Claudia Zanfolim

Rodolfo Chaves Fernandes e aprovada pela

Banca Examinadora, como parte dos requisi-

tos para a obtencao do ttulo de Bacharel em

Ciencia da Computacao.

Dourados, 11 de dezembro de 2009.

Andre Chastel Lima (Orientador)

Celso G. Camilo Jr (Co-orientador)

ii


3/71

Coordenacao do Curso de Ciencia da Computacao

Universidade Estadual de Mato Grosso do Sul

Desenvolvendo um Estudo de Caso

Utilizando a Plataforma Java ME

Lais Claudia ZanfolimRodolfo Chaves Fernandes

Dezembro de 2009

Banca Examinadora:

Andre Chastel Lima (Orientador)

Celso G. Camilo Jr (Co-orientador)

Raquel Marcia Muller

Nielsen Cassiano Simoes

iii


4/71

Resumo

A plataforma Java Micro Edition e o conjunto de tecnologias que permitem o de-

senvolvimento de aplicacoes Java para dispositivos com processamento, memoria e vdeo

limitados, como celulares e smartphones. Assim como as outras edicoes Java, essa pla-

taforma foi desenvolvida com o mesmo intuito, a portabilidade, alem de possuir diversas

APIs para o desenvolvimento, o Java ME tambem fornece compatibilidade entre as edi-

coes Java, possibilitando a comunicacao com aplicacoes construdas em Java SE e Java

EE. Mantendo o foco em Java Micro Edition, este trabalho propoe o desenvolvimento de

uma aplicacao movel que una as tecnologias Java ME e Java EE. Como o Java Enterprise

Edition possui varias funcionalidades de redes e Internet e contem classes especialmente

desenvolvidas para acesso a servidores e banco de dados, parte da aplica cao foi construda

usando esta tecnologia, possibilitando a comunicacao entre dispositivos moveis e um servi-

dor disposto na rede local ou Internet. Portanto, neste trabalho foi abordado, juntamente

com a plataforma Java ME, o uso de Servlets dentro da arquitetura Java EE, interagindo

com um cliente movel atraves do protocolo HTTP para estabelecer a comunicacao com

celulares e smartphones. Visto que um Servlet pode efetuar qualquer processamento ine-rente a uma classe Java e enviar respostas na forma de documentos XML, para efetuarmos

a troca de dados entre um dispositivo movel e o servidor remoto de dados, que alimenta o

sistema movel, utilizamos os recursos que a linguagem XML nos oferece. Para auxiliar o

desenvolvimento do estudo de caso, a metodologia agil extreme programming foi utilizada

juntamente com diagramas da UML com o intuito de organizar o processo de desenvolvi-

mento. A aplicacao desenvolvida durante o trabalho e responsavel por agilizar o processo

de vendas de uma distibuidora de bebidas, a fim de automatizar a forca de vendas e foi

testada em celulares e smartphones com o sistema operacional movel Symbian e Windows

Mobile, interagindo com o servidor via requisicoes HTTP.

Palavras Chave: Java ME, mobilidade, celulares e smartphones.

iv


5/71


6/71

Agradecimentos

Agradecemos primeiramente a Deus, por ter nos abencoado durante toda nossa vida

e principalmente por ter nos dado forcas durante todo o decorrer do trabalho.

Aos nossos familiares, pela confianca, apoio e educacao durante toda nossa caminhada.

Ao nosso orientador Andre Chastel Lima, pelo apoio e compreensao.

Ao nosso co-orientador Celso Camilo, pelo incentivo e paciencia.

A toda academia, que nos proporcionou as condicoes necessarias para o desenvolvi-

mento deste trabalho, em especial os professores Odival Faccenda e Glaucia Gabriel Sass.

Aos funcionarios da eXclaim, por nos dar a oportunidade de estagiar na empresa e

desenvolver projetos com a tecnologia Java ME.

Aos leitores e colaboradores do javamovel.com, pela lealdade e por nos incentivar a

estudar o tema do projeto.

Enfim, agradecemos todos aqueles que contriburam para o sucesso desta caminhada

e que de forma injusta nao tiveram seus nomes includos aqui.

vi


7/71

Sumario

Resumo iv

Abstract v

Agradecimentos vi

1 Introducao 3

1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Sistemas operacionais para dispositivos moveis 6

2.1 Dispositivos Moveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Sistemas Operacionais e suas tecnologias . . . . . . . . . . . . . . . . . . . 7

2.2.1 Symbian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.2 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.3 Windows Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.4 Palm OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.5 BlackBerry OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.6 Iphone OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Analise do Mercado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Java Micro Edition 11

3.1 Visao geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 Configuracoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3 Perfis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.4 Maquinas Virtuais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.5 Pacotes Opcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

vii


8/71


9/71

Lista de Figuras

3.1 Elementos da plataforma Java ME. . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Arquitetura da plataforma Java. . . . . . . . . . . . . . . . . . . . . . . . . 13

4.1 Ciclo de vida do MIDlet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2 Hierarquia de classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.3 Record Management System. . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.1 Arquitetura da plataforma Java EE. . . . . . . . . . . . . . . . . . . . . . . 36

6.2 Servlet container. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6.3 Ciclo de vida do servlet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.4 Estrutura do XML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

7.1 Esquema de comunicacao. . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

7.2 Diagrama de Caso de Uso. . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

7.3 Estoria 1-A: Consulta de produtos. . . . . . . . . . . . . . . . . . . . . . . 44

7.4 Estoria 1-B: Consulta e cadastro de clientes. . . . . . . . . . . . . . . . . . 447.5 Estoria 2-A: Cadastro de pedidos. . . . . . . . . . . . . . . . . . . . . . . . 45

7.6 Estoria 2-B: Alteracao de pedidos. . . . . . . . . . . . . . . . . . . . . . . . 45

7.7 Estoria 2-C: Envio dos dados para o banco central da empresa. . . . . . . . 46

7.8 Diagrama de classe de projeto - Produto. . . . . . . . . . . . . . . . . . . . 47

7.9 Diagrama de classe de projeto - Cliente. . . . . . . . . . . . . . . . . . . . 47

7.10 Diagrama de classes de projeto. . . . . . . . . . . . . . . . . . . . . . . . . 48

7.11 Autenticacao do usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

7.12 Menu principal da aplicacao movel. . . . . . . . . . . . . . . . . . . . . . . 51

7.13 Cadastro de Clientes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7.14 Busca de Produtos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.15 Detalhamento de produto. . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7.16 Cadastro de pedidos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7.17 Lista de pedidos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

ix


10/71

Lista de Siglas

AM - Application Manager

API - Application Programming Interface

CDC - Connected Device Configuration

CGI - Common Gateway Interface

CLDC - Connected Limited Device Configuration

CVM - Compact Virtual Machine

DTD - Document Type Declaration

FP - Foundation Profile

GP - Game Profile

GPS - Global Positioning System (Sistema de Posicionamento Global)

HTTP - HyperText Markup Language

HTTP - Hypertext Transfer Protocol

J2SE - Java 2 Standard Edition

JAD - Java Decompiler

JAR - Java ArchiveJava EE - Java Enterprise Edition

Java ME - Java Micro Edition

JCP - Java Community Process

JNI - Java Native Interface

JSP - Java ServerPages

JVM - Java Virtual Machine

KVM - K Virtual Machine

LWUIT - LightWeight User Interface Toolkit

MIDP - Mobile Information Device Profile

MMAPI - Mobile Media APIMMS - Multimedia Messaging Service (Servico de Mensagem Multimdia)

MSA - Mobile Service Architecture

OpenCL - Open Computing Language

OpenGL - Open Graphics Library

1


11/71

2

PBP - Personal Basis Profile

PC - Personal Computer

PDA - Personal Digital Assistants

PDAP - PDA Profile

PP - Personal ProfileRAD - Rapid Application Development

RAM - Random Access Memory

RIM - Research in Motion

RMI - Remote Method Invocation

RMIP - Remote Method Invocation Profile

RMS - Record Management System

SDK - Software Development Kit

SMS - Short Message Service

SO - Sistema OperacionalUML - Unified Modeling Language

VM - Virtual Machine

W3C - World Wide Web Consortium

WAV - WAVEform audio format

WTK - Wireless ToolKit

XML - eXtensible Markup Language


12/71

Captulo 1

Introducao

Com a expansao da Internet e da utilizacao de aplicacoes, surgiram diversas linguagens

de programacao, tendo destaque as de multiplataforma, como e o caso do Java, que podeser aplicado em diversos setores, como aparelhos eletronicos, telefones celulares, aplicacoes

para Web e desktop, entre outros. Levando em consideracao os diferentes setores, tornou-

se necessario a criacao de kits de desenvolvimento diferenciados.

A proposta inicial parte do interesse pela linguagem de programacao Java, em espe-

cfico Java Micro Edition - Java ME. E uma plataforma que permite o desenvolvimento

de aplicacoes Java para dispositivos com processamento, memoria e vdeo limitados, tais

como celulares e smartphones. Assim como as outras edicoes Java, essa tecnologia foi

desenvolvida com o mesmo intuito, a portabilidade, alem de possuir diversas APIs (Ap-

plication Programming Interface) para o desenvolvimento. O Java ME tambem fornece

compatibilidade entre as edicoes Java, possibilitando a comunicacao com aplicacoes JavaSE (Java Standard Edition) e Java EE (Java Enterprise Edition).

A Java Community Process - JCP, especifica o Java ME em dois grupos:

CDC - Connected Device Configuration: para dispositivos com maior capacidade

computacional.

CLDC - Connected Limited Device Configuration: para dispositivos com menor

capacidade computacional e normalmente usado em aplicacoes embarcadas.

Dentro desta ultima configuracao existe uma outra classificacao que define os perfis dos

dispositivos. No caso de celulares e smartphones a classificacao usada e o MIDP, MobileInformation Device Profile. Dentro desta classificacao, se ocorrer a migracao de aplicacoes

para outros celulares com a mesma configuracao elas nao perdem sua funcionalidade

(TOPLEY, 2002).

Para otimizar o funcionamento de aplicacoes em celulares a Sun desenvolveu maquinas

virtuais Java especficas para cada configuracao, que manipulam de maneira mais eficiente

3


13/71

1.1. Objetivos 4

a codificacao desse tipo de dispositivos.

Com a criacao deste ambiente de desenvolvimento torna-se viavel a construcao de

aplicacoes para dispositivos moveis com maior produtividade e portabilidade (MUCHOW,

2001).

1.1 Objetivos

O objetivo principal deste trabalho e desenvolver um estudo de caso aplicando os prin-

cipais conceitos da plataforma Java ME e utilizar a plataforma Java EE para constru cao

de um servidor que sera responsavel pela troca de dados com a aplicacao movel.

Para alcancar o objetivo principal, as seguintes etapas foram efetuadas:

Fazer um breve estudo sobre as plataformas de dispositivos moveis;

Estudar a plataforma Java ME, voltada para dispositivos moveis;

Estudar a plataforma Java EE para a construcao de um servidor remoto;

Estudar a comunicacao entre o servidor e a aplicacao movel;

Estudar alguns frameworks Java ME e definir quais serao utilizados no estudo de

caso;

Definir os padroes da Engenharia de Software que serao utilizados na aplicacao;

Definir o estudo de caso; Desenvolver e testar o estudo de caso.

1.2 Justificativa

Segundo dados divulgados pela Agencia Nacional de Telecomunicacoes (Anatel), o

numero de linhas de telefones moveis no pas chegou a aproximadamente 152,4 milhoes,

em fevereiro de 2009, o que corresponde a 79,94% da popula cao (AGENCIAESTADO,

2009).

Em nvel mundial, o numero de usuarios de telefones moveis chegou perto de 3 bilhoesem 2007, atingindo 48% da populacao e a estimativa para o final de 2008 era de 4 bilh oes,

o que corresponde a 61%, segundo a Uniao Internacional de Telecomunicacoes (UIT)

(REUTERS, 2008).

Segundo Eric Klein, vice-presidente de marketing do Java, em entrevista a Reuters, o

Java esta instalado em 2,6 bilhoes de telefones em todo o mundo (VIRKI, 2009). Visto


14/71


15/71

Captulo 2

Sistemas operacionais para

dispositivos moveis

A tecnologia da informacao atinge a maior parte das empresas e instituicoes de forma

que fiquem dependentes de sistemas que ajudam ou otimizam o trabalho e a comunicacao

dentro das mesmas. Com a massificacao de computadores e Internet surge um outro

conceito: Mobilidade. O poder de carregar as informacoes para qualquer ambiente e

evidentemente util para empresas que trabalham com base de dados e um fator essencial

para se destacar no mercado e ter acesso as informacoes em tempo real.

Sendo evidente o impacto que solucoes de softwares moveis tem e terao nos proximos

anos, e de extrema importancia conhecer os sistemas operacionais moveis do mercado

e quais tipos de aplicacoes cada um deles suporta. Assim, e apresentada uma breve

analise dos principais sistemas operacionais para dispositivos moveis mais importantes daatualidade.

Neste captulo tambem sao explanados os principais tipos de dispositivos moveis e suas

tecnologias, visando uma abordagem completa dos requisitos necessarios para construir

aplicativos de sucesso.

2.1 Dispositivos Moveis

Primeiramente e importante esclarecer que o termo Palm e utilizado para PDAs (As-

sistente Pessoal Digital) ou Handhelds, que sao computadores de mao que fornecem asfuncoes basicas de um computador pessoal, como acesso a Internet, programas de cadas-

tros, agenda, controle financeiro, controle de vendas, planilhas, documentos entre outras

aplicacoes da categoria (PALMBRASIL, 2009a).

O smartphone e uma categoria de telefone celular com caractersticas que antes eram

encontradas somente em Palms e PCs (Personal Computers). PoketPC e o nome que

6


16/71

2.2. Sistemas Operacionais e suas tecnologias 7

a Microsoft usa para a categoria de PDAs, que difere dos smartphones por agregar ca-

ractersticas como uma tela maior e sensvel a toque, suporte wi-fi, bluetooh, integracao

com GPS (Global Positioning System), enfim, tecnologias que o tornam mais robusto

(MICROSOFT, 2009b).

2.2 Sistemas Operacionais e suas tecnologias

Nesta secao abordaremos as principais caractersticas dos sistemas operacionais moveis

mais utilizados no mercado, bem como suas tecnologias.

2.2.1 Symbian

Comecaremos entao com o sistema operacional para telefones moveis que desde 1998

lidera o mercado mundial, o Symbian OS, ou simplesmente Symbian. Ele possui suporteMMS (Multimedia Messaging Service), bluetooh, wireless, infra-vermelho, entre outras

funcoes que tornam-se extremamente importantes quando o assunto e mobilidade. Este

SO possui um sistema grafico bem simples e atualmente e o sistema mais usado pelos

maiores fabricantes de telefones moveis do mundo, porem com o surgimento de novas

tecnologias e plataformas, vem apresentando queda. Por ser um sistema operacional

que controla muito bem o consumo de memoria, o consumo de energia, o processamento,

entre outros fatores essenciais, as empresas mais poderosas da telecomunicacao investiram

bastante para que este fosse um sistema promissor para o mercado.

Empresas como Nokia, Samsung, Panasonic, Ericsson e Sony Ericsson, foram as res-

ponsaveis pela ascendencia desse modelo de sistema operacional movel. Segundo a INFO(2008), atualmente a Nokia possui a totalidade das acoes da empresa britanica de software

(Symbian), liderando o mercado mundial com 38,9% de participacao e promete concorrer

com o mais novo sistema operacional para dispositivos moveis - Android.

O Symbian suporta sistemas divididos em modulos, desta forma cada empresa pode

criar sua propria interface. Permite o uso de varias linguagens de programacao, entre

as mais importantes estao: Symbian C/C++, Java ME, FlashLite, Perl, Python, Ruby,

entre outras. Assim se o aparelho nao possui certa funcionalidade, fica facil de integrar a

mesma (SYMBIANBRASIL, 2009).

2.2.2 Android

O Android e um sistema operacional baseado em Linux voltado para smartphones,

criado pela Google em consorcio com mais de 40 empresas. Utiliza uma maquina virtual

que foi projetada para otimizar a memoria e os recursos de hardware em um ambiente


17/71


movel. E a primeira plataforma open source para desenvolvimento de aplicacoes moveis,

portanto e livre para incorporar novas tecnologias. Por ser um SO mais novo no mercado

esta em aceitacao, positiva por sinal, pelos usuarios e desenvolvedores, pois agrega todas

as funcionalidades que os aparelhos moveis mais atuais fornecem. E importante ressaltar

que os servicos da Google passam a ser facilmente acoplados com as tecnologias moveisapos o surgimento do Android, ja que o interesse e os investimentos atuais da empresa

visam a mobilidade.

Entre os servicos oferecidos estao: Cliente de e-mail, programa para SMS (Short Mes-

sage Service), calendario, mapas, navegador e gerenciador de contatos. Tudo construdo

em Java, desta forma os desenvolvedores Java podem construir aplicativos e disponibiliza-

los. Os desenvolvedores tem acesso a mesma API utilizada nos aplicativos centrais, po-

dendo aproveita-las livremente.

Alem dos aplicativos feitos em Java, o Android possui um conjunto de bibliotecas

C/C++ usadas por diversos componentes que permitem trabalhar com arquivos de mdia,exibicao de conteudo em 2D e 3D, inclusive bibliotecas implementadas utilizando OpenGL

(Open Graphics Library) e um poderoso banco de dados relacional, o SQLite (Developers,

2009).

2.2.3 Windows Mobile

Windows Mobile e um sistema operacional para dispositivos moveis, projetado para

realizar boa parte das funcoes existentes no Windows para PC. Ele pode ser instalado

em PDAs, PocketPC, smartphones e aparelhos de multimdia em geral. (MICROSOFT,

2009b).Possui uma interface intuitiva, e seguro, permite acesso a Internet, inclusive envio e

recebimento de e-mails, possui conectividade bluetooth e wi-fi, alem de versoes moveis

dos aplicativos da Microsoft Office, como: Word, Excel e Power Point. O SO suporta

aplicativos desenvolvidos em linguagens como C, C#, VB.Net, Java ME, Visual Basic,

Python, FlashLite, entre outras, alem de possuir um interpretador para PHP (MICRO-

SOFT, 2009a).

2.2.4 Palm OS

Palm OS e um sistema operacional desenvolvido pela PalmSource para rodar em PDAs.Entre as versoes da linha temos: O Palm OS Garnet e, o atualmente mais usado, Palm

OS Cobalt.

No Palm OS Cobalt o sistema roda em 32 bits, possibilitando que os aplicativos fiquem

muito mais rapidos e com recursos extras. No Palm OS Garnet (5.x) apenas algumas

partes dos aplicativos sao em 32 bits, ja que maior parte simula processadores antigos da


18/71


Motorola. A desvantagem e que as aplicacoes criadas utilizando os novos recursos nao

irao funcionar em equipamentos com versoes anteriores do sistema.

As linguagens mais utilizadas para o desenvolvimento de aplicacoes no Palm OS e

o Pascal e o C/C++. Vale ressaltar que a ultima possui uma grande quantidade de

frameworks e e mais usada no desenvolvimento de jogos. Importante dizer que existemaplicativos que convertem aplicacoes em Java para que possam ser utilizadas em Palm

OS, uma otima sada para escapar do padrao de desenvolvimento em palms. Existem

ainda outras linguagens para Palm OS, mas que nao possuem tantos recursos, tais como:

Satellite Forms, Codewarrior, AppForge, NSBasic, CASL e PDAToolBox.

Existem ferramentas RAD (Rapid Application Development) muito bem documenta-

das para auxiliar no desenvolvimento em Palm OS, e o caso da Handheld Basic (HB++),

que e muito bem aceita pela comunidade de desenvolvedores . O PocketStudio e outra

ferramenta de desenvolvimento do tipo RAD, semelhante ao Delphi, que ajuda muitos

desenvolvedores a construir aplicacoes com maior facilidade para o Palm OS. Atualmenteessas sao as mais usadas no desenvolvimento de aplicacoes comerciais para palms.

Apos a PalmSource ser comprada pela Access as proximas versoes devem ser baseadas

no sistema operacional Linux. Atualmente os dispositivos palms estao sendo comerciali-

zados tambem com Windows Mobile justamente pelas restricoes para o desenvolvimento

no sistema operacional Palm OS (PALMBRASIL, 2009b).

2.2.5 BlackBerry OS

O BlackBerry OS e o sistema operacional para smartphones BlackBerry da empresa

Canadense RIM (Research in Motion). O SO possui como ponto sobressalente a suaconsagrada ferramenta de sincronizacao de e-mails. Assim que o servidor recebe o e-mail

este e enviado para o dispositivo. Inicialmente deixava a desejar no quesito design, porem

passa por constantes aprimoramentos neste quesito e em outros recursos. Suas versoes

mais atuais apresentam recursos como menus recolhveis, navegacao por fotos, gerenciador

de arquivos dedicado e oferece suporte para aplicativos desenvolvidos em Java ME (RIM,

2009).

E o terceiro sistema operacional para dispositivos moveis mais vendido do mundo e o

segundo dos Estados Unidos. Teve um crescimento muito rapido, chegando a ser o mais

vendido nos Estados Unidos no primeiro trimestre de 2009 (ADMOB, 2009).

2.2.6 Iphone OS

O Iphone OS e o sistema operacional proprietario do Iphone, desenvolvido pela Apple.

Atualmente conhecido como Mac OS X Snow Leopard, semelhante ao sistema OS X que

roda nos computadores Macintosh. Este SO introduziu diversas tecnologias de primeira


19/71

2.3. Analise do Mercado 10

linha com uso de 64 bits, proporcionando a mais rapida implementacao de javascript e

acesso a Web, chegando a ser 53 vezes mais rapido quando usa o mini navegador Safari.

Outra poderosa tecnologia implementada e o OpenCL(Open Computing Language) que

possibilita aos desenvolvedores maior otimizacao em aplicacoes que usam recursos grafi-

cos. Possui uma tecnologia de multicondutores que agiliza a distribuicao de tarefas emmultiplos processadores (APPLE, 2009a).

Em comparacao ao Android por exemplo, e notavel que o sistema operacional do

Iphone e muito superior em qualidade e eficiencia, ainda mais se compararmos o acesso a

Web, pois o Iphone ja conquista e domina o mercado e nao deixa a desejar em nenhum

aspecto, com excecao do custo. A linguagem de desenvolvimento para o iPhone e o

Objective-C, que e muito utilizada na plataforma MAC. Ela e orientada a objetos e

difere do C no acrescimo de transmissao de mensagens, ao estilo da linguagem Smalltalk.

Tambem existem iniciativas Open Source para converter codigos em Python para C ou

tambem de Java para Objective-C.Para desenvolver aplicativos para o Iphone OS e necessario utilizar o Cocoa, um con-

junto de frameworks orientado a objetos que disponibiliza um ambiente de execucao para

as aplicacoes serem executadas em MAC OSX e Iphone OS. E o unico ambiente de apli-

cacao para Iphone OS. As aplicacoes existentes no MAC OSX e no Iphone OS sao Cocoa,

portanto para desenvolver aplicacoes Java para o sistema operacional do Iphone e neces-

sario usar ferramentas que convertem o codigo Java para a implementacao da biblioteca

Cocoa. Tambem existem frameworks para converter Python, Ruby, Perl, C# e Objective-

Basic em Objective-C, utilizando o Cocoa (APPLE, 2009b).

2.3 Analise do Mercado

As plataformas da Apple, Google e Palm sao, hoje, as que mais se destacam no mer-

cado mundial. Segundo JONES (2009), analista de mobilidade e tecnologias sem fio do

Gatener, a Microsoft esta lutando para sobreviver no celular, pois se voltou demais para

o mercado corporativo e deixou de lado o mercado domestico, ficando fraca diante do

iPhone, Symbian e Android.

Apenas tres plataformas devem sobreviver, mas e difcil dizer hoje exatamente quais

sao. E uma batalha de ecossistemas que dependem de fatores como recursos do equi-

pamento, estilo, preco e oferta de aplicativos e nao so da plataforma em si. (JONES,

2009).


20/71

Captulo 3

Java Micro Edition

Neste captulo sao apresentadas as caractersticas da plataforma Java Micro Edition

(Java ME), bem como suas tecnologias e arquitetura.

3.1 Visao geral

Segundo a SUN (2009b), o Java ME e uma colecao de tecnologias e especificacoes que criam

uma plataforma que se ajusta aos requisitos de dispositivos moveis tais como produtos de

consumo, dispositivos embarcados e dispositivos moveis avancados.

O Java ME e a plataforma Java voltada para dispositivos que possuam capacidade de

memoria, tela e processamento restritos. Foi construda com o objetivo de fornecer um

ambiente de execucao Java capaz de lidar com as caractersticas particulares de pequenos

dispositivos.

Para utilizar a mesma plataforma em dispositivos diferentes o Java ME foi baseado

em tres elementos, especificados pela comunidade JCP, que define todos requisitos da

plataforma Java, incluindo a especificacao de APIs. Os tres elementos citados sao: Con-

figuracoes, perfis e pacotes opcionais, os quais funcionam sobre uma maquina virtual

Java, por sua vez ligada a um sistema operacional. Dessa forma podemos representar a

hierarquia dos elementos nas camadas apresentadas na Figura 3.1.

11


21/71

3.1. Visao geral 12

Figura 3.1: Elementos da plataforma Java ME.

Na camada de configuracao sao definidas as bibliotecas necessarias para o funciona-

mento da maquina virtual. A JCP especificou o Java ME em duas configuracoes de acordo

com as necessidades dos dispositivos: CLDC (Connected, Limited Device Configuration)e CDC (Connected Device Configuration), de forma que:

CLDC especifica o ambiente Java para dispositivos com capacidades mais restritas,

como telefones celulares, PDAs e smartphones.

CDC e destinada a dispositivos com maior capacidade de memoria e processamento,

como TV digital, dispositivos sem fio de alto nvel e sistemas automotivos.

Dentro da configuracao existe uma outra classificacao, os perfis. Estes formam um

conjunto de aplicacoes que complementa uma configuracao e fornece funcionalidades para

desenvolver um aplicativo para determinado dispositivo.

O perfil associado a CLDC e o MIDP (Mobile Information Device Profile). E os asso-

ciados a CDC sao: FP (Foundation Profile), PP (Personal Profile), PBP (Personal Basis

Profile), RMIP (Remote Method Invocation Profile) e GP (Game Profile) (JOHNSON,

2007).

Os principais pacotes opcionais estao inseridos em um conjunto de APIs utilizadas com

as configuracoes e perfis para estender funcionalidades nao encontradas nos respectivos

pacotes, como APIs para bluetooh e wireless.

Quanto a maquina virtual, a JCP especifica a CDC HotSpot Implementaion e a CLDC

HotSpot Implementation, que substituram respectivamente a CVM (Compact VirtualMachine), vinculada a configuracao CDC e a KVM (Kilo Virtual Machine), vinculada a

CLDC. A Figura 3.2 mostra a arquitetura da plataforma Java.


22/71

3.2. Configuracoes 13

Figura 3.2: Arquitetura da plataforma Java.

3.2 Configuracoes

A configuracao define uma especificacao padrao para uma mesma classe de dispositivos,

definidos por caractersticas individuais de hardware, como interface, processamento, me-

moria, vdeo, tipo de conexao de rede, entre outras (TOPLEY, 2002). Esta camada possui

as bibliotecas basicas da linguagem, representando a plataforma mnima de desenvolvi-mento para cada tipo de dispositivo. Tais configuracoes sao definidas pelos fabricantes a

fim de proporcionar um ambiente de desenvolvimento para funcionar em um determinado

dispositivo.

Cada configuracao consiste de uma maquina virtual Java (Java Virtual Machine -

JVM), seja da Sun, do proprio fabricante, ou de terceiros e de uma colecao de classes

Java. Devido as restricoes de hardware dos dispositivos moveis, as maquinas virtuais

utilizadas na plataforma Java ME nao suportam todas as caractersticas da linguagem

Java, instrucoes bytecodes e softwares de otimizacao providenciados pela plataforma Java

SE nao sao suportados, sendo assim diferentes das demais JVMs (TOPLEY, 2002).A JCP especificou duas configuracoes para Java ME, CLDC e CDC. Dentre elas abor-

daremos a configuracao CLDC, visto que esta aborda celulares e smartphones, cujo e o

objetivo deste trabalho.

A Connected, Limited Device Configuration - CLDC e a configuracao mnima do Java

ME, formada por um subconjunto de pacotes disponveis na plataforma Java para desktop


23/71

3.2. Configuracoes 14

e abrange os dispositivos com grandes restricoes de processamento, memoria e vdeo, como

celulares, smartphones, pagers e PDAs.

Os dispositivos desta configuracao tem pelo menos 16 ou 32 bits, 160k de memoria

nao volatil (onde sao armazenadas as bibliotecas e a maquina virtual), fonte limitada de

energia e pelo menos 16 Mhz de velocidade. Alem disso e necessario 192k de memoriapara a plataforma Java e suportar conexao com rede sem fio, porem com capacidade de

transmissao limitada (JOHNSON, 2007).

A CLDC esta disponvel nas versoes 1.0 (JSR 30) e 1.1 (JSR 139) (SUN, 2006e). A

principal caracterstica da versao 1.0 e a ausencia de operacoes que use ponto flutuante,

porem ja existem classes que simulam esta propriedade para dada configuracao (CLAU-

SEN, 2003).

Segundo a SUN (2007), as classes desta configuracao estao restritas a apenas quatro

pacotes:

java.io - Tratamento de entrada e sada de dados usando streams (abstracao).

java.lang - Classes basicas da linguagem Java.

java.util - Classes de utilidades genericas (estruturas de dados e manipulacao de

dados).

java.microedition.io - Exclusivamente da plataforma Java ME, incluindo as classes

de conexao.

A CLDC 1.1 e uma configuracao que engloba os pacotes da versao 1.0 e suporta as

seguintes caractersticas:

Ponto flutuante - Possibilita operacoes com variaveis do tipo float/double.

ClassLoading - Classe abstrata responsavel por carregar outras classes.

Garbage Collector - Coletor de lixo dos objetos.

Finalize() - Com esse metodo e possvel liberar recursos e executar outras operacoes

de limpeza antes que o objeto seja recuperado por coleta de lixo (garbage collector).

JNI (Java Native Interface) - Classe de interface nativa que possibilita a maquina

virtual acessar bibliotecas acessadas com o codigo nativo de um sistema.

ThreadGroups - Possibilita que os processos sejam executados simultaneamente,

possibilitando a organizacao das threads em grupos. A multiThreading suporta

multiplas linhas de execucao atraves das funcoes start(), interrupt(), pause(), re-

sume() e stop() para o controle das threads.


24/71

3.3. Perfis 15

RMI (Remote Method Invocation) - Permite o acesso a objetos remotos que podem

ser invocados de diferentes maquinas Java.

3.3 PerfisPerfil e definido como um conjunto de APIs que especificam o nvel de interface de

aplicacoes para um classe de dispositivos (JCP, 2009c). Assim um perfil pode especificar

varios tipos de servicos e funcionalidades de alto nvel, como o ciclo de vida da aplicacao,

elementos de interface grafica, persistencia de dados e meios de comunicacao. Um perfil e

implementado no topo de uma configuracao, sendo assim intimamente ligado a esta, po-

rem compreende bibliotecas mais especficas que as disponibilizadas pelas configuracoes,

ou seja, o perfil complementa a configuracao adicionando classes que fornecem caracte-

rsticas apropriadas para um tipo particular de dispositivos. Tanto os perfis quanto as

configuracoes sao especificacoes de baixo nvel.As aplicacoes moveis sao portanto construdas sobre configuracoes e perfis e podem

apenas usar bibliotecas especificadas por estas. Uma configuracao pode conter varios

perfis, porem um perfil e ligado somente a uma configuracao. E um perfil ainda pode ter

outros perfis ligados a ele (TOPLEY, 2002).

Para a configuracao CLDC temos o perfil MIDP (Mobile Information Device Profile

- JSR 37), que e amplamente utilizado e providencia o desenvolvimento para pequenos

dispositivos, de recursos limitados e com capacidade de conexao sem fio, como os celulares,

smartphones e alguns PDAs. No proximo captulo serao abordados mais detalhes sobre o

perfil MIDP.

3.4 Maquinas Virtuais

A Sun especifica duas maquinas virtuais para a configuracao CLDC: KVM e CLDC

HotSpot Implementation.

KVM

E uma maquina virtual com funcoes reduzidas, com uma pequena memoria e com

um coletor de lixo (garbage collector) incorporado para a otimizacao da memoria

(TOPLEY, 2002). Esta e uma VM (Virtual Machine) especificada pela SUN, que

implementa as necessidades e restricoes impostas pela configuracao CLDC. O K do

termo KVM surgiu para fazer alusao aos poucos kilobytes necessarios para que a

VM execute uma aplicacao. Ela nao compila o codigo e sim o interpreta para o

sistema operacional.


25/71

3.5. Pacotes Opcionais 16

CLDC HotSpot Implementation

E uma VM de alto desempenho e robustez da SUN, para celulares e dispositivos

de caractersticas restritas. Foi implementada para ter um desempenho melhor

que a KVM, utilizando a mesma quantidade de memoria restrita que os pequenos

dispositivos oferecem. Esta maquina virtual suporta CLDC 1.0 e 1.1, porem agora

exige do processador pelo menos 32 bits com uma velocidade de clock de 60 MHz,

600KB de memoria RAM e 2 MB de memoria flash e ROM. Aplica tecnologias

utilizadas na plataforma Java SE e Java EE, incorpora diversos designs inovadores,

diminui o tempo de incio das aplicacoes, oferece vida longa a bateria e possui

compilacao dinamica das instrucoes de bytecode em instrucoes nativas, chamada de

compilacao Just-in-time (SUN, 2008a).

Segundo LUZ (2009), a compilacao Just-in-time e uma das mudancas mais impor-

tantes, pois a compilacao dinamica pode ser cinquenta vezes mais rapida que uma

instrucao interpretada.

3.5 Pacotes Opcionais

Pacotes opcionais sao componentes muito importantes da plataforma Java ME. Po-

demos enxergar como extensoes de perfis, alem de oferecerem apoio em areas com fun-

cionalidades restritas que alguns dispositivos e aplicacoes precisam, tais como troca de

mensagens, multimdia, servicos e localizacao geografica.

Os perfis podem concentrar-se em apoiar apenas as capacidades que a maioria ou

todos os dispositivos em uma classe necessitam, enquanto pacotes opcionais fornecemtipos especficos de funcionalidades. Todos os pacotes opcionais do Java ME sao definidos

pela JCP, estes pacotes tambem sao chamados de APIs. Podendo ser obrigatorios ou

nao, tal decisao cabe aos desenvolvedores ou fabricantes inclu-los em um determinado

produto.

Os pacotes opcionais passam por um processo de aprovacao atraves da MSA (Mobile

Service Architecture) apos serem construdos pelos desenvolvedores. Depois de aprovados

sao disponibilizados seguindo as especificacoes da JCP. Alguns exemplos de pacotes opcio-

nais sao: API para suporte bluetooth (JSR 82), API para acesso as funcionalidades nativas

do aparelho como agenda, calendario e acesso a arquivos (JSR 75 - File Connection API),

API de seguranca e servicos confiaveis (JSR 177), entre outras (SUN, 2009a).


26/71

Captulo 4

Perfil MIDP

Neste captulo sao apresentadas as caractersticas do perfil MIDP, bem como o fun-

cionamento de uma aplicacao. Serao apresentados os principais conceitos relacionados ainterface e armazenamento persistente.

4.1 Visao Geral do MIDP

O MIDP - Mobile Information Device Profile e um perfil suportado pela configuracao

CDLC, onde juntos providenciam um ambiente padrao de execucao Java para os mais

populares dispositivos moveis, como os celulares e PDAs. Este perfil prove um conjunto de

bibliotecas e classes que fornecem suporte ao desenvolvimento de aplicacoes que referem-

se a diferentes aspectos, como sistema de armazenamento persistente, interface com o

usuario, transacoes seguras, gerencia de sons, entre outros.

De acordo com JOHNSON (2007), o MIDP apresenta diversas funcionalidades, entre

elas estao a reproducao de multimdia, suporte a protocolos dos tipos HTTP e sockets,

suporte ao sistema de cores RGB, definicao de formularios e itens, APIs para jogos e

validacao de permissoes de seguranca e assinaturas digitais.

Segundo a SUN (2006e), os recursos mnimos de hardware do perfil MIDP sao:

130KB de memoria nao volatil para persistencia de dados e bibliotecas da CLDC

32KB de memoria volatil para a execucao do Java

Conectividade com algum tipo de rede sem fio

Interface grafica

Uma tela de pelo menos 96 pixels de largura por 54 de altura

17


27/71

4.1. Visao Geral do MIDP 18

Alguns recursos mnimos de software tambem sao requeridos, tais como: possuir re-

cursos suficientes para executar a maquina virtual Java, tratamento de excecoes, pro-

cessamento de interrupcoes, acesso de leitura e escrita a rede sem fio, mecanismos para

capturar a entrada de dispositivos de entrada, recursos para ler e gravar em memoria nao

volatil, oferecendo suporte persistente aos dados e escrita de elementos graficos na tela(JOHNSON, 2007).

As especificacoes deste perfil sao definidas pela JCP, definindo uma plataforma para

desenvolvimento seguro e dinamico. Atualmente o MIDP possui as versoes 1.0 (JSR

37), 2.0 (JSR 118), 2.1 (JSR 118) e 3.0 (JSR 271). Porem esta ultima ainda nao esta

disponvel para utilizacao. A versao 1.0 trabalha integrada com a configuracao CLDC

1.0 ou 1.1. Nao tem nenhuma API ativa para renderizacao, nao oferece suporte para

acesso direto aos pixels de imagens, nao tem suporte para full screen/full canvas sem

uma API proprietaria e tambem nao possui suporte direto para audio. Inclui APIs para

o ciclo de vida de aplicacoes, conectividade de redes HTTP, interface com o usuario earmazenamento persistente. O unico protocolo de rede que o MIDP 1.0 suporta e o

HTTP (SUN, 2002).

Segundo a SUN (2006c), os pacotes suportados pela versao 1.0 sao:

javax.microedition.io - Fornece suporte ao framework GenericConnection da confi-

guracao CLDC.

javax.microedition.lcdui - API que providencia um conjunto de caractersticas para

a implementacao de interfaces com o usuario.

javax.microedition.rms - Providencia um mecanismo de persistencia de dados para

MIDlets.

javax.microedition.midlet - O pacote MIDlet define aplicacoes MIDP e interacoes

entre as aplicacoes e o ambiente no qual a aplicacao e executada.

A versao 2.0 e compatvel com a versao 1.0 e adiciona novas melhorias como suporte

a conexao segura (HTTPS), biblioteca de multimdia, formulario de entrada de dados

aprimorada, sensvel melhoria na API de suporte a games, conceito de aplicacoes confiaveis

(trusted) e nao confiaveis (untrusted). Alem de HTTPS, o MIDP 2.0 suporta HTTP,

datagramas, sockets e SMS (Short Message Service). Quanto a multimdia, um conjunto

de APIs foram introduzidas, que sao na verdade um subconjunto da Mobile Media API(MMAPI). Com estas APIs podem ser gerados simples toques, sequencias mais completas

ou ate mesmo musicas completas no formato WAV, alem de poderem ser implementados

em outros formatos.

Dentre as mudancas nos formularios de entrada destacam-se a nova aparencia do Form

que e consideravelmente mais sofisticada do que era no MIDP 1.0 e a classe Item, onde


28/71

4.1. Visao Geral do MIDP 19

agora podem ser especificados layouts horizontais, verticais, novas linhas antes ou depois

de itens, entre outros. Um novo item tambem foi criado, o Spacer, que serve pra colocar

espacamentos entre os demais itens disponveis. Tambem foi introduzido o tipo pop up ao

item choiceGroup, que sera estudado a frente.

No MIDP 2.0 tambem foram estendidos os comandos de manuseio. Adicionar co-mandos aos itens agora e permitido. Tambem foi introduzida a classe CustomItem, que

permite ao programador criar seus proprios itens. Nesta versao o suporte a jogos ganha

uma melhoria com o suporte a camadas na tela. Uma camada pode conter um fundo, ou-

tra mostrar objetos, uma terceira camada poderia mostrar esfeitos especias ou qualquer

outra coisa. Outra mudanca e o surgimento da classe GameCanvas, uma subclasse de

Canvas - classe de baixo nvel que proporciona o desenvolvimento de jogos. Nesta versao

as imagens podem ser representadas em arrays de inteiros e tambem suporta imagens em

RGB (SUN, 2002).

Segundo a SUN (2006d), os pacotes que foram adicionados a esta versao sao:

javax.microedition.lcdui.game - Providencia classes para o desenvolvimento de con-

teudo rico para jogos em dispositivos wireless.

javax.microedition.media - Compatvel com as especificacoes da API Mobile Media

(JSR 135).

javax.microedition.media.control - Define o tipo especfico, control, que pode ser

usado como um player.

javax.microedition.pki - Autentica informacoes para conexoes seguras, atraves decertificados.

A versao 2.1 do MIDP reforca a especificacao MIDP 2.0 tornando a diretiva layout LC-

DUI obrigatoria, os pacotes javax.microedition.io.SocketConnection e javax.microedition-

.io.HTTPConnection nao sao mais opcionais, entre outros requisitos para aprimorar a

versao 2.0.

A versao 3.0 traz melhor suporte para dispositivos com telas maiores, suporte a MI-

Dlets para desenhar em telas secundarias, armazenamento RMS seguro e acesso remoto a

bancos RMS (JCP, 2009a). Esta versao requer no mnimo 1MB de memoria volatil e tela

de pelo menos 176x220 pixels. Ela e compatvel com o CLDC 1.0, mas o recomendado eo 1.1 e possui compatibilidade com as outras versoes do MIDP. No MIDP 3.0 a tela de

splash pode ser carregada sem a necessidade de ser criada uma classe em canvas com uma

imagem e tempo controlado manualmente. Isto pode ser feito atraves de um atributo no

arquivo JAD, um arquivo de descricao da aplicacao, que sera explicado posteriormente.

Os protetores de tela agora sao aplicacoes que sao destrudas pelo gerenciador quando


29/71

4.2. MIDlets 20

alguma tecla e pressionada ou algum evento e disparado. Alem destas funcionalidades,

o MIDP 3.0 apresenta suporte a IP versao 6, o que possibilita fazer parse de um ende-

reco IPv6 e a possibilidade de compartilhar bibliotecas entre os MIDlets em tempo de

execucao, conhecido como LIBlets (LUZ, 2009).

4.2 MIDlets

E uma aplicacao Java destinada para dispositivos moveis desenvolvida com a utilizacao

do perfil MIDP, que esta vinculado a configuracao CLDC (MUCHOW, 2001).

Todo dispositivo movel tem um gerenciador de aplicativos (AM - Application Mana-

ger) que controla os aplicativos a serem instalados, onde e como serao armazenados e

como serao executados. A comunicacao do gerenciador com o MIDlet acontece pela classe

MIDlet do pacote javax.microedition.midlet.MIDlet. Os MIDlets devem herdar esta classe

MIDlet que contem metodos que inicializam, resumem, interrompem a execucao e des-troem MIDlets.

Uma aplicacao e iniciada quando o AM invoca o metodo startApp(), colocando a

aplicacao no modo ativo. Enquanto estiver executando ela pode ser pausada pela AM

atraves do metodo pauseApp(), isto pode ocorrer quando uma chamada for recebida por

exemplo ou o proprio usuario pode pausar a aplicacao. E quando a aplicacao e encerrada

ela passa para o estado destrudo, atraves do metodo destroyApp(), que limpa todos os

recursos para fechar a aplicacao (JOHNSON, 2007).

O ciclo de vida do MIDlet e apresentado na Figura 4.1.

Figura 4.1: Ciclo de vida do MIDlet.

Estes tres metodos, segundo MUCHOW (2001), trata-se da comunicacao que parte

do gerenciador de aplicativos para o MIDlet. Alem destes metodos, tambem existem

outros tres onde a comunicacao parte do MIDlet para o gerenciador de aplicativos. Estes

metodos sao:


30/71

4.3. MIDlets Suite 21

notifyDestroy(): Avisa ao gerenciador que pode desligar a MIDlet.

notifyPaused(): Envia o pedido de pausa para o gerenciador caso a MIDlet queira

pausar.

resumeRequest(): Avisa ao gerenciador que a MIDlet pode tornar-se ativa novamente.

4.3 MIDlets Suite

MIDlet Suite consiste em um ou mais MIDlets que sao juntados em um Java Ar-

chive (JAR). E composto por classes Java, recursos e um arquivo de manifesto, que estao

situados dentro do arquivo JAR e um arquivo de descricao, chamado Java Application

Descriptor (JAD). Dentre os recursos estao imagens, dados da aplicacao, entre outros.

No arquivo de manifesto, cuja extensao e .mf, esta a descricao do JAR. E o arquivo JAD

descreve os detalhes da aplicacao, repetindo muitos do dados que estao no arquivo de

manifesto, porem este arquivo esta fora do JAR e pode ser acessado antes de se insta-lar o arquivo JAR no aplicativo (JOHNSON, 2007). As proximas subsecoes descrevem

detalhadamente cada um desses arquivos.

4.3.1 JAR

Todas as MIDlets sao empacotadas antes de serem transferidas a um dispositivo, isso

e feito atraves de um metodo de compressao onde sao colocadas todas as informacoes em

um unico arquivo cuja extensao e .JAR. Este arquivo engloba classes Java, recursos e

informacoes do empacotamento, com citado anteriormente (MUCHOW, 2001).

O arquivo JAR providencia muitos benefcios, como: seguranca, atraves de assinaturasdigitais; compressao; empacotamento de extensoes, juntando varios tipos de extensoes

diferentes em uma unica: o .JAR; portabilidade e o fato de quando e necessario fazer o

download de uma aplicacao apenas um arquivo deve ser baixado (SUN, 2008b).

4.3.2 JAD

Conforme estudado, alem do JAR e criado um arquivo em separado de extensao .JAD

que contem informacoes sobre o MIDlet. Este arquivo e usado muitas vezes para preparar

o JAR para ser instalado, otimizando a instalacao do aplicativo, porem nem todos os

aparelhos precisam ler o .JAD para realizar a instalacao. O arquivo JAD possui a seguinte

estrutura:

MIDlet-Name: Nome da Suite MIDlet.

MIDlet-Version: Versao da MIDlet.

MIDlet-Vendor: Desenvolvedor da MIDlet.


31/71

4.4. Interface 22

MIDlet-Icon: Especifica o cone da tela inicial da aplicacao.

MIDlet-Description: Descricao da aplicacao.

MIDlet-info-URL: Endereco para um arquivo de informacoes (JAR).

MIDlet-DATA-Size: Tamanho dos dados.

4.4 Interface

Os dispositivos moveis que implementam o perfil MIDP possuem diversas restricoes

quando se trata de interface, podendo variar em tamanho de tela, numero de cores apresen-

tadas na tela, disposicao dos botoes, etc. E estas informacoes sao acessadas pela MIDlet

somente em tempo de execucao. Sendo assim, o MIDP so permite a utilizacao de objetos

visuais simples, nao sendo permitida a implementacao de objetos comuns na versao Java

para desktop (JOHNSON, 2007).

O Java ME tem como padrao para construcao de interfaces a biblioteca LCDUI, quee responsavel pelos componentes que formam a interface de aplicacoes MIDP. Nesta se-

cao estudaremos algumas classes desta biblioteca, que estao dispostas de acordo com a

hierarquia mostrada na Figura 4.2.

Figura 4.2: Hierarquia de classes.


32/71

4.4. Interface 23

Display e Displayable

Para desenvolver interfaces que se encaixem em dispositivos moveis com diferentes

caractersticas de tela, as aplicacoes sao desenvolvidas com uma certa abstracao. Para

acessar as informacoes de um determinado aparelho existe a classe Display e cada MIDletpossui sua propria instancia desta classe que pode ser acessada pelo metodo getDisplay(),

que geralmente esta contido no metodo startApp(), pois o Display so pode ser acessado

depois que aplicacao tenha sido iniciada.

Portanto, a tela do dispositivo e representada por uma instancia da classe Display,

que representa o hardware, e para que seja mostrado algo na tela devemos passar um

objeto Displayable para o objeto da classe Display. Displayable e uma classe abstrata

que controla o que e mostrado na tela e os comandos enviados pelos usuarios. Eles

representam conteudos de uma tela na qual ha interacao com o usuario (JOHNSON,

2007). Cada aplicacao possui apenas uma instancia da classe Display, sendo assim podem

existir varios objetos Displayable mas apenas um e mostrado por vez (MUCHOW, 2001).Os objetos Displayable que estao na memoria, mas nao estao sendo mostrados estao no

chamado background e o objeto que esta sendo mostrado esta no foreground. Portanto os

objetos que estao no background nao tem acesso ao Display. Para mostrar um Displayable

na tela usamos o metodo setCurrent() e para obter qual objeto esta sendo mostrado no

Display usamos o metodo getCurrent() (JOHNSON, 2007).

A classe Displayable da origem a duas outras classes: Screen e Canvas. Ambas sao

classes para representar interfaces, porem a primeira classe, juntamente com suas subclas-

ses formam componentes de interface de alto nvel e a segunda de baixo nvel (MUCHOW,

2001).

Screen

Screen e uma classe que contem objetos graficos prontos, onde cada uma pode ter uma

aparencia, variando de acordo com o dispositivo em que esta sendo executada a aplicacao

(JOHNSON, 2007). Screen e suas herancas sao classificadas como objetos de interface de

alto nvel (High-Level APIs) e as herancas desta classe sao as classes Form, List, Alert e

Textbox (MUCHOW, 2001).

Form

Form e um formulario o qual pode conter textos, imagens e outros componentes para

serem exibidos no visor. Varios componentes podem ser colocados em um Form e se

houver necessidade ele apresenta barra de rolagem automatica para mostrar todos estes

componentes visuais. Porem nada muito extenso e viavel para aplicacoes moveis.


33/71

4.4. Interface 24

Esses componentes que podem ser adicionados em um Form sao subclasses da classe

Item e serao estudados posteriormente. Um Form possui metodos para adicionar, inserir,

apagar e substituir componentes. Estes componentes da classe Item so pode ser inseri-

dos em um Form e nao em outras telas da classe Screen, como List, Alert ou Textbox

(MUCHOW, 2001).

Item

Conforme mostrado um Item e um componente que pode ser inserido em um Form e

suas subclasses sao:

StringItem

E um simples texto estatico, ou seja, nao pode ser editado.

TextFieldE um campo para entrada e/ou edicao de texto. Podendo ser associadas regras a

este. Por exemplo: aceitar somente numeros, qualquer caracter, ser um campo de

senha, entre outros.

ImageItem

Permite inserir uma imagem.

ChoiceGroup

E uma lista de escolhas, dentro de um Form. Possui os tipos: multiplo, exclusivo

ou pop up.

1. Multiplo: Podem ser selecionadas varias opcoes, marcando uma caixa de che-

cagem que acompanha os elementos da lista;

2. Exclusivo: Pode ser selecionado apenas uma opcao e esta e marcada com um

radioButton.

3. Pop up: Pode ser selecionada apenas uma opcao. A lista e exibida como

uma comboBox, ou seja, os elementos ficam escondidos e quando clicada esta

lista toda e exibida. Apos a selecao de um elementos os outros elementos sao

escondidos novamente.

DataField

Campo utilizado para exibir e/ou entrar com data e/ou hora.


34/71

4.4. Interface 25

Gauge

E uma representacao grafica de um numero inteiro. Ele permite que o usuario

defina um nvel, como o volume por exemplo, se for um Gauge interativo. Se for

nao interativo e somente o programa que o controla (MUCHOW, 2001).

Spacer

Determina um espacamento vertical e/ou horizontal mnimo entre os componentes

de um Form. Ele e utilizado por questoes de design de layout.

CustomItem

Utilizado para criar itens especficos, atraves de desenhos, utilizando a classe Graphics

da API de baixo nvel (MATTOS, 2005).

List

E uma lista que permite ao usuario selecionar opcoes. Estas podem ser tanto uma

String quanto uma imagem. O List pode ser exclusivo, multiplo ou implcito. Implcito e

quanto a lista e exibida sem nenhum marcador e somente uma opcao pode ser escolhida,

gerando um evento quando e selecionada uma das opcoes. Os outros dois tipos funcionam

igualmente ao ChoiceGroup (MATTOS, 2005).

Alert

E uma tela de informacao ao usuario. Pode conter uma mensagem de erro, de sucesso,

de informacao, entre outras. Ele pode ser programado para ser exibido durante um tempopre determinado, pode ser composto de um texto e uma imagem e sua aparencia varia de

acordo com o dispositivo movel usado (MATTOS, 2005).

TextBox

Basicamente e uma tela que serve para entrada e edicao de texto. E como se fosse um

Item textField, porem so existe ele na tela. Em um textBox tambem podem ser usadas

regras, assim como em um textField (SUN, 2006b).

Canvas

Canvas e uma classe de baixo nvel, que proporciona maior liberdade na implementacao

dos graficos e eventos. E destinada a aplicacoes que necessitam de posicionamento preciso

dos elementos graficos, sendo portanto muito utilizada para a criacao de jogos.


35/71

4.5. Armazenamento Persistente 26

Atraves da utilizacao desta classe e possvel desenhar na tela. O desenvolvedor cria

o que sera mostrado para o usuario final. Para criar uma interface grafica com canvas e

utilizado a classe Graphics, que fornece metodos para desenhar linhas, arcos, retangulos

e textos, alem de especificar cores e fontes (MUCHOW, 2001).

Alem de desenhar interfaces, a classe canvas permite controlar eventos primitivos,como teclas pressionadas e liberadas e acessar dispositivos de entrada de dados, como

teclados em geral, toques, em telas touchScreen, entre outros (MATTOS, 2005).

Command

A classe Command permite adicionar comandos, ou seja, funcoes, aos objetos mostra-

dos na tela (JOHNSON, 2007). Os comandos sao usados para a interacao do usuario com

a aplicacao podendo ser atribudos a qualquer Displayable, de alto ou baixo nvel, e a um

Item. Quando um comando e acionado pelo usuario, e notificado a um CommandListener

que e definido no objeto Displayable. Um command contem somente uma informacaosobre o comando e nao sobre qual acao realizar. A acao e definida no CommandListener

associado ao Displayable (SUN, 2006a).

CommandListener: E uma interface usada para tratar os eventos, controlando quais

e quando os eventos foram acionados. O commandListener vincula um comando a um

gatilho, detectando quais comandos foram ativados e definindo gatilhos para eles. Quando

um comando e acionado, o commadAction o captura, juntamente com o Displayable atual

(JOHNSON, 2007).

4.5 Armazenamento Persistente

Os dispositivos moveis que usam o perfil MIDP possuem, como memoria volatil, a

memoria RAM e, como memoria de armazenamento persistente, a memoria flash. Esta

permite armazenar dados por longos perodos de tempo, sem a necessidade de ser mantida

energizada por uma bateria ou fonte eletrica.

As vantagens da memoria flash sao: o pequeno tamanho fsico, a resistencia a choques,

o alto desempenho para a leitura de dados, entre outros. E algumas de suas desvantagens

sao o fato de as operacoes de escrita serem lentas e a capacidade de armazenamento ser

restrita. Porem, a maioria dos dispositivos moveis contam com um cartao de memoria,

que serve como um drive de armazenamento. O cartao oferece solucao ao armazenamento

restrito, porem o seu acesso e mais lento se comparado com o acesso a memoria flash

interna.

Para o armazenamento persistente o perfil MIDP utiliza a API RMS (Record Mana-

gement System - Sistema de gerenciamento de armazenamento) e a API JSR-75 - File


36/71

4.5. Armazenamento Persistente 27

Connection, que implementa um sistema de armazenamento em arquivos. Porem nao sao

todos os dispositivos que fornecem acesso a esta ultima API (LUGON, 2005).

4.5.1 RMS

A API RMS e o mecanismo padrao para persistencia de dados oferecido pelo MIDP. O

RMS funciona como um banco de dados orientado a registros, apresentando-se diferente

dos tradicionais bancos de dados relacionais conhecidos. Ele e composto por Record Stores,

que sao como armazens de dados, conforme mostra a Figura 4.3.

Figura 4.3: Record Management System.

Um Record Store e identificado por um nome, que e case sensitive e e criado por um

MIDlet. Entao quando um MIDlet e removido de um dispositivos todos os Record Stores

relacionados a ele serao removidos tambem. O limite de armazenamento e o mesmo que

o dispositivo oferecer.

A API RMS nao suporta tipos caractersticos de outros banco de dados, como ta-

belas, colunas ou linhas, nela cada registro, chamado Record, e um array de bytes. Por

causa disso a aplicacao deve converter os dados para array de bytes para poderem ser

armazenados. Para ler os dados o processo inverso deve ser feito ( MUCHOW, 2001).

Contudo, podemos imaginar o Record Store como um conjunto de linhas, onde cada

linha e um registro (Record) e estes sao identificados por uma chave primaria, chamada

Record ID, que e um inteiro. Logo, cada registro e formado por um inteiro e um array de

bytes. A API fornece metodos para abrir, fechar e deletar um RecordStore inteiro. Alemdestes existem metodos para a manipulacao dos registros como, adicionar, modificar,

deletar, recuperar um registro e a quantidade de registros existentes (SOUSA, 2006).


37/71

Captulo 5

APIs e Frameworks para Java ME

Atraves de frameworks e APIs especficas e possvel construir aplicacoes com mais

recursos, dispondo de varias funcionalidades extras, que nao sao encontradas nas especi-ficacoes do perfil MIDP, alem de otimizar o desenvolvimento. Este captulo lista algumas

APIs e frameworks mais utilizados no desenvolvimento de aplicacoes para celulares e

smartphones, utilizando a plataforma Java ME, destacando-se os que foram utilizados no

estudo de caso e explica o porque da escolha destes.

5.1 APIs

Com APIs podemos desenvolver aplicacoes que se conectam a servidores remotos, com

outros aparelhos, aplicacoes que utilizam bluetooth, que executam musicas e vdeos, entre

outras. Algumas das APIs opcionais disponveis para o perfil MIDP sao citadas por

(JOHNSON, 2007).

Java APIs for Bluetooh (JSR 82) - Permite o desenvolvimento de aplicacoes para

acesso a rede bluetooh.

Location API (JSR 179) - Permite o desenvolvimento de aplicativos baseados em

localizacao fsica (LBS).

Mobile Game API (JSR 178) - Voltada para criacao de jogos.

Mobile Media API (JSR 135) - Permite reproducao de mdia.

Security and Trust Services API for J2ME (JSR 177) - Usada para adicionar segu-

ranca as aplicacoes.

Wireless Messaging (JSR 120 e 205) - Permite troca de mensagens SMS.

28


38/71

5.1. APIs 29

Entre outras APIs opcionais importantes para auxiliar no desenvolvimento de aplica-

coes temos:

File Connection API (JSR 75) - Permite acesso e armazenamento em arquivos e

acesso a programas nativos do dispositivo, como agenda, calendario, entre outros.

Mobile Sensor API (JSR 256) - Permite a recuperacao de dados de sensores internos

ou externos ao aparelho celular.

MECHART - Uma API de terceiro, ainda nao catalogada pela JCP, que permite

construir graficos de maneira simples e rapida, sem a necessidade de programar

diretamente na classe Canvas.

Dentre estas, vamos estudar a FileConnection API, pois alem de ser uma das mais

usadas por desenvolvedores da plataforma Java ME, possui maior reconhecimento e sera

de grande utilidade para o projeto que desenvolveremos posteriormente.E importante dizer que a JCP ate o momento tem catalogado 927 JSRs na plataforma

Java (JCP, 2009b). E para a plataforma Java ME foram especificadas 83 JSRs, entre elas

APIs opcionais.

File Connection API

A JSR 75 especifica dois pacotes obrigatorios para a plataforma Java ME:

O PIM - Pacote que permite desenvolvedores acessar os dados de PIM do aparelho,tais como agenda, livro de enderecos e listas de tarefas, que existe na maioria dos

dispositivos moveis.

O Pacote opcional de conexao de arquivos (FCOP) - Permite aos desenvolvedores

o acesso a diversas formas de dados, tais como: imagens, sons, vdeos, textos en-

tre outros tipos de dados do sistema de arquivo do dispositivo movel. Isto inclui

dispositivos de armazenamento removveis, como cartoes de memoria.

O PIM e os arquivos de dados permitem a integracao de aplicacoes com informacoes

sobre o dispositivo, permitindo aplicacoes mais inteligentes (SUN, 2009c).Abaixo estao as importantes classes e interfaces:

ConnectionClosedException - Lancada quando um metodo e invocado em uma Fi-

leConnection quando a conexao e fechada.


39/71

5.2. Frameworks 30

FileSystemRegistry - Classe central de registros que possui a habilidade de listar

roots montadas atraves do metodo listRoots(). Ela tambem providencia metodos

para os ouvintes de registros (Registering listeners), estes sao notificados se sistemas

de arquivos sao adicionados ou removidos durante o tempo de execucao.

A FileSystemListener interface - Usada para recepcao de notificacoes de status

quando e adicionado ou removido um sistema de arquivo raz.

A FileConnection interface - Usada para acessar diretorios e arquivos no dispositivo.

Ela estende a Connection interface e mantem inumeros metodos uteis para criar,

remover diretorios e arquivos, lista de conteudo de diretorios, configurar permissoes,

obter informacoes de arquivos e efetuar operacoes de entrada e sada nos arquivo.

Os pacotes usados sao:

javax.microedition.pim

javax.microedition.io.file

No desenvolvimento do estudo de caso foi explorado o pacote opcional de conexao de

arquivos (FCOP), dependente apenas do nucleo de classes definidas pelo CLDC.

A forma de acessar os arquivos e utilizando a FCOP atraves da interface FileConnec-

tion, muito usada por sinal. Para isto basta importar o pacote javax.microedition.io.file.-

FileConnection.

A FileConnection estende StreamConnection pela adicao de metodos de arquivo e

diretorio de manipulacao. A funcionalidade adicional e semelhante a que se encontradisponvel no J2SE, na classe java.io.File. Para a abertura de um arquivo e usado uma

URL no formato: file://host/path

Enfim, com metodos mais especficos desta API e possvel manipular arquivos dentro

do aparelho, sem a necessidade de trabalhar com classes de baixo nvel (NOKIA, 2008).

5.2 Frameworks

Entre os frameworks mais utilizados para a otimizacao no desenvolvimento de aplica-coes para dispositivos moveis estao:

Floggy - Framework para persistencia de dados.

J2MicroDB - Fornece um banco de dados relacional limitado para dispositivos mo-

veis.


40/71

5.2. Frameworks 31

Perst Lite - Banco de dados orientado a objetos para aplicacoes embarcadas.

JMESQL - Banco de dados relacional escrito em Java.

KXML - Realiza o parser de arquivos XML.

LWUIT - Possibilita o desenvolvimento de interfaces ricas (RIA) e robustas.

Java2ME Polish - Framework para personalizar a UI (User Interface) do MIDlet

sem alterar o codigo fonte.

Diamont Powder - Acelera a criacao de aplicacoes para coleta de dados.

Fire (Flexible Interface Rendering Engine) - Framework para o desenvolvimento de

interfaces mais atraentes que as compreendidas pelo MIDP.

Marge - Facilita o desenvolvimento de aplicacoes em Java que fazem uso de bluetooth

Entre os frameworks citados neste trabalho, astraves de testes, os que melhor atende-

ram ao desenvolvimento do estudo de caso foram: o Floggy, pois abstrai significativamente

a complexidade dos codigos RMS para a persistencia de dados, o LWUIT, que fornece in-

terfaces bastante atraentes, alem de estar caminhando para ser o framework referencia

em UI, por fim o KXML, para fazer o parse de XMLs, usado para interpretar os dados

trocados entre servidor e aplicacao movel.

5.2.1 Floggy

Uma das limitacoes impostas pelo perfil MIDP e a utilizacao da API RMS, na maioria

dos dispositivos, para a persistencia de dados. Visando a dificuldade dos codigos utilizados

para acessar esta API surgiu o Floggy, framework de persistencia free para J2ME/MIDP,

desenvolvido por brasileiros. Seu principal objetivo e abstrair os detalhes da persistencia

de dados para o desenvolvedor, reduzindo os esforcos de desenvolvimento e manutencao

(FLOGGY, 2009).

O Floggy utiliza comandos de alto nvel para encapsular os comandos necessarios para

o armazenamento e recuperacao de objetos, ou seja, o que esta por tras deste framework

sao codigos para acessar a API RMS (LUGON, 2005).O framework e composto por dois modulos:

- Framework: responsavel por fornecer os metodos de persistencia como salvar, remover

e recuperar os dados, atraves de um arquivo JAR (11KB) que deve ser adicionada na

aplicacao.


41/71


42/71

5.2. Frameworks 33

o acesso, parse e exibicao de XMLs e e destinado principalmente a ambientes restritos

como em dispositivos que usam o perfil MIDP (HAUSTEIN, 2007).

Possui as tres versoes. A primeira versao foi criada para dispor a tecnica pull parser

em dispositivos moveis e embarcados e e baseada em eventos de objetos. A segunda versao

e a versao corrente e possui caractersticas de cursor em vez de se basear em eventos deobjetos. A terceira versao ainda esta sendo produzida.

Segundo LECHETA (2006), as principais operacoes do KXML sao:

nextTag(): Aponta para o proximo incio ou fim de tag, pulando eventos insignifi-

cantes como espacos em branco ou comentarios.

Require(): Obriga o cursor a ser posicionado onde for indicado.

nextText(): Exige que a posicao corrente seja uma tag de incio. Retorna o texto

contido no elemento correspondente.

getName(): Obtem o nome da tag na posicao corrente.

Um analisador de XML deveria nao aceitar ou reconhecer documentos com erros,

porem devido as restricoes dos dispositivos moveis isto nao e possvel. Garantir que o

documento esteja com uma sintaxe correta faz parte da tarefa do desenvolvedor. Como

falado anteriormente este framework foi desenvolvido para ser usado em ambientes res-

tritos, o que nos leva a estuda-lo para a aplicacao que sera desenvolvida (HAUSTEIN,

2007).

5.2.3 LWUIT

O LWUIT (LightWeight User Interface Toolkit) e um framework para a criacao de

interfaces graficas ricas em dispositivos moveis, que suportam a tecnologia Java ME.

Inspirado no Swing da plataforma Java SE, foi projetado para ser o mais leve possvel,

comprometendo o mnimo possvel a aplicacao final, visto que foi desenvolvido para dis-

positivos com capacidades restritas (SUN, 2009d).

Com o LWUIT nao ha mais necessidade de se desenhar telas em canvas para construir

interfaces mais amigaveis, e uma grande evolucao visto que a complexidade para tal

tarefa e muito alta. O framework oferece melhorias a componentes graficos de alto nvelja existentes no Java ME, como List, Form, Alert, entre outros. Ainda oferece varias

outras vantagens como suporte a touch Screen, diversas fontes, animacoes, transicoes de

telas animadas e temas variados, que podem ser includos pelos proprios usuarios.

Alem das caractersticas citadas acima, o LWUIT tambem inclui: a utilizacao de

layouts, que organizam a disposicao dos componentes na tela, alem de oferecer melhor


43/71

5.2. Frameworks 34

portabilidade, integracao 3D (se o dispositivo possuir bibliotecas 3D), caixas de dialogo,

utilizacao de abas (como no Java SE) e internacionalizacao. O LWUIT roda no perfil

MIDP 2.0 e esta sob a licenca GPL v2.0 com a Classpath Excepption, o que significa que

pode ser utilizado em aplicacoes de codigos nao abertos, desde de que nao haja modificacao

nas classes do framework (NETO, 2008).O framework foi recentemente incorporado pela Sun como uma de suas bibliotecas

padroes, no Java ME Plataform SDK 3, que substitui o WTK (Wireless ToolKit) - para

CLDC e o CDC ToolKit, o que promete ainda mais alavancar a utilizacao do LWUIT

dentro da comunidade de desenvolvedores (DOEDERLEIN, 2009).


44/71

Captulo 6

Comunicacao com o Servidor

Neste captulo sao apresentadas algumas caractersticas da plataforma Java Enterprise

Edition (Java EE), a fim de estudar um metodo eficiente para a construcao de servidoresde dados remotos para alimentar qualquer sistema movel que necessite deste tipo de

comunicacao.

6.1 A Plataforma Java EE

Existem diversas tecnologias que fornecem aplicacoes com conteudo dinamico e per-

sonalizado, seja para construir um simples site de conteudo dinamico ou um sistema

complexo de e-business com banco de dados que integram sistemas corporativos. A pla-

taforma Java EE fornece um conjunto de tecnologias para o desenvolvimento de aplicacoes

robustas para a Web. Dentre as tecnologias disponveis atualmente, destacam-se para o

desenvolvimento de aplicacoes os servlets e paginas JSP (JavaServer Pages). servlets e

JSP sao duas tecnologias desenvolvidas pela Sun para desenvolvimento de aplicacoes na

Web a partir de componentes Java que executam no lado do servidor. A Figura 6.1 ilustra

a arquitetura da plataforma Java EE.

A utilizacao de servlets oferece diversas vantagens em relacao a outras tecnologias para

o desenvolvimento de aplicacoes Web. As principais vantagens sao herdadas da propria

linguagem Java, entre elas estao: Portabilidade, facilidade de programacao e a flexibilidade

da linguagem para o desenvolvimento. Em particular, os servlets sao mais eficientes,apresentam melhor usabilidade, maior poder na programacao, sao mais portateis, mais

seguros e mais baratos que um CGI (Common Gateway Interface) tradicional (HALL,

1998).

35


45/71

6.1. A Plataforma Java EE 36

Figura 6.1: Arquitetura da plataforma Java EE.

CGI e um padrao que determina a forma de comunicacao entre o servidor Web e

uma outra aplicacao rodando neste servidor e um script CGI e um programa que atende

requisicoes enviadas por um cliente e repassa para um servidor HTTP ( QUIN, 2009).

Um servlet tem um modelo de programacao parecido com um script CGI, porem os

programas de CGI necessitam de um processo para tratar cada nova solicita cao e no caso

dos servlets, podem existir varios ligados ao mesmo servidor, que estes sao executados

dentro de um mesmo processo. E este processo roda dentro de uma JVM, que gera

um encadeamento de processos para tratar cada solicitacao. Estes encadeamentos geram

muito menos overheads do que processos completos (PITTELLA, 2009).

6.1.1 Servlets

Segundo HALL (1998), servlet e uma resposta da tecnologia Java para a programacao

CGI. Sao programas que rodam em sevidores Web agindo como uma camada mediana

entre um pedido que vem de um browser Web ou outro cliente de HTTP.

O trabalho dos servlets se resumem em:

Ler qualquer dado enviado pelo usuario.

Observar qualquer outra informacao sobre o pedido que e embutido no pedido de

HTTP.

Gerar os resultados.

Formatar os resultados dentro de um documento.

Fixar parametros de resposta de HTTP apropriados.


46/71

6.1. A Plataforma Java EE 37

Enviar de volta o documento ao cliente.

Servlets sao classes Java instaladas junto a um Servidor que implemente um Servlet

Container, interagindo com clientes Web usando o paradigma request-response, ou seja,

um programa Java que estende funcionalidades de um servidor de aplicacoes Java quepermite a execucao de servlets comunicando com clientes.

O componente container, ou conteiner, e resposnsavel por dar suporte as APIs de

servlets e JSP. Gerencia as instancias dos servlets e fornece os servicos de rede necessarios

para as requisicoes e respostas. O container pode criar varias threads permitindo que

uma unica instancia servlet atenda mais de uma requisicao simultaneamente. A Figura

6.2 ilustra a relacao entre esses componentes.

Figura 6.2: Servlet container.

Os servlets sao independentes de protocolos e plataformas, podendo trabalhar comdiversos tipos de servidores, pois a API dos servlets nao assume nada a respeito do am-

biente do servidor. Diversas requisicoes podem ser feitas ao mesmo tempo em um unico

servidor.

O comportamento dos servlets que sera estudado para a construcao de aplicacoes

esta definido na classe HttpServlet do pacote javax.servlet. Tendo em vista o paradigma

request-response, cujo atende requisicoes realizadas por meio do protocolo HTTP, os ob-

jetos dos servlets podem capturar parametros desta requisicao, efetuar qualquer proces-

samento inerente a uma classe Java e enviar respostas na forma de paginas HTML, XML,

imagens entre outros (TEMPLE, 2004).Um servlet e basicamente definido pela Interface Servlet, uma classe de interface que

implementa os metodos init(), service() e destroy(), e a estrutura de uma classe servlet

contem os metodos doGet() e doPost(), como ilustrado na Figura 6.3.

Todos os seguintes metodos sao invocados por meio do metodo service() da classe de

interface.


47/71

6.2. XML - Linguaguem de marcacao extensvel 38

Figura 6.3: Ciclo de vida do servlet.

Metodo doGet: Trata requisicoes do tipo GET. Esse tipo pode ser enviado varias

vezes e alocado em um bookmark.

Metodo doPost: Trata requisicoes do tipo POST, permitindo que o cliente envie

dados do servidor Web uma unica vez.

Metodo doPut: Trata requisicoes do tipo PUT, permitindo que o cliente enviearquivos para o servidor, semelhante ao FTP.

Metodo doDelete: Trata requisicoes do tipo DELETE, permitindo que o cliente

remova determinada pagina ou documento do servidor.

Um servlet nao possui interface grafica, porem dentro de um servlet e possvel construir

um HTML, mas a visualizacao e entendimento e de alta complexidade quando se trata

de logicas extensas. Tendo em vista que o foco do estudo de caso esta em um ambiente

movel, nao e necessario a construcao de uma interface grafica para trabalhar junto com o

servlet.

6.2 XML - Linguaguem de marcacao extensvel

A Extensible Markup Language (XML) e uma linguagem de marcacao de dados sem

nenhum elemento de apresentacao embutido, ou seja, apenas com elementos de definicao


48/71


de conteudo. O XML prove um formato para descrever dados estruturados que facilita

declaracoes mais precisas do conteudo e resultados mais significativos de busca atraves de

multiplas plataformas.

Segundo TITTEL (2002), a palavra extensvel reflete o fato de que a linguagem e

flexvel, escalonavel e adaptavel. Com esses tres fatores o desenvolvimento de aplicacoesem tres camadas (three-tier), que e o caso deste projeto, e altamente factvel com o XML.

Os dados podem ser distribudos entre as aplicacoes desktop para serem visualizados em

um navegador ou em servidores intermediarios para o processamento, permitindo que tais

dados possam ser facilmente combinados via software, com bancos de dados nas extremi-

dades da rede. Desta forma a troca de informacoes entre dispositivos moveis e servidores

remotos seria realizada de maneira mais comprimida e escalavel, alem de proporcionar

buscas mais eficientes. Esse ponto e de suma importancia, pois os dispositivos moveis

tipicamente possuem memoria limitada e baixo poder de processamento.

A estrutura de um documento XML e baseada em um modelo de arvore rotulada.Geralmente possui um no raiz especial acima do elemento raiz. Os nos internos sao

elementos rotulados com um nome e um conjunto de atributos (valor). Os nos folhas

contem:

Sequencias de caracteres

Anotacoes de processamento, normalmente no cabecalho do documento

Um comentario

Uma declaracao de entidade

Nos DTD (Document Type Declaration)

Podemos visualizar uma breve estrutura de um documento XML com sua respectiva

arvore na Figura 6.4.

6.2.1 Analise de documentos XML

A partir de um modelo no formato XML e necessario realizar a analise dos dados

embutidos atraves de uma tecnica denominada Parse. Segundo VELOSO (2007), Par-

sing e o processo de leitura e divisao do documento em elementos, atributos, entidades,comentarios e outros tipos de dados, por meio do qual poderao ser analisados e validados.

Existem algumas tecnicas para realizar o parse de um XML, como o pull parser, o

DOM e o push parser. No pull parser uma quantidade de dados e analisada de cada

vez, durante o parse sempre e solicitado a proxima parte que deve ser processada ate

chegar ao fim, geralmente isto e feito em um loop. Assim sao obtidas as informacoes do


49/71


Figura 6.4: Estrutura do XML.

XML a medida que o parser e efetuado. Uma outra tecnica e o DOM, que utiliza ummodelo baseado em arvore e cria uma estrutura de dados na memoria, onde e possvel

acessar essa estrutura atraves de um conjunto de objetos. E muito simples de se utilizar,

porem e necessario ler o documento inteiro para montar a estrutura de arvore, para depois

exibir as informacoes que foram lidas, alem disso, pode ter muitos objetos armazenados na

memoria entao nao e recomendado para ser usado em Java ME. E o modelo push parser

e orientado a eventos, portanto ao ler um XML um objeto listener e notificado sempre

que novas tags sao encontradas.


50/71


51/71

7.2. Arquitetura do sistema 42

iteracoes. Cada iteracao contem um conjunto de estorias e no final desta o cliente pode

validar as implementacoes efetuadas e dar seu feedback. O XP utiliza ainda o conceito de

programacao em par. Enquanto uma das pessoas esta escrevendo o codigo a outra pessoa,

chamada de navegador, esta permanentemente revisando. Todo codigo desenvolvido e

coletivo, portanto utiliza-se padronizacao para simplificar o desenvolvimento (TELES,2004).

O XP oferece agilidade no processo de desenvolvimento de software e um feedback

rapido do cliente, o que e necessario quando se trata de desenvolvimento para celulares e

smartphones, por ser um sistema enxuto. Portanto, para este estudo de caso foi adotado

as praticas da metodologia agil XP, onde foram definidos dois releases, cada um composto

por duas iteracoes. As iteracoes dos releases foram descritas no decorrer deste trabalho.

7.2 Arquitetura do sistema

Para o trabalho que segue, foi abordado juntamente da plataforma Java ME, o uso

de servlets, dentro da arquitetura Java EE, interagindo com um cliente via HTTP para

estabelecer a comunicacao com o dispositivo movel. Visto que um servlet pode efetuar

qualquer processamento inerente a uma classe Java e enviar respostas na forma de docu-

mentos XML, para efetuar a troca de dados entre o dispositivo m ovel e o servidor remoto

de dados, que alimentara o sistema movel, foi utilizado os recursos que a linguagem XML

oferece.

A Figura 7.1 mostra o esquema de comunicacao para o trabalho proposto. Definido

por uma arquitetura Cliente - Servidor e baseado nas tres seguintes camadas:

Figura 7.1: Esquema de comunicacao.


52/71

7.3. Visao geral do sistema 43

7.3 Visao geral do sistema

E proposto um sistema movel gerador de pedidos para uma empresa revendedora de

bebidas. O sistema sera responsavel por cadastrar e editar clientes, gerar os pedidosrealizados, informar os dados dos pedidos, clientes e produtos. O objetivo do sistema e

informatizar e agilizar o processo de pedidos realizados pelos revendedores da empresa

distribuidora de bebidas. Atualmente a tarefa e feita manualmente atraves de consultas a

catalogos e toda informacao coletada e registrada em listas e repassada para a central da

empresa, onde os dados eram digitalizados para serem armazenados no banco de dados

central da distribuidora.

A empresa possui um sistema Web, que e o responsavel por alimentar o sistema movel.

Com este sistema a gerencia otimiza o acesso aos dados de forma segura, alem de facilitar

o trabalho dos revendedores. O revendedor realiza o pedido via celular ou smartphone, e

este e armazenado no aparelho. Quando o dispositivo acessar uma rede sem fio e possvel

atualizar o banco de dados do dispositivo e enviar os pedidos para um sistema Web que

ira armazenar as informacoes no banco de dados central da distribuidora, controlando

todas as informacoes referente a forca de vendas.

7.4 Diagrama de

Documents

Caso de uso JME