Caso de Uso JME

Coordenação do Curso de Ciência da Computação
Universidade Estadual de Mato Grosso do Sul
Desenvolvendo um Estudo de Caso

Utilizando a Plataforma Java ME
Lais Claudia Zanfolim

Rodolfo Chaves Fernandes
André Chastel Lima (Orientador)

Celso G. Camilo Jr (Co-orientador)
Dezembro de 2009

Este exemplar corresponde à redação final

da monografia da disciplina Projeto Final de
Curso devidamente corrigida e defendida por
Rodolfo Chaves Fernandes e aprovada pela
Banca Examinadora, como parte dos requisi-
tos para a obtenção do tı́tulo de Bacharel em
Ciência da Computação.
Dourados, 11 de dezembro de 2009.
André Chastel Lima (Orientador)
Celso G. Camilo Jr (Co-orientador)
ii
Coordenação do Curso de Ciência da Computação
Universidade Estadual de Mato Grosso do Sul


Dezembro de 2009
Banca Examinadora:
• André Chastel Lima (Orientador)
• Celso G. Camilo Jr (Co-orientador)
• Raquel Marcia Müller
• Nielsen Cassiano Simões
iii
Resumo
A plataforma Java Micro Edition é o conjunto de tecnologias que permitem o de-

senvolvimento de aplicações Java para dispositivos com processamento, memória e vı́deo
limitados, como celulares e smartphones. Assim como as outras edições Java, essa pla-
taforma foi desenvolvida com o mesmo intuito, a portabilidade, além de possuir diversas
APIs para o desenvolvimento, o Java ME também fornece compatibilidade entre as edi-
ções Java, possibilitando a comunicação com aplicações construı́das em Java SE e Java
EE. Mantendo o foco em Java Micro Edition, este trabalho propõe o desenvolvimento de
uma aplicação móvel que una as tecnologias Java ME e Java EE. Como o Java Enterprise
Edition possui várias funcionalidades de redes e Internet e contém classes especialmente
desenvolvidas para acesso a servidores e banco de dados, parte da aplicação foi construı́da
usando esta tecnologia, possibilitando a comunicação entre dispositivos móveis 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 móvel através do protocolo HTTP para estabelecer a comunicação 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 móvel e o servidor remoto de dados, que alimenta o
sistema móvel, utilizamos os recursos que a linguagem XML nos oferece. Para auxiliar o
desenvolvimento do estudo de caso, a metodologia ágil extreme programming foi utilizada
juntamente com diagramas da UML com o intuito de organizar o processo de desenvolvi-
mento. A aplicação desenvolvida durante o trabalho é responsável por agilizar o processo
de vendas de uma distibuidora de bebidas, a fim de automatizar a força de vendas e foi
testada em celulares e smartphones com o sistema operacional móvel Symbian e Windows
Mobile, interagindo com o servidor via requisições HTTP.
Palavras Chave: Java ME, mobilidade, celulares e smartphones.
iv
Abstract
The platform Java Micro Edition is the set of technologies that enable the develop-
ment of Java applications for devices with limited processing, memory and video, such
as cell phones and smartphones. As with other Java editions, this platform was develo-
ped with the same intention, portability, and have different APIs for the development,
Java ME also provides compatibility between Java editions, enabling communication with
applications built on Java SE and Java EE. Keeping the focus on Java Micro Edition,
this paper proposes the development of a mobile application that gather the technologies
Java ME and Java EE. As the Java Enterprise Edition has several networks and Internet
features and contains classes designed specially to access servers and databases, part of
the application was built using this technology, enabling communication between mobile
devices and server requirements of a local network or Internet. Therefore, in this study
was discussed, along with the Java ME platform, the use of Servlets in the Java EE archi-
tecture, interacting with a mobile client via the HTTP protocol to communicate with cell
phones and smartphones. Since a servlet can perform any processing associated with a
Java class and submit answers in the form of XML documents, to effectuate the exchange
of data between a mobile device and the remote database, which feeds the mobile system,
we use the resources that XML language offers. To assist the development of case study,
the agile eXtreme Programming was used together with UML diagrams in order to orga-
nize the development process. The application developed during the work is responsible
for streamlining the sales process of a beverage distributor, to automate the sales force
and has been tested on mobile phones and smartphones with mobile operating system
Symbian and Windows Mobile, interacting with the server via HTTP requests.
Keywords: Java ME, mobile, cell phones and smartphones.
v
Agradecimentos
Agradecemos primeiramente a Deus, por ter nos abençoado durante toda nossa vida
e principalmente por ter nos dado forças durante todo o decorrer do trabalho.
Aos nossos familiares, pela confiança, apoio e educação durante toda nossa caminhada.
Ao nosso orientador André Chastel Lima, pelo apoio e compreensão.
Ao nosso co-orientador Celso Camilo, pelo incentivo e paciência.
A toda academia, que nos proporcionou as condições necessárias para o desenvolvi-
mento deste trabalho, em especial os professores Odival Faccenda e Glaucia Gabriel Sass.
Aos funcionários 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 contribuı́ram para o sucesso desta caminhada
e que de forma injusta não tiveram seus nomes incluı́dos aqui.
vi
Sumário
Resumo iv
Abstract v
Agradecimentos vi
1 Introdução 3
1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Sistemas operacionais para dispositivos móveis 6

2.1 Dispositivos Móveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Análise do Mercado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3 Java Micro Edition 11

3.1 Visão geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Configurações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Perfis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Máquinas Virtuais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5 Pacotes Opcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
vii
4 Perfil MIDP 17
4.1 Visão Geral do MIDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 MIDlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3 MIDlets Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3.1 JAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3.2 JAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.5 Armazenamento Persistente . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.5.1 RMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5 APIs e Frameworks para Java ME 28

5.1 APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2.1 Floggy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.2 KXML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2.3 LWUIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6 Comunicação com o Servidor 35

6.1 A Plataforma Java EE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.1.1 Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.2 XML - Linguaguem de marcação extensı́vel . . . . . . . . . . . . . . . . . . 38
6.2.1 Análise de documentos XML . . . . . . . . . . . . . . . . . . . . . . 39
7 Estudo de Caso 41
7.1 Extreme programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.2 Arquitetura do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.3 Visão geral do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.4 Diagrama de Caso de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.5 Estórias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.6 Release 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.6.1 Iteração A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.6.2 Iteração B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.7 Release 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.7.1 Iteração A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.7.2 Iteração B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.8 A Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
8 Considerações Finais 57
viii
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 comunicação. . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

7.2 Diagrama de Caso de Uso. . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.3 Estória 1-A: Consulta de produtos. . . . . . . . . . . . . . . . . . . . . . . 44
7.4 Estória 1-B: Consulta e cadastro de clientes. . . . . . . . . . . . . . . . . . 44
7.5 Estória 2-A: Cadastro de pedidos. . . . . . . . . . . . . . . . . . . . . . . . 45
7.6 Estória 2-B: Alteração de pedidos. . . . . . . . . . . . . . . . . . . . . . . . 45
7.7 Estória 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 Autenticação do usuário. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.12 Menu principal da aplicação móvel. . . . . . . . . . . . . . . . . . . . . . . 51
7.13 Cadastro de Clientes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.14 Busca de Produtos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
7.15 Detalhamento de produto. . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
7.16 Cadastro de pedidos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.17 Lista de pedidos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
ix
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 Archive
Java 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 API
MMS - Multimedia Messaging Service (Serviço de Mensagem Multimı́dia)
MSA - Mobile Service Architecture
OpenCL - Open Computing Language
OpenGL - Open Graphics Library
1
2
PBP - Personal Basis Profile

PC - Personal Computer
PDA - Personal Digital Assistants
PDAP - PDA Profile
PP - Personal Profile
RAD - 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 Operacional
UML - Unified Modeling Language
VM - Virtual Machine
W3C - World Wide Web Consortium
WAV - WAVEform audio format
WTK - Wireless ToolKit
XML - eXtensible Markup Language
Capı́tulo 1
Introdução
Com a expansão da Internet e da utilização de aplicações, surgiram diversas linguagens

de programação, tendo destaque as de multiplataforma, como é o caso do Java, que pode
ser aplicado em diversos setores, como aparelhos eletrônicos, telefones celulares, aplicações
para Web e desktop, entre outros. Levando em consideração os diferentes setores, tornou-
se necessário a criação de kits de desenvolvimento diferenciados.
A proposta inicial parte do interesse pela linguagem de programação Java, em espe-
cı́fico Java Micro Edition - Java ME. É uma plataforma que permite o desenvolvimento
de aplicações Java para dispositivos com processamento, memória e vı́deo limitados, tais
como celulares e smartphones. Assim como as outras edições Java, essa tecnologia foi
desenvolvida com o mesmo intuito, a portabilidade, além de possuir diversas APIs (Ap-
plication Programming Interface) para o desenvolvimento. O Java ME também fornece
compatibilidade entre as edições Java, possibilitando a comunicação com aplicações Java
SE (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 aplicações embarcadas.
Dentro desta última configuração existe uma outra classificação que define os perfis dos
dispositivos. No caso de celulares e smartphones a classificação usada é o MIDP, Mobile
Information Device Profile. Dentro desta classificação, se ocorrer a migração de aplicações
para outros celulares com a mesma configuração elas não perdem sua funcionalidade
(TOPLEY, 2002).
Para otimizar o funcionamento de aplicações em celulares a Sun desenvolveu máquinas
virtuais Java especı́ficas para cada configuração, que manipulam de maneira mais eficiente
3
1.1. Objetivos 4
a codificação desse tipo de dispositivos.

Com a criação deste ambiente de desenvolvimento torna-se viável a construção de
aplicações para dispositivos móveis 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 construção
de um servidor que será responsável pela troca de dados com a aplicação móvel.
Para alcançar o objetivo principal, as seguintes etapas foram efetuadas:
• Fazer um breve estudo sobre as plataformas de dispositivos móveis;
• Estudar a plataforma Java ME, voltada para dispositivos móveis;
• Estudar a plataforma Java EE para a construção de um servidor remoto;
• Estudar a comunicação entre o servidor e a aplicação móvel;
• Estudar alguns frameworks Java ME e definir quais serão utilizados no estudo de

caso;
• Definir os padrões da Engenharia de Software que serão utilizados na aplicação;
• Definir o estudo de caso;
• Desenvolver e testar o estudo de caso.
1.2 Justificativa
Segundo dados divulgados pela Agência Nacional de Telecomunicações (Anatel), o
número de linhas de telefones móveis no paı́s chegou a aproximadamente 152,4 milhões,
em fevereiro de 2009, o que corresponde a 79,94% da população (AGÊNCIAESTADO,
2009).
Em nı́vel mundial, o número de usuários de telefones móveis chegou perto de 3 bilhões
em 2007, atingindo 48% da população e a estimativa para o final de 2008 era de 4 bilhões,
o que corresponde a 61%, segundo a União Internacional de Telecomunicações (UIT)
(REUTERS, 2008).
Segundo Eric Klein, vice-presidente de marketing do Java, em entrevista à Reuters, o
Java está instalado em 2,6 bilhões de telefones em todo o mundo (VIRKI, 2009). Visto
1.3. Metodologia 5
que o número de usuários de aparelhos celulares é significativo, que está em crescimento e

que a plataforma Java ME é bem aceita pelo mercado de software para dispositivos móveis
e também está em ascendência no mercado, o desenvolvimento para esta plataforma se
torna bastante atraente.
1.3 Metodologia
Mantendo o foco em Java Micro Edition, propomos fazer uma revisão bibliográfica dos
conceitos chaves desta plataforma e desenvolver uma aplicação para celular ou smartphone
que una as plataformas Java ME e Java EE. Como o Java Enterprise Edition possui várias
funcionalidades de redes e Internet e contém bibliotecas especialmente desenvolvidas para
acesso a servidores e banco de dados, parte da aplicação será construı́da usando esta
plataforma, possibilitando a comunicação entre dispositivos móveis e um servidor disposto
na rede ou Internet.
A plataforma Java EE contém uma série de especificações, cada uma com funciona-
lidades distintas, entre elas, utilizamos servlets, utilizados para o desenvolvimento Web
com conteúdo dinâmico e contém uma API que simplifica os recursos do servidor Web
para o programador (HALL, 1998).
Foi realizado um levantamento de diferentes frameworks Java ME e os que se apresen-
taram mais viáveis para o desenvolvimento da aplicação foram utilizados.
Os dados foram padronizados em documentos XML (Extensible Markup Language),
padronizada pela W3C (World Wide Web Consortium), a fim de serem transferidos do
servidor para a aplicação móvel.
O estudo de caso foi desenvolvido com base na metodologia ágil extreme programming
- (XP), e diagramas da UML serão apresentados para o melhor entendimento da aplicação.
Os testes foram realizados em celulares e smartphones com o sistema operacional
Symbian e Windows Mobile com a configuração CLDC 1.1 e perfil MIDP 2.1, porém a
aplicação poderá ser executada em outros sistemas operacionais móveis que possuam uma
máquina virtual Java compatı́vel com estas caracterı́sticas.
Capı́tulo 2
Sistemas operacionais para

dispositivos móveis
A tecnologia da informação atinge a maior parte das empresas e instituições de forma

que fiquem dependentes de sistemas que ajudam ou otimizam o trabalho e a comunicação
dentro das mesmas. Com a massificação de computadores e Internet surge um outro
conceito: Mobilidade. O poder de carregar as informações para qualquer ambiente é
evidentemente útil para empresas que trabalham com base de dados e um fator essencial
para se destacar no mercado é ter acesso as informações em tempo real.
Sendo evidente o impacto que soluções de softwares móveis têm e terão nos próximos
anos, é de extrema importância conhecer os sistemas operacionais móveis do mercado
e quais tipos de aplicações cada um deles suporta. Assim, é apresentada uma breve
análise dos principais sistemas operacionais para dispositivos móveis mais importantes da
atualidade.
Neste capı́tulo também são explanados os principais tipos de dispositivos móveis e suas
tecnologias, visando uma abordagem completa dos requisitos necessários para construir
aplicativos de sucesso.
2.1 Dispositivos Móveis

Primeiramente é importante esclarecer que o termo Palm é utilizado para PDAs (As-
sistente Pessoal Digital) ou Handhelds, que são computadores de mão que fornecem as
funções básicas de um computador pessoal, como acesso a Internet, programas de cadas-
tros, agenda, controle financeiro, controle de vendas, planilhas, documentos entre outras
aplicações da categoria (PALMBRASIL, 2009a).
O smartphone é uma categoria de telefone celular com caracterı́sticas que antes eram
encontradas somente em Palms e PCs (Personal Computers). PoketPC é o nome que
6
2.2. Sistemas Operacionais e suas tecnologias 7
a Microsoft usa para a categoria de PDAs, que difere dos smartphones por agregar ca-
racterı́sticas como uma tela maior e sensı́vel a toque, suporte wi-fi, bluetooh, integração
com GPS (Global Positioning System), enfim, tecnologias que o tornam mais robusto
(MICROSOFT, 2009b).
2.2 Sistemas Operacionais e suas tecnologias

Nesta seção abordaremos as principais caracterı́sticas dos sistemas operacionais móveis
mais utilizados no mercado, bem como suas tecnologias.
2.2.1 Symbian
Começaremos então com o sistema operacional para telefones móveis que desde 1998
lidera o mercado mundial, o Symbian OS, ou simplesmente Symbian. Ele possui suporte
MMS (Multimedia Messaging Service), bluetooh, wireless, infra-vermelho, entre outras
funções que tornam-se extremamente importantes quando o assunto é mobilidade. Este
SO possui um sistema gráfico bem simples e atualmente é o sistema mais usado pelos
maiores fabricantes de telefones móveis do mundo, porém com o surgimento de novas
tecnologias e plataformas, vem apresentando queda. Por ser um sistema operacional
que controla muito bem o consumo de memória, o consumo de energia, o processamento,
entre outros fatores essenciais, as empresas mais poderosas da telecomunicação investiram
bastante para que este fosse um sistema promissor para o mercado.
Empresas como Nokia, Samsung, Panasonic, Ericsson e Sony Ericsson, foram as res-
ponsáveis pela ascendência desse modelo de sistema operacional móvel. Segundo a INFO
(2008), atualmente a Nokia possui a totalidade das ações da empresa britânica de software
(Symbian), liderando o mercado mundial com 38,9% de participação e promete concorrer
com o mais novo sistema operacional para dispositivos móveis - Android.
O Symbian suporta sistemas divididos em módulos, desta forma cada empresa pode
criar sua própria interface. Permite o uso de várias linguagens de programação, entre
as mais importantes estão: Symbian C/C++, Java ME, FlashLite, Perl, Python, Ruby,
entre outras. Assim se o aparelho não possui certa funcionalidade, fica fácil 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 consórcio com mais de 40 empresas. Utiliza uma máquina virtual
que foi projetada para otimizar a memória e os recursos de hardware em um ambiente
móvel. É a primeira plataforma open source para desenvolvimento de aplicações móveis,

portanto é livre para incorporar novas tecnologias. Por ser um SO mais novo no mercado
está em aceitação, positiva por sinal, pelos usuários e desenvolvedores, pois agrega todas
as funcionalidades que os aparelhos móveis mais atuais fornecem. É importante ressaltar
que os serviços da Google passam a ser facilmente acoplados com as tecnologias móveis
após o surgimento do Android, já que o interesse e os investimentos atuais da empresa
visam a mobilidade.
Entre os serviços oferecidos estão: Cliente de e-mail, programa para SMS (Short Mes-
sage Service), calendário, mapas, navegador e gerenciador de contatos. Tudo construı́do
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.
Além dos aplicativos feitos em Java, o Android possui um conjunto de bibliotecas
C/C++ usadas por diversos componentes que permitem trabalhar com arquivos de mı́dia,
exibição de conteúdo 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 móveis, projetado para
realizar boa parte das funções existentes no Windows para PC. Ele pode ser instalado
em PDAs, PocketPC, smartphones e aparelhos de multimı́dia 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, além de versões móveis
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, além 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 versões 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 rápidos e com recursos extras. No Palm OS Garnet (5.x) apenas algumas
partes dos aplicativos são em 32 bits, já que maior parte simula processadores antigos da
Motorola. A desvantagem é que as aplicações criadas utilizando os novos recursos não

irão funcionar em equipamentos com versões anteriores do sistema.
As linguagens mais utilizadas para o desenvolvimento de aplicações no Palm OS é
o Pascal e o C/C++. Vale ressaltar que a última possui uma grande quantidade de
frameworks e é mais usada no desenvolvimento de jogos. Importante dizer que existem
aplicativos que convertem aplicações em Java para que possam ser utilizadas em Palm
OS, uma ótima saı́da para escapar do padrão de desenvolvimento em palms. Existem
ainda outras linguagens para Palm OS, mas que não 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 aplicações com maior facilidade para o Palm OS. Atualmente
essas são as mais usadas no desenvolvimento de aplicações comerciais para palms.
Após a PalmSource ser comprada pela Access as próximas versões devem ser baseadas
no sistema operacional Linux. Atualmente os dispositivos palms estão sendo comerciali-
zados também com Windows Mobile justamente pelas restrições 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 sua
consagrada ferramenta de sincronização de e-mails. Assim que o servidor recebe o e-mail
este é enviado para o dispositivo. Inicialmente deixava a desejar no quesito design, porém
passa por constantes aprimoramentos neste quesito e em outros recursos. Suas versões
mais atuais apresentam recursos como menus recolhı́veis, navegação por fotos, gerenciador
de arquivos dedicado e oferece suporte para aplicativos desenvolvidos em Java ME (RIM,
2009).
É o terceiro sistema operacional para dispositivos móveis mais vendido do mundo e o
segundo dos Estados Unidos. Teve um crescimento muito rápido, 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 proprietário 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
2.3. Análise do Mercado 10
linha com uso de 64 bits, proporcionando a mais rápida implementação de javascript e

acesso a Web, chegando a ser 53 vezes mais rápido quando usa o mini navegador Safari.
Outra poderosa tecnologia implementada é o OpenCL(Open Computing Language) que
possibilita aos desenvolvedores maior otimização em aplicações que usam recursos gráfi-
cos. Possui uma tecnologia de multicondutores que agiliza a distribuição de tarefas em
multiplos processadores (APPLE, 2009a).
Em comparação ao Android por exemplo, é notável que o sistema operacional do
Iphone é muito superior em qualidade e eficiência, ainda mais se compararmos o acesso a
Web, pois o Iphone já conquista e domina o mercado e não deixa a desejar em nenhum
aspecto, com exceção 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 acréscimo de transmissão de mensagens, ao estilo da linguagem Smalltalk.
Também existem iniciativas Open Source para converter códigos em Python para C ou
também de Java para Objective-C.
Para desenvolver aplicativos para o Iphone OS é necessário utilizar o Cocoa, um con-
junto de frameworks orientado a objetos que disponibiliza um ambiente de execução para
as aplicações serem executadas em MAC OSX e Iphone OS. É o único ambiente de apli-
cação para Iphone OS. As aplicações existentes no MAC OSX e no Iphone OS são Cocoa,
portanto para desenvolver aplicações Java para o sistema operacional do Iphone é neces-
sário usar ferramentas que convertem o código Java para a implementação da biblioteca
Cocoa. Também existem frameworks para converter Python, Ruby, Perl, C# e Objective-
Basic em Objective-C, utilizando o Cocoa (APPLE, 2009b).
2.3 Análise do Mercado
As plataformas da Apple, Google e Palm são, 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 doméstico, ficando fraca diante do
iPhone, Symbian e Android.
Apenas três plataformas devem sobreviver, mas é difı́cil dizer hoje exatamente quais
são. ”É uma batalha de ecossistemas que dependem de fatores como recursos do equi-
pamento, estilo, preço e oferta de aplicativos e não só da plataforma em si.” (JONES,
2009).
Capı́tulo 3
Java Micro Edition
Neste capı́tulo são apresentadas as caracterı́sticas da plataforma Java Micro Edition

(Java ME), bem como suas tecnologias e arquitetura.
3.1 Visão geral

Segundo a SUN (2009b), o Java ME é uma coleção de tecnologias e especificações que criam
uma plataforma que se ajusta aos requisitos de dispositivos móveis tais como produtos de
consumo, dispositivos embarcados e dispositivos móveis avançados.
O Java ME é a plataforma Java voltada para dispositivos que possuam capacidade de
memória, tela e processamento restritos. Foi construı́da com o objetivo de fornecer um
ambiente de execução Java capaz de lidar com as caracterı́sticas particulares de pequenos
dispositivos.
Para utilizar a mesma plataforma em dispositivos diferentes o Java ME foi baseado
em três elementos, especificados pela comunidade JCP, que define todos requisitos da
plataforma Java, incluindo a especificação de APIs. Os três elementos citados são: Con-
figurações, perfis e pacotes opcionais, os quais funcionam sobre uma máquina 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
3.1. Visão geral 12
Figura 3.1: Elementos da plataforma Java ME.
Na camada de configuração são definidas as bibliotecas necessárias para o funciona-

mento da máquina virtual. A JCP especificou o Java ME em duas configurações 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 memória e processamento,

como TV digital, dispositivos sem fio de alto nı́vel e sistemas automotivos.
Dentro da configuração existe uma outra classificação, os perfis. Estes formam um

conjunto de aplicações que complementa uma configuração 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 são: 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 estão inseridos em um conjunto de APIs utilizadas com
as configurações e perfis para estender funcionalidades não encontradas nos respectivos
pacotes, como APIs para bluetooh e wireless.
Quanto a máquina virtual, a JCP especifica a CDC HotSpot Implementaion e a CLDC
HotSpot Implementation, que substituı́ram respectivamente a CVM (Compact Virtual
Machine), vinculada a configuração CDC e a KVM (Kilo Virtual Machine), vinculada a
CLDC. A Figura 3.2 mostra a arquitetura da plataforma Java.
3.2. Configurações 13
Figura 3.2: Arquitetura da plataforma Java.
3.2 Configurações
A configuração define uma especificação padrão para uma mesma classe de dispositivos,
definidos por caracterı́sticas individuais de hardware, como interface, processamento, me-
mória, vı́deo, tipo de conexão de rede, entre outras (TOPLEY, 2002). Esta camada possui
as bibliotecas básicas da linguagem, representando a plataforma mı́nima de desenvolvi-
mento para cada tipo de dispositivo. Tais configurações são definidas pelos fabricantes a
fim de proporcionar um ambiente de desenvolvimento para funcionar em um determinado
dispositivo.
Cada configuração consiste de uma máquina virtual Java (Java Virtual Machine -
JVM), seja da Sun, do próprio fabricante, ou de terceiros e de uma coleção de classes
Java. Devido as restrições de hardware dos dispositivos móveis, as máquinas virtuais
utilizadas na plataforma Java ME não suportam todas as caracterı́sticas da linguagem
Java, instruções bytecodes e softwares de otimização providenciados pela plataforma Java
SE não são suportados, sendo assim diferentes das demais JVMs (TOPLEY, 2002).
A JCP especificou duas configurações para Java ME, CLDC e CDC. Dentre elas abor-
daremos a configuração CLDC, visto que esta aborda celulares e smartphones, cujo é o
objetivo deste trabalho.
A Connected, Limited Device Configuration - CLDC é a configuração mı́nima do Java
ME, formada por um subconjunto de pacotes disponı́veis na plataforma Java para desktop
3.2. Configurações 14
e abrange os dispositivos com grandes restrições de processamento, memória e vı́deo, como

celulares, smartphones, pagers e PDAs.
Os dispositivos desta configuração têm pelo menos 16 ou 32 bits, 160k de memória
não volátil (onde são armazenadas as bibliotecas e a máquina virtual), fonte limitada de
energia e pelo menos 16 Mhz de velocidade. Além disso é necessário 192k de memória
para a plataforma Java e suportar conexão com rede sem fio, porém com capacidade de
transmissão limitada (JOHNSON, 2007).
A CLDC está disponı́vel nas versões 1.0 (JSR 30) e 1.1 (JSR 139) (SUN, 2006e). A
principal caracterı́stica da versão 1.0 é a ausência de operações que use ponto flutuante,
porém já existem classes que simulam esta propriedade para dada configuração (CLAU-
SEN, 2003).
Segundo a SUN (2007), as classes desta configuração estão restritas a apenas quatro
pacotes:
• java.io - Tratamento de entrada e saı́da de dados usando streams (abstração).
• java.lang - Classes básicas da linguagem Java.
• java.util - Classes de utilidades genéricas (estruturas de dados e manipulação de

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

de conexão.
A CLDC 1.1 é uma configuração que engloba os pacotes da versão 1.0 e suporta as
seguintes caracterı́sticas:
• Ponto flutuante - Possibilita operações com variáveis do tipo float/double.
• ClassLoading - Classe abstrata responsável por carregar outras classes.
• Garbage Collector - Coletor de lixo dos objetos.
• Finalize() - Com esse método é possı́vel liberar recursos e executar outras operações
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 máquina
virtual acessar bibliotecas acessadas com o código nativo de um sistema.
• ThreadGroups - Possibilita que os processos sejam executados simultaneamente,

possibilitando a organização das threads em grupos. A multiThreading suporta
múltiplas linhas de execução através das funções start(), interrupt(), pause(), re-
sume() e stop() para o controle das threads.
3.3. Perfis 15
• RMI (Remote Method Invocation) - Permite o acesso a objetos remotos que podem
ser invocados de diferentes máquinas Java.
3.3 Perfis
Perfil é definido como um conjunto de APIs que especificam o nı́vel de interface de
aplicações para um classe de dispositivos (JCP, 2009c). Assim um perfil pode especificar
vários tipos de serviços e funcionalidades de alto nı́vel, como o ciclo de vida da aplicação,
elementos de interface gráfica, persistência de dados e meios de comunicação. Um perfil é
implementado no topo de uma configuração, sendo assim intimamente ligado a esta, po-
rém compreende bibliotecas mais especı́ficas que as disponibilizadas pelas configurações,
ou seja, o perfil complementa a configuração adicionando classes que fornecem caracte-
rı́sticas apropriadas para um tipo particular de dispositivos. Tanto os perfis quanto as
configurações são especificações de baixo nı́vel.
As aplicações móveis são portanto construı́das sobre configurações e perfis e podem
apenas usar bibliotecas especificadas por estas. Uma configuração pode conter vários
perfis, porém um perfil é ligado somente a uma configuração. E um perfil ainda pode ter
outros perfis ligados a ele (TOPLEY, 2002).
Para a configuração 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 conexão sem fio, como os celulares,
smartphones e alguns PDAs. No próximo capı́tulo serão abordados mais detalhes sobre o
perfil MIDP.
3.4 Máquinas Virtuais

A Sun especifica duas máquinas virtuais para a configuração CLDC: KVM e CLDC
HotSpot Implementation.
• KVM
É uma máquina virtual com funções reduzidas, com uma pequena memória e com
um coletor de lixo (garbage collector ) incorporado para a otimização da memória
(TOPLEY, 2002). Esta é uma VM (Virtual Machine) especificada pela SUN, que
implementa as necessidades e restrições impostas pela configuração CLDC. O K do
termo KVM surgiu para fazer alusão aos poucos kilobytes necessários para que a
VM execute uma aplicação. Ela não compila o código e sim o interpreta para o
sistema operacional.
3.5. Pacotes Opcionais 16
• CLDC HotSpot Implementation

É uma VM de alto desempenho e robustez da SUN, para celulares e dispositivos
de caracterı́sticas restritas. Foi implementada para ter um desempenho melhor
que a KVM, utilizando a mesma quantidade de memória restrita que os pequenos
dispositivos oferecem. Esta máquina virtual suporta CLDC 1.0 e 1.1, porém agora
exige do processador pelo menos 32 bits com uma velocidade de clock de 60 MHz,
600KB de memória RAM e 2 MB de memória flash e ROM. Aplica tecnologias
utilizadas na plataforma Java SE e Java EE, incorpora diversos designs inovadores,
diminui o tempo de inı́cio das aplicações, oferece vida longa a bateria e possui
compilação dinâmica das instruções de bytecode em instruções nativas, chamada de
compilação Just-in-time (SUN, 2008a).
Segundo LUZ (2009), a compilação Just-in-time é uma das mudanças mais impor-
tantes, pois a compilação dinâmica pode ser cinquenta vezes mais rápida que uma
instrução interpretada.
3.5 Pacotes Opcionais

Pacotes opcionais são componentes muito importantes da plataforma Java ME. Po-
demos enxergar como extensões de perfis, além de oferecerem apoio em áreas com fun-
cionalidades restritas que alguns dispositivos e aplicações precisam, tais como troca de
mensagens, multimı́dia, serviços e localização geográfica.
Os perfis podem concentrar-se em apoiar apenas as capacidades que a maioria ou
todos os dispositivos em uma classe necessitam, enquanto pacotes opcionais fornecem
tipos especı́ficos de funcionalidades. Todos os pacotes opcionais do Java ME são definidos
pela JCP, estes pacotes também são chamados de APIs. Podendo ser obrigatórios ou
não, tal decisão cabe aos desenvolvedores ou fabricantes incluı́-los em um determinado
produto.
Os pacotes opcionais passam por um processo de aprovação através da MSA (Mobile
Service Architecture) após serem construı́dos pelos desenvolvedores. Depois de aprovados
são disponibilizados seguindo as especificações da JCP. Alguns exemplos de pacotes opcio-
nais são: API para suporte bluetooth (JSR 82), API para acesso as funcionalidades nativas
do aparelho como agenda, calendário e acesso a arquivos (JSR 75 - File Connection API ),
API de segurança e serviços confiáveis (JSR 177), entre outras (SUN, 2009a).
Capı́tulo 4
Perfil MIDP
Neste capı́tulo são apresentadas as caracterı́sticas do perfil MIDP, bem como o fun-
cionamento de uma aplicação. Serão apresentados os principais conceitos relacionados à
interface e armazenamento persistente.
4.1 Visão Geral do MIDP

O MIDP - Mobile Information Device Profile é um perfil suportado pela configuração
CDLC, onde juntos providenciam um ambiente padrão de execução Java para os mais
populares dispositivos móveis, como os celulares e PDAs. Este perfil provê um conjunto de
bibliotecas e classes que fornecem suporte ao desenvolvimento de aplicações que referem-
se a diferentes aspectos, como sistema de armazenamento persistente, interface com o
usuário, transações seguras, gerência de sons, entre outros.
De acordo com JOHNSON (2007), o MIDP apresenta diversas funcionalidades, entre
elas estão a reprodução de multimı́dia, suporte a protocolos dos tipos HTTP e sockets,
suporte ao sistema de cores RGB, definição de formulários e itens, APIs para jogos e
validação de permissões de segurança e assinaturas digitais.
Segundo a SUN (2006e), os recursos mı́nimos de hardware do perfil MIDP são:
• 130KB de memória não volátil para persistência de dados e bibliotecas da CLDC
• 32KB de memória volátil para a execução do Java
• Conectividade com algum tipo de rede sem fio
• Interface gráfica
• Uma tela de pelo menos 96 pixels de largura por 54 de altura
17
4.1. Visão Geral do MIDP 18
Alguns recursos mı́nimos de software também são requeridos, tais como: possuir re-
cursos suficientes para executar a máquina virtual Java, tratamento de exceções, pro-
cessamento de interrupções, acesso de leitura e escrita à rede sem fio, mecanismos para
capturar a entrada de dispositivos de entrada, recursos para ler e gravar em memória não
volátil, oferecendo suporte persistente aos dados e escrita de elementos gráficos na tela
(JOHNSON, 2007).
As especificações deste perfil são definidas pela JCP, definindo uma plataforma para
desenvolvimento seguro e dinâmico. Atualmente o MIDP possui as versões 1.0 (JSR
37), 2.0 (JSR 118), 2.1 (JSR 118) e 3.0 (JSR 271). Porém esta última ainda não está
disponı́vel para utilização. A versão 1.0 trabalha integrada com a configuração CLDC
1.0 ou 1.1. Não tem nenhuma API ativa para renderização, não oferece suporte para
acesso direto aos pixels de imagens, não tem suporte para full screen/full canvas sem
uma API proprietária e também não possui suporte direto para áudio. Inclui APIs para
o ciclo de vida de aplicações, conectividade de redes HTTP, interface com o usuário e
armazenamento persistente. O único protocolo de rede que o MIDP 1.0 suporta é o
HTTP (SUN, 2002).
Segundo a SUN (2006c), os pacotes suportados pela versão 1.0 são:
• javax.microedition.io - Fornece suporte ao framework GenericConnection da confi-
guração CLDC.
• javax.microedition.lcdui - API que providencia um conjunto de caracterı́sticas para

a implementação de interfaces com o usuário.
• javax.microedition.rms - Providencia um mecanismo de persistência de dados para

MIDlets.
• javax.microedition.midlet - O pacote MIDlet define aplicações MIDP e interações

entre as aplicações e o ambiente no qual a aplicação é executada.
A versão 2.0 é compatı́vel com a versão 1.0 e adiciona novas melhorias como suporte
à conexão segura (HTTPS), biblioteca de multimı́dia, formulário de entrada de dados
aprimorada, sensı́vel melhoria na API de suporte a games, conceito de aplicações confiáveis
(trusted ) e não confiáveis (untrusted ). Além de HTTPS, o MIDP 2.0 suporta HTTP,
datagramas, sockets e SMS (Short Message Service). Quanto a multimı́dia, um conjunto
de APIs foram introduzidas, que são na verdade um subconjunto da Mobile Media API
(MMAPI). Com estas APIs podem ser gerados simples toques, sequências mais completas
ou até mesmo músicas completas no formato WAV, além de poderem ser implementados
em outros formatos.
Dentre as mudanças nos formulários de entrada destacam-se a nova aparência do Form
que é consideravelmente mais sofisticada do que era no MIDP 1.0 e a classe Item, onde
4.1. Visão Geral do MIDP 19
agora podem ser especificados layouts horizontais, verticais, novas linhas antes ou depois
de itens, entre outros. Um novo item também foi criado, o Spacer, que serve pra colocar
espaçamentos entre os demais itens disponı́veis. Também foi introduzido o tipo pop up ao
item choiceGroup, que será estudado à frente.
No MIDP 2.0 também foram estendidos os comandos de manuseio. Adicionar co-
mandos aos itens agora é permitido. Também foi introduzida a classe CustomItem, que
permite ao programador criar seus próprios itens. Nesta versão 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 mudança é o surgimento da classe GameCanvas, uma subclasse de
Canvas - classe de baixo nı́vel que proporciona o desenvolvimento de jogos. Nesta versão
as imagens podem ser representadas em arrays de inteiros e também suporta imagens em
RGB (SUN, 2002).
Segundo a SUN (2006d), os pacotes que foram adicionados a esta versão são:
• javax.microedition.lcdui.game - Providencia classes para o desenvolvimento de con-

teúdo rico para jogos em dispositivos wireless.
• javax.microedition.media - Compatı́vel com as especificações da API Mobile Media

(JSR 135).
• javax.microedition.media.control - Define o tipo especı́fico, control, que pode ser

usado como um player.
• javax.microedition.pki - Autentica informações para conexões seguras, através de

certificados.
A versão 2.1 do MIDP reforça a especificação MIDP 2.0 tornando a diretiva layout LC-
DUI obrigatória, os pacotes javax.microedition.io.SocketConnection e javax.microedition-
.io.HTTPConnection não são mais opcionais, entre outros requisitos para aprimorar a
versão 2.0.
A versão 3.0 traz melhor suporte para dispositivos com telas maiores, suporte a MI-
Dlets para desenhar em telas secundárias, armazenamento RMS seguro e acesso remoto a
bancos RMS (JCP, 2009a). Esta versão requer no mı́nimo 1MB de memória volátil e tela
de pelo menos 176x220 pixels. Ela é compatı́vel com o CLDC 1.0, mas o recomendado é
o 1.1 e possui compatibilidade com as outras versões 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 através de um atributo no
arquivo JAD, um arquivo de descrição da aplicação, que será explicado posteriormente.
Os protetores de tela agora são aplicações que são destruı́das pelo gerenciador quando
4.2. MIDlets 20
alguma tecla é pressionada ou algum evento é disparado. Além destas funcionalidades,

o MIDP 3.0 apresenta suporte a IP versão 6, o que possibilita fazer parse de um ende-
reço IPv6 e a possibilidade de compartilhar bibliotecas entre os MIDlets em tempo de
execução, conhecido como LIBlets (LUZ, 2009).
4.2 MIDlets
É uma aplicação Java destinada para dispositivos móveis desenvolvida com a utilização
do perfil MIDP, que está vinculado a configuração CLDC (MUCHOW, 2001).
Todo dispositivo móvel tem um gerenciador de aplicativos (AM - Application Mana-
ger ) que controla os aplicativos a serem instalados, onde e como serão armazenados e
como serão executados. A comunicação do gerenciador com o MIDlet acontece pela classe
MIDlet do pacote javax.microedition.midlet.MIDlet. Os MIDlets devem herdar esta classe
MIDlet que contém métodos que inicializam, resumem, interrompem a execução e des-
troem MIDlets.
Uma aplicação é iniciada quando o AM invoca o método startApp(), colocando a
aplicação no modo ativo. Enquanto estiver executando ela pode ser pausada pela AM
através do método pauseApp(), isto pode ocorrer quando uma chamada for recebida por
exemplo ou o próprio usuário pode pausar a aplicação. E quando a aplicação é encerrada
ela passa para o estado destruı́do, através do método destroyApp(), que limpa todos os
recursos para fechar a aplicação (JOHNSON, 2007).
O ciclo de vida do MIDlet é apresentado na Figura 4.1.
Figura 4.1: Ciclo de vida do MIDlet.
Estes três métodos, segundo MUCHOW (2001), trata-se da comunicação que parte
do gerenciador de aplicativos para o MIDlet. Além destes métodos, também existem
outros três onde a comunicação parte do MIDlet para o gerenciador de aplicativos. Estes
métodos são:
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 são juntados em um Java Ar-
chive (JAR). É composto por classes Java, recursos e um arquivo de manifesto, que estão
situados dentro do arquivo JAR e um arquivo de descrição, chamado Java Application
Descriptor (JAD). Dentre os recursos estão imagens, dados da aplicação, entre outros.
No arquivo de manifesto, cuja extensão é .mf, está a descrição do JAR. E o arquivo JAD
descreve os detalhes da aplicação, repetindo muitos do dados que estão no arquivo de
manifesto, porém este arquivo está fora do JAR e pode ser acessado antes de se insta-
lar o arquivo JAR no aplicativo (JOHNSON, 2007). As próximas subseções descrevem
detalhadamente cada um desses arquivos.
4.3.1 JAR
Todas as MIDlets são empacotadas antes de serem transferidas a um dispositivo, isso
é feito através de um método de compressão onde são colocadas todas as informações em
um único arquivo cuja extensão é .JAR. Este arquivo engloba classes Java, recursos e
informações do empacotamento, com citado anteriormente (MUCHOW, 2001).
O arquivo JAR providencia muitos benefı́cios, como: segurança, através de assinaturas
digitais; compressão; empacotamento de extensões, juntando vários tipos de extensões
diferentes em uma única: o .JAR; portabilidade e o fato de quando é necessário fazer o
download de uma aplicação apenas um arquivo deve ser baixado (SUN, 2008b).
4.3.2 JAD
Conforme estudado, além do JAR é criado um arquivo em separado de extensão .JAD
que contém informações sobre o MIDlet. Este arquivo é usado muitas vezes para preparar
o JAR para ser instalado, otimizando a instalação do aplicativo, porém nem todos os
aparelhos precisam ler o .JAD para realizar a instalação. O arquivo JAD possui a seguinte
estrutura:
MIDlet-Name: Nome da Suite MIDlet.
MIDlet-Version: Versão da MIDlet.
MIDlet-Vendor : Desenvolvedor da MIDlet.
4.4. Interface 22
MIDlet-Icon: Especifica o ı́cone da tela inicial da aplicação.

MIDlet-Description: Descrição da aplicação.
MIDlet-info-URL: Endereço para um arquivo de informações (JAR).
MIDlet-DATA-Size: Tamanho dos dados.
4.4 Interface
Os dispositivos móveis que implementam o perfil MIDP possuem diversas restrições
quando se trata de interface, podendo variar em tamanho de tela, número de cores apresen-
tadas na tela, disposição dos botões, etc. E estas informações são acessadas pela MIDlet
somente em tempo de execução. Sendo assim, o MIDP só permite a utilização de objetos
visuais simples, não sendo permitida a implementação de objetos comuns na versão Java
para desktop (JOHNSON, 2007).
O Java ME tem como padrão para construção de interfaces à biblioteca LCDUI, que
é responsável pelos componentes que formam a interface de aplicações MIDP. Nesta se-
ção estudaremos algumas classes desta biblioteca, que estão dispostas de acordo com a
hierarquia mostrada na Figura 4.2.
Figura 4.2: Hierarquia de classes.

4.4. Interface 23
Display e Displayable
Para desenvolver interfaces que se encaixem em dispositivos móveis com diferentes
caracterı́sticas de tela, as aplicações são desenvolvidas com uma certa abstração. Para
acessar as informações de um determinado aparelho existe a classe Display e cada MIDlet
possui sua própria instância desta classe que pode ser acessada pelo método getDisplay(),
que geralmente está contido no método startApp(), pois o Display só pode ser acessado
depois que aplicação tenha sido iniciada.
Portanto, a tela do dispositivo é representada por uma instância 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 usuários. Eles
representam conteúdos de uma tela na qual há interação com o usuário (JOHNSON,
2007). Cada aplicação possui apenas uma instância da classe Display, sendo assim podem
existir vários objetos Displayable mas apenas um é mostrado por vez (MUCHOW, 2001).
Os objetos Displayable que estão na memória, mas não estão sendo mostrados estão no
chamado background e o objeto que está sendo mostrado está no foreground. Portanto os
objetos que estão no background não tem acesso ao Display. Para mostrar um Displayable
na tela usamos o método setCurrent() e para obter qual objeto está sendo mostrado no
Display usamos o método getCurrent() (JOHNSON, 2007).
A classe Displayable da origem a duas outras classes: Screen e Canvas. Ambas são
classes para representar interfaces, porém a primeira classe, juntamente com suas subclas-
ses formam componentes de interface de alto nı́vel e a segunda de baixo nı́vel (MUCHOW,
2001).
Screen
Screen é uma classe que contém objetos gráficos prontos, onde cada uma pode ter uma
aparência, variando de acordo com o dispositivo em que esta sendo executada a aplicação
(JOHNSON, 2007). Screen e suas heranças são classificadas como objetos de interface de
alto nı́vel (High-Level APIs) e as heranças desta classe são as classes Form, List, Alert e
Textbox (MUCHOW, 2001).
Form
Form é um formulário o qual pode conter textos, imagens e outros componentes para
serem exibidos no visor. Vários componentes podem ser colocados em um Form e se
houver necessidade ele apresenta barra de rolagem automática para mostrar todos estes
componentes visuais. Porém nada muito extenso é viável para aplicações móveis.
4.4. Interface 24
Esses componentes que podem ser adicionados em um Form são subclasses da classe
Item e serão estudados posteriormente. Um Form possui métodos para adicionar, inserir,
apagar e substituir componentes. Estes componentes da classe Item só pode ser inseri-
dos em um Form e não 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 são:
• StringItem
É um simples texto estático, ou seja, não pode ser editado.
• TextField
É um campo para entrada e/ou edição de texto. Podendo ser associadas regras a
este. Por exemplo: aceitar somente números, 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: múltiplo, exclusivo
ou pop up.
1. Múltiplo: Podem ser selecionadas várias opções, marcando uma caixa de che-
cagem que acompanha os elementos da lista;
2. Exclusivo: Pode ser selecionado apenas uma opção e esta é marcada com um
radioButton.
3. Pop up: Pode ser selecionada apenas uma opção. A lista é exibida como
uma comboBox, ou seja, os elementos ficam escondidos e quando clicada esta
lista toda é exibida. Após a seleção de um elementos os outros elementos são
escondidos novamente.
• DataField
Campo utilizado para exibir e/ou entrar com data e/ou hora.
4.4. Interface 25
• Gauge
É uma representação gráfica de um número inteiro. Ele permite que o usuário
defina um nı́vel, como o volume por exemplo, se for um Gauge interativo. Se for
não interativo é somente o programa que o controla (MUCHOW, 2001).
• Spacer
Determina um espaçamento vertical e/ou horizontal mı́nimo entre os componentes
de um Form. Ele é utilizado por questões de design de layout.
• CustomItem
Utilizado para criar itens especı́ficos, através de desenhos, utilizando a classe Graphics
da API de baixo nı́vel (MATTOS, 2005).
List
É uma lista que permite ao usuário selecionar opções. Estas podem ser tanto uma
String quanto uma imagem. O List pode ser exclusivo, múltiplo ou implı́cito. Implı́cito é
quanto a lista é exibida sem nenhum marcador e somente uma opção pode ser escolhida,
gerando um evento quando é selecionada uma das opções. Os outros dois tipos funcionam
igualmente ao ChoiceGroup (MATTOS, 2005).
Alert
É uma tela de informação ao usuário. Pode conter uma mensagem de erro, de sucesso,
de informação, entre outras. Ele pode ser programado para ser exibido durante um tempo
pré determinado, pode ser composto de um texto e uma imagem e sua aparência varia de
acordo com o dispositivo móvel usado (MATTOS, 2005).
TextBox
Basicamente é uma tela que serve para entrada e edição de texto. É como se fosse um
Item textField, porém só existe ele na tela. Em um textBox também podem ser usadas
regras, assim como em um textField (SUN, 2006b).
Canvas
Canvas é uma classe de baixo nı́vel, que proporciona maior liberdade na implementação
dos gráficos e eventos. É destinada a aplicações que necessitam de posicionamento preciso
dos elementos gráficos, sendo portanto muito utilizada para a criação de jogos.
4.5. Armazenamento Persistente 26
Através da utilização desta classe é possı́vel desenhar na tela. O desenvolvedor cria

o que será mostrado para o usuário final. Para criar uma interface gráfica com canvas é
utilizado a classe Graphics, que fornece métodos para desenhar linhas, arcos, retângulos
e textos, além de especificar cores e fontes (MUCHOW, 2001).
Além 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, funções, aos objetos mostra-
dos na tela (JOHNSON, 2007). Os comandos são usados para a interação do usuário com
a aplicação podendo ser atribuı́dos a qualquer Displayable, de alto ou baixo nı́vel, e a um
Item. Quando um comando é acionado pelo usuário, é notificado a um CommandListener
que é definido no objeto Displayable. Um command contém somente uma informação
sobre o comando e não sobre qual ação realizar. A ação 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 móveis que usam o perfil MIDP possuem, como memória volátil, a
memória RAM e, como memória de armazenamento persistente, a memória flash. Esta
permite armazenar dados por longos perı́odos de tempo, sem a necessidade de ser mantida
energizada por uma bateria ou fonte elétrica.
As vantagens da memória flash são: o pequeno tamanho fı́sico, a resistência a choques,
o alto desempenho para a leitura de dados, entre outros. E algumas de suas desvantagens
são o fato de as operações de escrita serem lentas e a capacidade de armazenamento ser
restrita. Porém, a maioria dos dispositivos móveis contam com um cartão de memória,
que serve como um drive de armazenamento. O cartão oferece solução ao armazenamento
restrito, porém o seu acesso é mais lento se comparado com o acesso a memória 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
4.5. Armazenamento Persistente 27
Connection, que implementa um sistema de armazenamento em arquivos. Porém não são

todos os dispositivos que fornecem acesso a esta última API (LUGON, 2005).
4.5.1 RMS
A API RMS é o mecanismo padrão para persistência 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 são como armazéns 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. Então quando um MIDlet é removido de um dispositivos todos os Record Stores
relacionados a ele serão removidos também. O limite de armazenamento é o mesmo que
o dispositivo oferecer.
A API RMS não suporta tipos caracterı́sticos 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 aplicação 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 são identificados por uma chave primária, chamada
Record ID, que é um inteiro. Logo, cada registro é formado por um inteiro e um array de
bytes. A API fornece métodos para abrir, fechar e deletar um RecordStore inteiro. Além
destes existem métodos para a manipulação dos registros como, adicionar, modificar,
deletar, recuperar um registro e a quantidade de registros existentes (SOUSA, 2006).
Capı́tulo 5
APIs e Frameworks para Java ME
Através de frameworks e APIs especı́ficas é possı́vel construir aplicações com mais

recursos, dispondo de várias funcionalidades extras, que não são encontradas nas especi-
ficações do perfil MIDP, além de otimizar o desenvolvimento. Este capı́tulo lista algumas
APIs e frameworks mais utilizados no desenvolvimento de aplicações 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 aplicações que se conectam a servidores remotos, com
outros aparelhos, aplicações que utilizam bluetooth, que executam músicas e vı́deos, entre
outras. Algumas das APIs opcionais disponı́veis para o perfil MIDP são citadas por
(JOHNSON, 2007).
• Java APIs for Bluetooh (JSR 82) - Permite o desenvolvimento de aplicações para
acesso à rede bluetooh.
• Location API (JSR 179) - Permite o desenvolvimento de aplicativos baseados em

localização fı́sica (LBS).
• Mobile Game API (JSR 178) - Voltada para criação de jogos.
• Mobile Media API (JSR 135) - Permite reprodução de mı́dia.
• Security and Trust Services API for J2ME (JSR 177) - Usada para adicionar segu-
rança às aplicações.
• Wireless Messaging (JSR 120 e 205) - Permite troca de mensagens SMS.
28
5.1. APIs 29
Entre outras APIs opcionais importantes para auxiliar no desenvolvimento de aplica-

ções temos:
• File Connection API (JSR 75) - Permite acesso e armazenamento em arquivos e

acesso a programas nativos do dispositivo, como agenda, calendário, entre outros.
• Mobile Sensor API (JSR 256) - Permite a recuperação de dados de sensores internos
ou externos ao aparelho celular.
• MECHART - Uma API de terceiro, ainda não catalogada pela JCP, que permite
construir gráficos de maneira simples e rápida, sem a necessidade de programar
diretamente na classe Canvas.
Dentre estas, vamos estudar a FileConnection API, pois além 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 obrigatórios para a plataforma Java ME:
• O PIM - Pacote que permite desenvolvedores acessar os dados de PIM do aparelho,

tais como agenda, livro de endereços e listas de tarefas, que existe na maioria dos
dispositivos móveis.
• O Pacote opcional de conexão de arquivos (FCOP) - Permite aos desenvolvedores

o acesso à diversas formas de dados, tais como: imagens, sons, vı́deos, textos en-
tre outros tipos de dados do sistema de arquivo do dispositivo móvel. Isto inclui
dispositivos de armazenamento removı́veis, como cartões de memória.
O PIM e os arquivos de dados permitem a integração de aplicações com informações

sobre o dispositivo, permitindo aplicações mais inteligentes (SUN, 2009c).
Abaixo estão as importantes classes e interfaces:
• ConnectionClosedException - Lançada quando um método é invocado em uma Fi-

leConnection quando a conexão é fechada.
5.2. Frameworks 30
• FileSystemRegistry - Classe central de registros que possui a habilidade de listar

roots montadas através do método listRoots(). Ela também providencia métodos
para os ouvintes de registros (Registering listeners), estes são notificados se sistemas
de arquivos são adicionados ou removidos durante o tempo de execução.
• A FileSystemListener interface - Usada para recepção de notificações de status

quando é adicionado ou removido um sistema de arquivo raı́z.
• A FileConnection interface - Usada para acessar diretórios e arquivos no dispositivo.

Ela estende a Connection interface e mantêm inúmeros métodos úteis para criar,
remover diretórios e arquivos, lista de conteúdo de diretórios, configurar permissões,
obter informações de arquivos e efetuar operações de entrada e saı́da nos arquivo.
Os pacotes usados são:
• javax.microedition.pim
• javax.microedition.io.file
No desenvolvimento do estudo de caso foi explorado o pacote opcional de conexão de

arquivos (FCOP), dependente apenas do núcleo de classes definidas pelo CLDC.
A forma de acessar os arquivos é utilizando a FCOP através da interface FileConnec-
tion, muito usada por sinal. Para isto basta importar o pacote javax.microedition.io.file.-
FileConnection.
A FileConnection estende StreamConnection pela adição de métodos de arquivo e
diretório de manipulação. A funcionalidade adicional é semelhante a que se encontra
disponı́vel no J2SE, na classe java.io.File. Para a abertura de um arquivo é usado uma
URL no formato: file://host/path
Enfim, com métodos mais especı́ficos desta API é possı́vel manipular arquivos dentro
do aparelho, sem a necessidade de trabalhar com classes de baixo nı́vel (NOKIA, 2008).
5.2 Frameworks
Entre os frameworks mais utilizados para a otimização no desenvolvimento de aplica-

ções para dispositivos móveis estão:
• Floggy - Framework para persistência de dados.
• J2MicroDB - Fornece um banco de dados relacional limitado para dispositivos mó-

veis.
5.2. Frameworks 31
• Perst Lite - Banco de dados orientado a objetos para aplicações 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 código fonte.
• Diamont Powder - Acelera a criação de aplicações 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 aplicações em Java que fazem uso de bluetooth
Entre os frameworks citados neste trabalho, astravés de testes, os que melhor atende-
ram ao desenvolvimento do estudo de caso foram: o Floggy, pois abstrai significativamente
a complexidade dos códigos RMS para a persistência de dados, o LWUIT, que fornece in-
terfaces bastante atraentes, além de estar caminhando para ser o framework referência
em UI, por fim o KXML, para fazer o parse de XMLs, usado para interpretar os dados
trocados entre servidor e aplicação móvel.
5.2.1 Floggy
Uma das limitações impostas pelo perfil MIDP é a utilização da API RMS, na maioria
dos dispositivos, para a persistência de dados. Visando a dificuldade dos códigos utilizados
para acessar esta API surgiu o Floggy, framework de persistência free para J2ME/MIDP,
desenvolvido por brasileiros. Seu principal objetivo é abstrair os detalhes da persistência
de dados para o desenvolvedor, reduzindo os esforços de desenvolvimento e manutenção
(FLOGGY, 2009).
O Floggy utiliza comandos de alto nı́vel para encapsular os comandos necessários para
o armazenamento e recuperação de objetos, ou seja, o que está por trás deste framework
são códigos para acessar a API RMS (LUGON, 2005).
O framework é composto por dois módulos:
- Framework : responsável por fornecer os métodos de persistência como salvar, remover
e recuperar os dados, através de um arquivo JAR (11KB) que deve ser adicionada na
aplicação.
5.2. Frameworks 32
- Compilador: responsável por analisar, gerar e compilar o bytecode. Bytecode é o

código binário gerado pelo compilador Java, que mais tarde será interpretado por uma
JVM, sendo assim executada uma aplicação (FLOGGY, 2009).
O módulo framework apresenta as seguintes classes:
Persistable
Funciona como um marcador, assim as classes que o implementam são consideradas
persistentes para o Floggy.
PersistableManager
É a classe principal do framework, pois gerencia a persistência e permite executar
todas as operações de persistência, como carregar, salvar, recuperar, remover, listar, entre
outros.
Filter
As classes que implementam esta interface definem critérios para seleção dos registros
que devem ser listados ou capturados.
Comparator
As classes que implementam esta interface definem critérios para ordenar registros que
foram selecionados.
ObjectSet
Os resultados de seleção de registros resultam em objetos da classe ObjectSet. Assim
esta classe serve para obter uma lista de registros e funciona como um cursor.
PersistableMetaData
Reúne informações sobre os objetos de uma determinada classe, como número de
objetos, data da ultima modificação, entre outros (LUGON, 2005).
5.2.2 KXML
O KXML é um framework que faz o parser de XML, utilizando a técnica pull parser,
que será discutida na seção 6.2.1, do capı́tulo 6. Ele é utilizado para simplificar e otimizar
5.2. Frameworks 33
o acesso, parse e exibição de XMLs e é destinado principalmente a ambientes restritos

como em dispositivos que usam o perfil MIDP (HAUSTEIN, 2007).
Possui as três versões. A primeira versão foi criada para dispor a técnica pull parser
em dispositivos móveis e embarcados e é baseada em eventos de objetos. A segunda versão
é a versão corrente e possui caracterı́sticas de cursor em vez de se basear em eventos de
objetos. A terceira versão ainda está sendo produzida.
Segundo LECHETA (2006), as principais operações do KXML são:
• nextTag(): Aponta para o próximo inı́cio ou fim de tag, pulando eventos insignifi-
cantes como espaços em branco ou comentários.
• Require(): Obriga o cursor a ser posicionado onde for indicado.
• nextText(): Exige que a posição corrente seja uma tag de inı́cio. Retorna o texto
contido no elemento correspondente.
• getName(): Obtêm o nome da tag na posição corrente.
Um analisador de XML deveria não aceitar ou reconhecer documentos com erros,

porém devido as restrições dos dispositivos móveis isto não é possı́vel. 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 aplicação que será desenvolvida (HAUSTEIN,
2007).
5.2.3 LWUIT
O LWUIT (LightWeight User Interface Toolkit) é um framework para a criação de

interfaces gráficas ricas em dispositivos móveis, que suportam a tecnologia Java ME.
Inspirado no Swing da plataforma Java SE, foi projetado para ser o mais leve possı́vel,
comprometendo o mı́nimo possı́vel a aplicação final, visto que foi desenvolvido para dis-
positivos com capacidades restritas (SUN, 2009d).
Com o LWUIT não há mais necessidade de se desenhar telas em canvas para construir
interfaces mais amigáveis, é uma grande evolução visto que a complexidade para tal
tarefa é muito alta. O framework oferece melhorias a componentes gráficos de alto nı́vel
já existentes no Java ME, como List, Form, Alert, entre outros. Ainda oferece várias
outras vantagens como suporte a touch Screen, diversas fontes, animações, transições de
telas animadas e temas variados, que podem ser incluı́dos pelos próprios usuários.
Além das caracterı́sticas citadas acima, o LWUIT também inclui: a utilização de
layouts, que organizam a disposição dos componentes na tela, além de oferecer melhor
5.2. Frameworks 34
portabilidade, integração 3D (se o dispositivo possuir bibliotecas 3D), caixas de diálogo,

utilização de abas (como no Java SE) e internacionalização. O LWUIT roda no perfil
MIDP 2.0 e está sob a licença GPL v2.0 com a Classpath Excepption, o que significa que
pode ser utilizado em aplicações de códigos não abertos, desde de que não haja modificação
nas classes do framework (NETO, 2008).
O framework foi recentemente incorporado pela Sun como uma de suas bibliotecas
padrões, 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 utilização do LWUIT
dentro da comunidade de desenvolvedores (DOEDERLEIN, 2009).
Capı́tulo 6
Comunicação com o Servidor
Neste capı́tulo são apresentadas algumas caracterı́sticas da plataforma Java Enterprise

Edition (Java EE), a fim de estudar um método eficiente para a construção de servidores
de dados remotos para alimentar qualquer sistema móvel que necessite deste tipo de
comunicação.
6.1 A Plataforma Java EE
Existem diversas tecnologias que fornecem aplicações com conteúdo dinâmico e per-
sonalizado, seja para construir um simples site de conteúdo dinâmico 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 aplicações
robustas para a Web. Dentre as tecnologias disponı́veis atualmente, destacam-se para o
desenvolvimento de aplicações os servlets e páginas JSP (JavaServer Pages). servlets e
JSP são duas tecnologias desenvolvidas pela Sun para desenvolvimento de aplicações 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 utilização de servlets oferece diversas vantagens em relação a outras tecnologias para
o desenvolvimento de aplicações Web. As principais vantagens são herdadas da própria
linguagem Java, entre elas estão: Portabilidade, facilidade de programação e a flexibilidade
da linguagem para o desenvolvimento. Em particular, os servlets são mais eficientes,
apresentam melhor usabilidade, maior poder na programação, são mais portáteis, mais
seguros e mais baratos que um CGI (Common Gateway Interface) tradicional (HALL,
1998).
35
6.1. A Plataforma Java EE 36
Figura 6.1: Arquitetura da plataforma Java EE.
CGI é um padrão que determina a forma de comunicação entre o servidor Web e

uma outra aplicação rodando neste servidor e um script CGI é um programa que atende
requisições enviadas por um cliente e repassa para um servidor HTTP (QUIN, 2009).
Um servlet tem um modelo de programação parecido com um script CGI, porém os
programas de CGI necessitam de um processo para tratar cada nova solicitação e no caso
dos servlets, podem existir vários ligados ao mesmo servidor, que estes são executados
dentro de um mesmo processo. E este processo roda dentro de uma JVM, que gera
um encadeamento de processos para tratar cada solicitação. 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 programação
CGI. São 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 usuário.
• Observar qualquer outra informação sobre o pedido que é embutido no pedido de

HTTP.
• Gerar os resultados.
• Formatar os resultados dentro de um documento.
• Fixar parâmetros de resposta de HTTP apropriados.

6.1. A Plataforma Java EE 37
• Enviar de volta o documento ao cliente.
Servlets são 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 aplicações Java que
permite a execução de servlets comunicando com clientes.
O componente container, ou contêiner, é resposnsável por dar suporte as APIs de
servlets e JSP. Gerência as instâncias dos servlets e fornece os serviços de rede necessários
para as requisições e respostas. O container pode criar várias threads permitindo que
uma única instância servlet atenda mais de uma requisição simultaneamente. A Figura
6.2 ilustra a relação entre esses componentes.
Figura 6.2: Servlet container.
Os servlets são independentes de protocolos e plataformas, podendo trabalhar com

diversos tipos de servidores, pois a API dos servlets não assume nada a respeito do am-
biente do servidor. Diversas requisições podem ser feitas ao mesmo tempo em um único
servidor.
O comportamento dos servlets que será estudado para a construção de aplicações
está definido na classe HttpServlet do pacote javax.servlet. Tendo em vista o paradigma
request-response, cujo atende requisições realizadas por meio do protocolo HTTP, os ob-
jetos dos servlets podem capturar parâmetros desta requisição, efetuar qualquer proces-
samento inerente a uma classe Java e enviar respostas na forma de páginas HTML, XML,
imagens entre outros (TEMPLE, 2004).
Um servlet é básicamente definido pela Interface Servlet, uma classe de interface que
implementa os métodos init(), service() e destroy(), e a estrutura de uma classe servlet
contém os métodos doGet() e doPost(), como ilustrado na Figura 6.3.
Todos os seguintes métodos são invocados por meio do método service() da classe de
interface.
6.2. XML - Linguaguem de marcação extensı́vel 38
Figura 6.3: Ciclo de vida do servlet.
• Método doGet: Trata requisições do tipo GET. Esse tipo pode ser enviado várias
vezes e alocado em um bookmark.
• Método doPost: Trata requisições do tipo POST, permitindo que o cliente envie
dados do servidor Web uma única vez.
• Método doPut: Trata requisições do tipo PUT, permitindo que o cliente envie
arquivos para o servidor, semelhante ao FTP.
• Método doDelete: Trata requisições do tipo DELETE, permitindo que o cliente

remova determinada página ou documento do servidor.
Um servlet não possui interface gráfica, porém dentro de um servlet é possı́vel construir
um HTML, mas a visualização e entendimento é de alta complexidade quando se trata
de lógicas extensas. Tendo em vista que o foco do estudo de caso está em um ambiente
móvel, não é necessário a construção de uma interface gráfica para trabalhar junto com o
servlet.
6.2 XML - Linguaguem de marcação extensı́vel

A Extensible Markup Language (XML) é uma linguagem de marcação de dados sem
nenhum elemento de apresentação embutido, ou seja, apenas com elementos de definição
de conteúdo. O XML provê um formato para descrever dados estruturados que facilita
declarações mais precisas do conteúdo e resultados mais significativos de busca através de
múltiplas plataformas.
Segundo TITTEL (2002), a palavra extensı́vel reflete o fato de que a linguagem é
flexı́vel, escalonável e adaptável. Com esses três fatores o desenvolvimento de aplicações
em três camadas (three-tier ), que é o caso deste projeto, é altamente factı́vel com o XML.
Os dados podem ser distribuı́dos entre as aplicações desktop para serem visualizados em
um navegador ou em servidores intermediários 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 informações entre dispositivos móveis e servidores
remotos seria realizada de maneira mais comprimida e escalável, além de proporcionar
buscas mais eficientes. Esse ponto é de suma importância, pois os dispositivos móveis
tipicamente possuem memória limitada e baixo poder de processamento.
A estrutura de um documento XML é baseada em um modelo de árvore rotulada.
Geralmente possui um nó raiz especial acima do elemento raiz. Os nós internos são
elementos rotulados com um nome e um conjunto de atributos (valor). Os nós folhas
contém:
• Sequências de caracteres
• Anotações de processamento, normalmente no cabeçalho do documento
• Um comentário
• Uma declaração de entidade
• Nós DTD (Document Type Declaration)
Podemos visualizar uma breve estrutura de um documento XML com sua respectiva
árvore na Figura 6.4.
6.2.1 Análise de documentos XML

A partir de um modelo no formato XML é necessário realizar a análise dos dados
embutidos através de uma técnica denominada Parse. Segundo VELOSO (2007), Par-
sing é o processo de leitura e divisão do documento em elementos, atributos, entidades,
comentários e outros tipos de dados, por meio do qual poderão ser analisados e validados.
Existem algumas técnicas 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 próxima parte que deve ser processada até
chegar ao fim, geralmente isto é feito em um loop. Assim são obtidas as informações do
Figura 6.4: Estrutura do XML.
XML a medida que o parser é efetuado. Uma outra técnica é o DOM, que utiliza um
modelo baseado em árvore e cria uma estrutura de dados na memória, onde é possı́vel
acessar essa estrutura através de um conjunto de objetos. É muito simples de se utilizar,
porém é necessário ler o documento inteiro para montar a estrutura de árvore, para depois
exibir as informações que foram lidas, além disso, pode ter muitos objetos armazenados na
memória então não 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 são encontradas.
Capı́tulo 7
Estudo de Caso
Para aplicar os conceitos estudados nos capı́tulos anteriores foi desenvolvido um estudo
de caso destinado a celulares e smartphones que possuam sistema operacional Symbian,
Windows Mobile ou que possuam suporte a Java. O estudo de caso representa o resultado
de um projeto de desenvolvimento de software que utilizou os valores e práticas do extreme
programming durante um perı́odo de três meses.
7.1 Extreme programming

Extreme programming (Programação extrema), ou XP, é uma metodologia ágil de de-
senvolvimento de software voltada para projetos cujos requisitos mudam com frequência.
O desenvolvimento é orientado a objetos e possui equipes de desenvolvimento pequenas.
Assim como outros métodos ágeis, o XP parte da premissa que o cliente aprende quais
as suas reais necessidades no decorrer do desenvolvimento do software, quando ele vai
manipulando as funcionalidades do sistema. Sendo assim uma das principais práticas do
XP é que o cliente esteja sempre presente (TELES, 2004).
No XP todas as funcionalidades do sistema são descritas em estórias, escritas pelos
clientes, e os desenvolvedores implementam as partes do sistema baseados nestas estórias.
Em uma reunião, chamada jogo de planejamento, o tempo de implementação de cada
estória é definido utilizando um sistema de pontos, onde um ponto significa um dia ideal
de trabalho, cujo desenvolvedor gaste todo o tempo somente na implementação. O cliente
prioriza quais as estórias que devem ser implementadas primeiro e então o sistema é
desenvolvido em partes, podendo assim ser entregue periodicamente releases do sistema.
Estes releases são intervalos de tempo menores, onde algumas funcionalidades que gerem
valor ao cliente possam ser entregues (TELES, 2004).
Mesmo os releases sendo curtos ainda representam um tempo longo para um feedback
do cliente. Por esta razão eles são divididos em espaços de tempo menores, chamados de
41
7.2. Arquitetura do sistema 42
iterações. Cada iteração contêm um conjunto de estórias e no final desta o cliente pode
validar as implementações efetuadas e dar seu feedback. O XP utiliza ainda o conceito de
programação em par. Enquanto uma das pessoas está escrevendo o código a outra pessoa,
chamada de navegador, está permanentemente revisando. Todo código desenvolvido é
coletivo, portanto utiliza-se padronização para simplificar o desenvolvimento (TELES,
2004).
O XP oferece agilidade no processo de desenvolvimento de software e um feedback
rápido do cliente, o que é necessário quando se trata de desenvolvimento para celulares e
smartphones, por ser um sistema enxuto. Portanto, para este estudo de caso foi adotado
as práticas da metodologia ágil XP, onde foram definidos dois releases, cada um composto
por duas iterações. As iterações 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 comunicação com o dispositivo móvel. 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 móvel e o servidor remoto
de dados, que alimentará o sistema móvel, foi utilizado os recursos que a linguagem XML
oferece.
A Figura 7.1 mostra o esquema de comunicação para o trabalho proposto. Definido
por uma arquitetura Cliente - Servidor e baseado nas três seguintes camadas:
Figura 7.1: Esquema de comunicação.

7.3. Visão geral do sistema 43
7.3 Visão geral do sistema
É proposto um sistema móvel gerador de pedidos para uma empresa revendedora de

bebidas. O sistema será responsável por cadastrar e editar clientes, gerar os pedidos
realizados, 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 através de consultas a
catálogos e toda informação 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 responsável por alimentar o sistema móvel.
Com este sistema a gerência otimiza o acesso aos dados de forma segura, além 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́ possı́vel
atualizar o banco de dados do dispositivo e enviar os pedidos para um sistema Web que
irá armazenar as informações no banco de dados central da distribuidora, controlando
todas as informações referente à força de vendas.
7.4 Diagrama de Caso de Uso

Para o melhor entendimento do sistema, o diagrama de casos de uso mostrado na
Figura 7.2, descreve o cenário que mostra as funcionalidades do sistema do ponto de vista
do usuário.
Figura 7.2: Diagrama de Caso de Uso.

7.5. Estórias 44
7.5 Estórias
As Figuras 7.3 a 7.7 ilustram estórias, que na prática são escritas pelo cliente. Estas
estórias contém as funcionalidades que um cliente deseja possuir em seu sistema e forne-
cem a base para os desenvolvedores implementarem as soluções necessárias, ou seja essas
estórias fornecem os requisitos do sistema. O modelo clássico dos cartões de estórias foi
adotado, a fim de seguir padrões das práticas XP.
Figura 7.3: Estória 1-A: Consulta de produtos.
A estória 1-A corresponde ao caso de uso ”Consultar Produto”.
Figura 7.4: Estória 1-B: Consulta e cadastro de clientes.
A estória 1-B corresponde ao caso de uso ”Gerenciar Cliente”.

7.5. Estórias 45
Figura 7.5: Estória 2-A: Cadastro de pedidos.
Figura 7.6: Estória 2-B: Alteração de pedidos.
As estórias 2-A e 2-B correspondem aos casos de uso ”Gerenciar Pedido”.

7.6. Release 1 46
Figura 7.7: Estória 2-C: Envio dos dados para o banco central da empresa.
A estória 2-C corresponde ao caso de uso ”Exportar dados”.

Os casos de uso ”Autenticar Usuário”e ”Atualizar Banco”não estão descritos nas estó-
rias, porém são necessidades do sistema.
7.6 Release 1
Este release é dividido nas seguintes iterações:
7.6.1 Iteração A
Nesta iteração foi utilizada a estória 1-A (”Consulta de produtos”) como base para
implementação. Neste ponto foram implementados os métodos para importação de um
documento XML do servidor, que contém os dados de produtos e clientes armazenados no
banco de dados da empresa. Foi construı́do localmente o banco de dados dos produtos,
desenvolvida a interface com o usuário da tela principal, busca, listagem e detalhes dos
produtos. Foram implementadas as funcionalidades referentes a essas telas. Os diagramas
de classes de projeto, mostrados pelas Figuras 7.8 a 7.10, mostram os atributos das classes
nas respectivas regras de negócio, com o propósito de deixar de forma bem definida os
dados envolvidos no estudo de caso.
7.6. Release 1 47
Figura 7.8: Diagrama de classe de projeto - Produto.
7.6.2 Iteração B
Para esta iteração foi utilizada a estória 1-B (”Consulta e cadastro de clientes”) como
base para implementação. Foram implementados os métodos para construção do banco
de dados local a partir dos dados dos clientes que estão no XML importado na Iteração
A. Foi desenvolvida a interface com o usuário e implementada uma busca de clientes. Os
dados dos clientes buscados podem ser detalhados e novos clientes podem ser cadastrados.
Figura 7.9: Diagrama de classe de projeto - Cliente.

7.7. Release 2 48
7.7 Release 2
Este release é dividido nas seguintes iterações:
7.7.1 Iteração A
Nesta iteração foi utilizada a estória 2-A (”Cadastro de pedidos”) como base para
implementação. Foram implementados os métodos de cadastro e listagem de pedidos,
bem como as interfaces de usuário correspondentes.
7.7.2 Iteração B
Nesta iteração foram utilizadas as estórias 2-B (”Alteração de pedidos”) e 2-C (”Envio
dos dados para o banco central da empresa”) como base para implementação. Foram
implementados os métodos de edição e exclusão dos pedidos cadastrados e as interfaces
correspondentes. Neste ponto também foram implementadas as funcionalidades necessá-
rias para exportação dos dados dos pedidos e clientes cadastrados. Desta forma os dados
podem ser exportados para o servidor em forma de um ducumento XML.
Figura 7.10: Diagrama de classes de projeto.

7.8. A Aplicação 49
7.8 A Aplicação
A aplicação desenvolvida no estudo de caso, um sistema móvel de força de venda
para uma distribuidora de bebidas, teve seu foco sobre a plataforma Java ME, utilizando
também o Java EE para a construção de um servidor que armazena documentos XMLs,
com dados que alimentam a aplicação móvel. Estes XMLs contém dados dos produtos
e clientes já cadastrados, além de oferecer uma gama de logins e senhas válidos para a
autenticação do usuário.
A aplicação móvel foi construı́da utilizando os frameworks já citados anteriormente:
LWUIT, KXML e Floggy. O LWUIT, proporcionou uma interface rica para a aplica-
ção e trata os eventos touchScreem; o KXML facilitou a leitura dos documentos XMLs,
armazenados no servidor, realizando o parse destes; e o floggy auxiliou os métodos de per-
sistência, simplificando os métodos para o armazenamento dos dados, em Records Stores,
armazéns de dados gravados na memória do celular ou smartphone.
Além dos frameworks citados, o sistema móvel faz uso da File Connection API, res-
ponsável, dentre outras funções, pelo acesso à arquivos situados no sistema de arquivos
local do dispositivo móvel utilizado. Na aplicação, esta API proporciona a gravação de
um arquivo XML de sáida, com os novos dados obtidos na aplicação, ou seja, dados de
pedidos e novos clientes.
Quando a aplicação é executada faz um acesso ao servidor, obtendo dados do XML
que contém os logins e senhas válidos e faz uma comparação com o login e senha digitados,
procurando se o login existe na lista e se a senha confere. A tela de autenticação pode
ser observada na Figura 7.11. Autenticado, o usuário possui acesso ao menu principal
da aplicação, ilustrado na Figura 7.12. Este menu fornece acesso: à Clientes, permitindo
funções de busca e cadastro; Produtos, permitindo funções de somente de busca; Pedidos,
onde é possı́vel cadastrar novos pedidos, utilizando as funções de busca de clientes e
produtos; Lista de Pedidos, que dispõe uma lista de pedidos já cadastrados permitindo
que estes sejam alterados ou excluı́dos; Importação, permite que a aplicação acesse o
servidor remoto, trazendo os dados dos XMLs de produtos e clientes para o banco de
dados local do dispositivo móvel; e Exportação, gera um arquivo XML de saı́da com
os dados dos clientes e pedidos cadastrados. Este arquivo é armazanado no cartão de
memória do celular ou smartphone, para ser enviado para o servidor ou utilizada de outra
forma desejada.
Figura 7.11: Autenticação do usuário.

Figura 7.12: Menu principal da aplicação móvel.
As telas ilustradas nas Figuras 7.13, 7.14 e 7.15 mostram respectivamente um cadastro
de clientes, uma busca de produtos e o detalhamento de um produto buscado. A primeira
tela pode ser obtida através do menu clientes e as duas últimas através do menu produtos.
E as Figuras 7.16 e 7.17 ilustram uma tela de cadastro de pedidos e a lista destes, onde
podem ser escolhidas as opções de editar ou excluir um pedido realizado. Estas telas
podem ser obtidas respectivamente nos menus Pedidos e Lista de Pedidos.
Figura 7.13: Cadastro de Clientes.

Figura 7.14: Busca de Produtos.

Figura 7.15: Detalhamento de produto.

Figura 7.16: Cadastro de pedidos.

Figura 7.17: Lista de pedidos.

Capı́tulo 8
Considerações Finais
Após estudos que culminaram nesta dissertação e através do desenvolvimento do es-

tudo de caso podemos chegar nas seguintes conclusões.
Atualmente o uso de telefones celulares no mundo é bastante elevado. Organizações
corporativas estão evoluindo juntamente com tecnologias móveis para a otimização do
processo de negócio. Dessa forma o uso de smartphones vem se tornando de grande utili-
dade tanto nestas organizações quanto para o uso particular. Visto que a plataforma Java
Micro Edition é bem aceita pelo mercado de software, torna-se viável o desenvolvimento
de aplicações móveis e embarcadas usando tal tecnologia.
O perfil MIDP é suportado pela configuração CLDC, providenciando um ambiente
padrão de execução de aplicações Java para os dispositivos móveis mais convencionais.
Este perfil provê um conjunto de bibliotecas e classes que fornecem um sistema de arma-
zenamento persistente, interface com o usuário, transações seguras, gerência de sons, entre
outras caracterı́sticas que proporcionam um bom ambitente de desenvolvimento. Através
de MIDlets foi possı́vel desenvolver aplicações utilizando o perfil MIDP. Estas aplicações
Java podem ser construı́das através da biblioteca LCDUI, que fornece componentes para
o desenvolvimento da interface das aplicações. Porém, também existem frameworks que
porporcionam o desenvolvimento de interfaces com o usuário mais robustas.
Para a comunicação da aplicação móvel com um servidor remoto de dados, o uso
da plataforma Java EE com a implementação de servlets se torna algo muito eficiente,
tanto para a segurança dos dados quanto para a compatibilidade entre as plataformas.
A transferência dos dados pode ser realizada através de diversas extensões de arquivos,
seja no formato de documentos XML, imagens, arquivos compactados ou até mesmo em
formato de strings, através de requisções HTTP. Vale ressaltar que a transferêcia de dados
utilizando documentos XML é muito bem organizada e segue um padrão de transferência
de informação unificado, porém o uso desse tipo de documento causa um leve retardo
57
58
tanto no desempenho da aplicação durante a leitura das informações quanto ao tamanho

do arquivo de tranferência, que fica levemente extenso devido a padronização e organização
das informações.
Através de alguns frameworks foi possı́vel construir uma aplicação com mais recur-
sos, além de otimizar o desenvolvimento. As tarefas mais rotineiras utilizadas para o
desenvolvimento de aplicações comerciais tratam do armazenamento persistente dos da-
dos no próprio dispositivo, construção de interfaces com o usuário mais robustas e da
transferência de dados padronizados na forma de documentos XML. Tendo em vista es-
tas caracterı́sticas, através de testes e do levantamento bibliográfico, os frameworks que
melhor atenderam para a execução de tais tarefas foram respectivamente o Floggy - para
persistência dos dados, o LWUIT - para interfaces mais robustas, e o KXML - para realizar
o parse de documentos XML.
A File Connection API é a API usada para manipulação de arquivos e diretórios do
dispositivo. Visando uma possı́vel implementação deste tipo de funcionalidade, seja para
contrução de um XML de saı́da ou de qualquer outro arquivo, o uso desta API é de suma
importância para aplicações móveis.
Para auxiliar no desenvolvimento do estudo caso, a metodologia ágil extreme program-
ming organizou o processo de desenvolvimento, proporcionando um estudo de caso bem
elaborado e definido seguindo referências da Engenharia de Software. A agilidade no
desenvolvimento de sistemas móveis é essencial, pois trata-se de um sistema exuto, que
necessita de constante feedback do cliente.
Desenvolver aplicações móveis nativas para diferentes plataformas requer conhecimento
especı́fico de diferentes linguagens. Sendo assim, um desenvolvedor necessita dedicar-se
a apenas uma ou duas plataformas e ainda precisa verificar em qual delas é mais viável
o desenvolvimento, o que é uma tarefa difı́cil. O Android é uma plataforma nova, em
fase de construção, possui diversas APIs opicionais para o desenvolvimento, mas ainda
a oferta de dispositivos não alcança o mundo todo. Restringir o desenvolvimento ao
Windows Mobile ou Symbian OS também não torna-se viável, visto que estes suportam
aplicações Java ME com a utilização de máquinas virtuais Java. O Palm OS é uma
plataforma que está em decadência, tanto que a Palm está disponibilizando aparelhos
com Windows Mobile. A empresa ainda está investindo em seu SO, porém não está
conseguindo superar os outros existentes no mercado. O iPhone possui um SO muito
robusto e atrativo, o que torna o desenvolvimento de aplicações para este muito lucrativas,
porém restringe as aplicações a apenas este SO. Em contra partida a plataforma Java ME
oferece portabilidade e acessibilidade, além de concentrar isto em uma única linguagem.
Referências Bibliográficas
ADMOB (2009). Admob mobile metrics report. Disponı́vel on-line em maio de 2009 no
endereço http://www.admob.com/marketing/pdf/mobile metrics jul 08.pdf.
AGÊNCIAESTADO (2009). Paı́s supera 152 milhões de celulares em fe-

vereiro. G1. Disponı́vel on-line em março de 2009 no endereço
http://g1.globo.com/Noticias/Economia Negocios/0 MUL1051483-9356,00-
”
PAIS+SUPERA+MILHOES+DE+CELULARES+EM+FEVEREIRO.html.
APPLE (2009a). More power to your mac. Disponı́vel on-line em maio de 2009 no endereço
http://www.apple.com/macosx/technology/.
APPLE (2009b). What is cocoa? Disponı́vel on-line em maio de 2009 no endereço

http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/
WhatIsCocoa/WhatIsCocoa.html.
CLAUSEN, D. (2003). Microfloat. Disponı́vel on-line em abril de 2009 no endereço

http://www.dclausen.net/projects/microfloat/.
Developers, A. (2009). What is android? Disponı́vel on-line em maio de 2009 no endereço

http://developer.android.com/guide/basics/what-is-android.html.
DOEDERLEIN, O. P. (2009). Java: Uma perspectiva. revista Java Magazine, edição 65.
FLOGGY (2009). Welcome to floggy. Disponı́vel on-line em Julho de 2009 no endereço

http://floggy.sourceforge.net/.
HALL, M. (1998). Core Servlets and JavaServer Pages. Sun Microsystems, 1th edition.
HAUSTEIN, S.; KROLL, M. P. J. (2007). About kxml. Disponı́vel on-line em Julho de

2009 no endereço http://www.kobjects.org/kxml/.
INFO (2008). Nokia compra ações da samsung na symbian. Disponı́vel on-line em maio de
2009 no endereço http://info.abril.com.br/aberto/infonews/092008/02092008-13.shl.
59
REFERÊNCIAS BIBLIOGRÁFICAS 60
JCP (2009a). Jsr 271: Mobile information device profile 3. Disponı́vel on-line em maio
de 2009 no endereço http://jcp.org/en/jsr/detail?id=271.
JCP (2009b). Jsrs: Java specification requests. Disponı́vel on-line em Julho de 2009 no
endereço http://jcp.org/en/jsr/all.
JCP, J. C. P. (2009c). Connected device configuration. Disponı́vel on-line em maio de

2009 no endereço http://jcp.org/en/jsr/detail?id=218.
JOHNSON, M. T. (2007). Java para Dispositivos Móveis - Desenvolvendo Aplicações com

J2ME. Novatec, 1th edition.
JONES (2009). Qual será seu próximo celular. revista info fevereiro de 2009.
LECHETA, R. R. (2006). kxml - fazendo parser de um xml

com j2me. Disponı́vel on-line em Julho de 2009 no endereço
http://www.devmedia.com.br/articles/viewcomp.asp?comp=2099.
LUGON, P. T. R. T. (2005). Floggy: Framework de persistência para j2me/midp.
LUZ, M. (2009). Midp 3.0: O que vem por ai. a nova especificação do principal perfil do
java me. Revista Java Magazine, edição 44.
MATTOS, r. T. d. (2005). Programação Java para Wireless - Aprenda a desenvolver

sistemas em J2ME. Digerati Editorial, 1th edition.
MICROSOFT (2009a). O que é o windows mobile? Disponı́vel on-line em maio de 2009

no endereço http://www.microsoft.com/brasil/windowsmobile/partners/default.mspx.
MICROSOFT (2009b). Qual é a diferença entre um pocket pc e um

smartphone? Disponı́vel on-line em maio de 2009 no endereço
http://www.microsoft.com/brasil/windowsmobile/about/faq.mspx#2.
MUCHOW, J. W. (2001). Core J2ME Technology & MIDP. Prentice Hall PTR, 1th
edition.
NETO, A. M. (2008). Lwuit: Swing para java me. revista Java Magazine, edição 60.
NOKIA (2008). Jsr 75 fille connection api. Disponı́vel on-line em Julho de 2009 no
endereço http://wiki.forum.nokia.com/index.php/JSR 75 File connection API.
PALMBRASIL (2009a). Conheça o palm. Disponı́vel on-line em maio de 2009 no endereço

http://www.palmbrasil.com.br/palm-os-webos/conheca-palm.
PALMBRASIL (2009b). Palm os. Disponı́vel on-line em maio de 2009 no endereço

http://www.palmbrasil.com.br/vocab/palmos.html.
PITTELLA, F. (2009). Cgi x servlets. Disponı́vel on-line em Junho de 2009 no endereço

http://www.javafree.org/artigo/1406/CGI-X-Servlets.html.
QUIN, L. (2009). Cgi: Common gateway interface. Disponı́vel on-line em Junho de 2009
no endereço http://www.w3.org/CGI/.
REUTERS (2008). Mundo terá 4 bi de celulares este ano.

Abril. Disponı́vel on-line em março de 2009 no endereço
http://info.abril.com.br/aberto/infonews/092008/25092008-21.shl.
RIM (2009). Visão geral. Disponı́vel on-line em maio de 2009 no endereço

http://br.blackberry.com/ataglance/.
SOUSA, A. E. J. (2006). Persistência em aplicativos para dispositivos móveis com j2me.

Revista WebMobile, edição 3.
SUN (2002). What’s new in midp 2.0. Disponı́vel on-line em maio de 2009 no endereço
http://developers.sun.com/mobility/midp/articles/midp20/.
SUN (2006a). Class command. Disponı́vel on-line em maio de 2009 no

endereço http://java.sun.com/javame/reference/apis/jsr118/javax/microedition/lcdui/
Command.html.
SUN (2006b). Class textbox. Disponı́vel on-line em maio de 2009 no

endereço http://java.sun.com/javame/reference/apis/jsr118/javax/microedition/lcdui/
TextBox.html.
SUN (2006c). Mid profile. Disponı́vel on-line em maio de 2009 no endereço

http://java.sun.com/javame/reference/apis/jsr037/.
SUN (2006d). Mid profile. Disponı́vel on-line em maio de 2009 no endereço

http://java.sun.com/javame/reference/apis/jsr118/.
SUN (2006e). Summary of cldc-based profiles. Disponı́vel on-line em maio de 2009 no

endereço http://developers.sun.com/mobility/midp/ttips/cldc/.
SUN (2007). A survey of java me today. Disponı́vel on-line em abril de 2009 no endereço
http://developers.sun.com/mobility/getstart/articles/survey/.
SUN (2008a). Cldc hotspot implementation architecture guide. Disponı́vel on-line

em maio de 2009 no endereço http://java.sun.com/javame/reference/docs/cldc-hi-2.0-
web/doc/architecture/html/Introduction.html#50638859 pgfId-431762.
SUN (2008b). Lesson: Packaging programs in jar files. Disponı́vel on-line em maio de
2009 no endereço http://java.sun.com/docs/books/tutorial/deployment/jar/.
SUN (2009a). Java me technology apis & docs. Disponı́vel on-line em maio de 2009 no
endereço http://java.sun.com/javame/reference/apis.jsp#api.
SUN (2009b). Javame technology - powering your devices everywhere. Disponı́vel on-line
em abril de 2009 no endereço http://java.sun.com/javame/technology/index.jsp.
SUN (2009c). Jsr 75 - pda optional packages. Disponı́vel on-line em Julho de 2009 no
endereço http://java.sun.com/javame/technology/msa/jsr75.jsp.
SUN (2009d). The lightweight user interface toolkit (lwuit): An in-

troduction. Disponı́vel on-line em Julho de 2009 no endereço
http://java.sun.com/developer/technicalArticles/javame/lwuit intro/.
SYMBIANBRASIL (2009). Symbian os. Disponı́vel on-line em maio de 2009 no endereço

http://www.symbianbrasil.com/Sobre.
TELES, V. M. (2004). Extreme Programming: Aprenda como encantar seus usuários

desenvolvendo software com agilidade e alta qualidade. Novatec, 1ed edition.
TEMPLE, André; MELLO, R. F. C. D. T. S. M. (2004). Programação Web com JSP,

Servlets e J2EE. Creative Commons, 1th edition.
TITTEL, E. (2002). Schaumt’s Outline of Theory and Problems of XML. The McGraw
Hill Companies, Inc., 1th edition.
TOPLEY, K. (2002). J2ME IN A NUTSHELL - A Desktop Quick Reference. O’Reilly,

1th edition.
VELOSO, R. R. (2007). Java e XML: Processamento de documentos XML com Java.

Novatec, 2ed edition.
VIRKI, T. (2009). Sun lança novo software java para celulares. Abril. Disponı́vel on-line
em março de 2009 no endereço http://www.abril.com.br/noticias/tecnologia/sun-lanca-
novo-software-java-celulares-266915.shtml.

Caso de Uso JME

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Caso de Uso JME

Enviado por

Direitos autorais:

Formatos disponíveis

Coordenação do Curso de Ciência da Computação

Universidade Estadual de Mato Grosso do Sul

Desenvolvendo um Estudo de Caso

Lais Claudia Zanfolim

André Chastel Lima (Orientador)

Lais Claudia Zanfolim

Este exemplar corresponde à redação final

Dourados, 11 de dezembro de 2009.

André Chastel Lima (Orientador)

Celso G. Camilo Jr (Co-orientador)

Desenvolvendo um Estudo de Caso

Lais Claudia Zanfolim

• André Chastel Lima (Orientador)

• Celso G. Camilo Jr (Co-orientador)

• Raquel Marcia Müller

• Nielsen Cassiano Simões

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

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

Keywords: Java ME, mobile, cell phones and smartphones.

2 Sistemas operacionais para dispositivos móveis 6

3 Java Micro Edition 11

5 APIs e Frameworks para Java ME 28

6 Comunicação com o Servidor 35

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

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

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

7.1 Esquema de comunicação. . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

PBP - Personal Basis Profile

Com a expansão da Internet e da utilização de aplicações, surgiram diversas linguagens

• CLDC - Connected Limited Device Configuration: para dispositivos com menor

a codificação desse tipo de dispositivos.

• Fazer um breve estudo sobre as plataformas de dispositivos móveis;

• Estudar a plataforma Java ME, voltada para dispositivos móveis;

• Estudar a plataforma Java EE para a construção de um servidor remoto;

• Estudar a comunicação entre o servidor e a aplicação móvel;

• Estudar alguns frameworks Java ME e definir quais serão utilizados no estudo de

• Definir os padrões da Engenharia de Software que serão utilizados na aplicação;

• Definir o estudo de caso;

• Desenvolver e testar o estudo de caso.

que o número de usuários de aparelhos celulares é significativo, que está em crescimento e

Sistemas operacionais para

A tecnologia da informação atinge a maior parte das empresas e instituições de forma

2.1 Dispositivos Móveis

2.2 Sistemas Operacionais e suas tecnologias

móvel. É a primeira plataforma open source para desenvolvimento de aplicações móveis,

2.2.3 Windows Mobile

Motorola. A desvantagem é que as aplicações criadas utilizando os novos recursos não

linha com uso de 64 bits, proporcionando a mais rápida implementação de javascript e

2.3 Análise do Mercado

Java Micro Edition

Neste capı́tulo são apresentadas as caracterı́sticas da plataforma Java Micro Edition

3.1 Visão geral

Figura 3.1: Elementos da plataforma Java ME.

Na camada de configuração são definidas as bibliotecas necessárias para o funciona-

• CDC é destinada a dispositivos com maior capacidade de memória e processamento,

Dentro da configuração existe uma outra classificação, os perfis. Estes formam um

Figura 3.2: Arquitetura da plataforma Java.

e abrange os dispositivos com grandes restrições de processamento, memória e vı́deo, como

• java.io - Tratamento de entrada e saı́da de dados usando streams (abstração).

• java.lang - Classes básicas da linguagem Java.

• java.util - Classes de utilidades genéricas (estruturas de dados e manipulação de

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

• Ponto flutuante - Possibilita operações com variáveis do tipo float/double.