desenvolvendo um estudo de caso utilizando a plataforma java me
DESCRIPTION
Trabalho de Conclusão de CursoTRANSCRIPT
Coordenacao do Curso de Ciencia da Computacao
Universidade Estadual de Mato Grosso do Sul
Desenvolvendo um Estudo de Caso
Utilizando a Plataforma Java ME
Lais Claudia ZanfolimRodolfo Chaves Fernandes
Andre Chastel Lima (Orientador)Celso G. Camilo Jr (Co-orientador)
Dezembro de 2009
Desenvolvendo um Estudo de CasoUtilizando a Plataforma Java ME
Lais Claudia ZanfolimRodolfo Chaves Fernandes
Este exemplar corresponde a redacao final
da monografia da disciplina Projeto Final de
Curso devidamente corrigida e defendida por
Lais Claudia Zanfolim
Rodolfo Chaves Fernandes e aprovada pela
Banca Examinadora, como parte dos requisi-
tos para a obtencao do tıtulo de Bacharel em
Ciencia da Computacao.
Dourados, 11 de dezembro de 2009.
Andre Chastel Lima (Orientador)
Celso G. Camilo Jr (Co-orientador)
ii
Coordenacao do Curso de Ciencia da Computacao
Universidade Estadual de Mato Grosso do Sul
Desenvolvendo um Estudo de Caso
Utilizando a Plataforma Java ME
Lais Claudia ZanfolimRodolfo Chaves Fernandes
Dezembro de 2009
Banca Examinadora:
• Andre Chastel Lima (Orientador)
• Celso G. Camilo Jr (Co-orientador)
• Raquel Marcia Muller
• Nielsen Cassiano Simoes
iii
Resumo
A plataforma Java Micro Edition e o conjunto de tecnologias que permitem o de-
senvolvimento de aplicacoes Java para dispositivos com processamento, memoria e vıdeo
limitados, como celulares e smartphones. Assim como as outras edicoes Java, essa pla-
taforma foi desenvolvida com o mesmo intuito, a portabilidade, alem de possuir diversas
APIs para o desenvolvimento, o Java ME tambem fornece compatibilidade entre as edi-
coes Java, possibilitando a comunicacao com aplicacoes construıdas em Java SE e Java
EE. Mantendo o foco em Java Micro Edition, este trabalho propoe o desenvolvimento de
uma aplicacao movel que una as tecnologias Java ME e Java EE. Como o Java Enterprise
Edition possui varias funcionalidades de redes e Internet e contem classes especialmente
desenvolvidas para acesso a servidores e banco de dados, parte da aplicacao foi construıda
usando esta tecnologia, possibilitando a comunicacao entre dispositivos moveis e um servi-
dor disposto na rede local ou Internet. Portanto, neste trabalho foi abordado, juntamente
com a plataforma Java ME, o uso de Servlets dentro da arquitetura Java EE, interagindo
com um cliente movel atraves do protocolo HTTP para estabelecer a comunicacao com
celulares e smartphones. Visto que um Servlet pode efetuar qualquer processamento ine-
rente a uma classe Java e enviar respostas na forma de documentos XML, para efetuarmos
a troca de dados entre um dispositivo movel e o servidor remoto de dados, que alimenta o
sistema movel, utilizamos os recursos que a linguagem XML nos oferece. Para auxiliar o
desenvolvimento do estudo de caso, a metodologia agil extreme programming foi utilizada
juntamente com diagramas da UML com o intuito de organizar o processo de desenvolvi-
mento. A aplicacao desenvolvida durante o trabalho e responsavel por agilizar o processo
de vendas de uma distibuidora de bebidas, a fim de automatizar a forca de vendas e foi
testada em celulares e smartphones com o sistema operacional movel Symbian e Windows
Mobile, interagindo com o servidor via requisicoes HTTP.
Palavras Chave: Java ME, mobilidade, celulares e smartphones.
iv
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 abencoado durante toda nossa vida
e principalmente por ter nos dado forcas durante todo o decorrer do trabalho.
Aos nossos familiares, pela confianca, apoio e educacao durante toda nossa caminhada.
Ao nosso orientador Andre Chastel Lima, pelo apoio e compreensao.
Ao nosso co-orientador Celso Camilo, pelo incentivo e paciencia.
A toda academia, que nos proporcionou as condicoes necessarias para o desenvolvi-
mento deste trabalho, em especial os professores Odival Faccenda e Glaucia Gabriel Sass.
Aos funcionarios da eXclaim, por nos dar a oportunidade de estagiar na empresa e
desenvolver projetos com a tecnologia Java ME.
Aos leitores e colaboradores do javamovel.com, pela lealdade e por nos incentivar a
estudar o tema do projeto.
Enfim, agradecemos todos aqueles que contribuıram para o sucesso desta caminhada
e que de forma injusta nao tiveram seus nomes incluıdos aqui.
vi
Sumario
Resumo iv
Abstract v
Agradecimentos vi
1 Introducao 3
1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Sistemas operacionais para dispositivos moveis 6
2.1 Dispositivos Moveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Sistemas Operacionais e suas tecnologias . . . . . . . . . . . . . . . . . . . 7
2.2.1 Symbian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.3 Windows Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.4 Palm OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.5 BlackBerry OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.6 Iphone OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Analise do Mercado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3 Java Micro Edition 11
3.1 Visao geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Configuracoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Perfis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Maquinas Virtuais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5 Pacotes Opcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
vii
4 Perfil MIDP 17
4.1 Visao 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 Comunicacao com o Servidor 35
6.1 A Plataforma Java EE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.1.1 Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.2 XML - Linguaguem de marcacao extensıvel . . . . . . . . . . . . . . . . . . 38
6.2.1 Analise de documentos XML . . . . . . . . . . . . . . . . . . . . . . 39
7 Estudo de Caso 41
7.1 Extreme programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.2 Arquitetura do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.3 Visao geral do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.4 Diagrama de Caso de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.5 Estorias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.6 Release 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.6.1 Iteracao A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.6.2 Iteracao B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.7 Release 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.7.1 Iteracao A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.7.2 Iteracao B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.8 A Aplicacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
8 Consideracoes 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 comunicacao. . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.2 Diagrama de Caso de Uso. . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.3 Estoria 1-A: Consulta de produtos. . . . . . . . . . . . . . . . . . . . . . . 44
7.4 Estoria 1-B: Consulta e cadastro de clientes. . . . . . . . . . . . . . . . . . 44
7.5 Estoria 2-A: Cadastro de pedidos. . . . . . . . . . . . . . . . . . . . . . . . 45
7.6 Estoria 2-B: Alteracao de pedidos. . . . . . . . . . . . . . . . . . . . . . . . 45
7.7 Estoria 2-C: Envio dos dados para o banco central da empresa. . . . . . . . 46
7.8 Diagrama de classe de projeto - Produto. . . . . . . . . . . . . . . . . . . . 47
7.9 Diagrama de classe de projeto - Cliente. . . . . . . . . . . . . . . . . . . . 47
7.10 Diagrama de classes de projeto. . . . . . . . . . . . . . . . . . . . . . . . . 48
7.11 Autenticacao do usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.12 Menu principal da aplicacao movel. . . . . . . . . . . . . . . . . . . . . . . 51
7.13 Cadastro de Clientes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.14 Busca de Produtos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 (Servico 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
Introducao
Com a expansao da Internet e da utilizacao de aplicacoes, surgiram diversas linguagens
de programacao, tendo destaque as de multiplataforma, como e o caso do Java, que pode
ser aplicado em diversos setores, como aparelhos eletronicos, telefones celulares, aplicacoes
para Web e desktop, entre outros. Levando em consideracao os diferentes setores, tornou-
se necessario a criacao de kits de desenvolvimento diferenciados.
A proposta inicial parte do interesse pela linguagem de programacao Java, em espe-
cıfico Java Micro Edition - Java ME. E uma plataforma que permite o desenvolvimento
de aplicacoes Java para dispositivos com processamento, memoria e vıdeo limitados, tais
como celulares e smartphones. Assim como as outras edicoes Java, essa tecnologia foi
desenvolvida com o mesmo intuito, a portabilidade, alem de possuir diversas APIs (Ap-
plication Programming Interface) para o desenvolvimento. O Java ME tambem fornece
compatibilidade entre as edicoes Java, possibilitando a comunicacao com aplicacoes 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 aplicacoes embarcadas.
Dentro desta ultima configuracao existe uma outra classificacao que define os perfis dos
dispositivos. No caso de celulares e smartphones a classificacao usada e o MIDP, Mobile
Information Device Profile. Dentro desta classificacao, se ocorrer a migracao de aplicacoes
para outros celulares com a mesma configuracao elas nao perdem sua funcionalidade
(TOPLEY, 2002).
Para otimizar o funcionamento de aplicacoes em celulares a Sun desenvolveu maquinas
virtuais Java especıficas para cada configuracao, que manipulam de maneira mais eficiente
3
1.1. Objetivos 4
a codificacao desse tipo de dispositivos.
Com a criacao deste ambiente de desenvolvimento torna-se viavel a construcao de
aplicacoes para dispositivos moveis com maior produtividade e portabilidade (MUCHOW,
2001).
1.1 Objetivos
O objetivo principal deste trabalho e desenvolver um estudo de caso aplicando os prin-
cipais conceitos da plataforma Java ME e utilizar a plataforma Java EE para construcao
de um servidor que sera responsavel pela troca de dados com a aplicacao movel.
Para alcancar o objetivo principal, as seguintes etapas foram efetuadas:
• Fazer um breve estudo sobre as plataformas de dispositivos moveis;
• Estudar a plataforma Java ME, voltada para dispositivos moveis;
• Estudar a plataforma Java EE para a construcao de um servidor remoto;
• Estudar a comunicacao entre o servidor e a aplicacao movel;
• Estudar alguns frameworks Java ME e definir quais serao utilizados no estudo de
caso;
• Definir os padroes da Engenharia de Software que serao utilizados na aplicacao;
• Definir o estudo de caso;
• Desenvolver e testar o estudo de caso.
1.2 Justificativa
Segundo dados divulgados pela Agencia Nacional de Telecomunicacoes (Anatel), o
numero de linhas de telefones moveis no paıs chegou a aproximadamente 152,4 milhoes,
em fevereiro de 2009, o que corresponde a 79,94% da populacao (AGENCIAESTADO,
2009).
Em nıvel mundial, o numero de usuarios de telefones moveis chegou perto de 3 bilhoes
em 2007, atingindo 48% da populacao e a estimativa para o final de 2008 era de 4 bilhoes,
o que corresponde a 61%, segundo a Uniao Internacional de Telecomunicacoes (UIT)
(REUTERS, 2008).
Segundo Eric Klein, vice-presidente de marketing do Java, em entrevista a Reuters, o
Java esta instalado em 2,6 bilhoes de telefones em todo o mundo (VIRKI, 2009). Visto
1.3. Metodologia 5
que o numero de usuarios de aparelhos celulares e significativo, que esta em crescimento e
que a plataforma Java ME e bem aceita pelo mercado de software para dispositivos moveis
e tambem esta em ascendencia no mercado, o desenvolvimento para esta plataforma se
torna bastante atraente.
1.3 Metodologia
Mantendo o foco em Java Micro Edition, propomos fazer uma revisao bibliografica dos
conceitos chaves desta plataforma e desenvolver uma aplicacao para celular ou smartphone
que una as plataformas Java ME e Java EE. Como o Java Enterprise Edition possui varias
funcionalidades de redes e Internet e contem bibliotecas especialmente desenvolvidas para
acesso a servidores e banco de dados, parte da aplicacao sera construıda usando esta
plataforma, possibilitando a comunicacao entre dispositivos moveis e um servidor disposto
na rede ou Internet.
A plataforma Java EE contem uma serie de especificacoes, cada uma com funciona-
lidades distintas, entre elas, utilizamos servlets, utilizados para o desenvolvimento Web
com conteudo dinamico e contem 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 viaveis para o desenvolvimento da aplicacao 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 aplicacao movel.
O estudo de caso foi desenvolvido com base na metodologia agil extreme programming
- (XP), e diagramas da UML serao apresentados para o melhor entendimento da aplicacao.
Os testes foram realizados em celulares e smartphones com o sistema operacional
Symbian e Windows Mobile com a configuracao CLDC 1.1 e perfil MIDP 2.1, porem a
aplicacao podera ser executada em outros sistemas operacionais moveis que possuam uma
maquina virtual Java compatıvel com estas caracterısticas.
Capıtulo 2
Sistemas operacionais para
dispositivos moveis
A tecnologia da informacao atinge a maior parte das empresas e instituicoes de forma
que fiquem dependentes de sistemas que ajudam ou otimizam o trabalho e a comunicacao
dentro das mesmas. Com a massificacao de computadores e Internet surge um outro
conceito: Mobilidade. O poder de carregar as informacoes para qualquer ambiente e
evidentemente util para empresas que trabalham com base de dados e um fator essencial
para se destacar no mercado e ter acesso as informacoes em tempo real.
Sendo evidente o impacto que solucoes de softwares moveis tem e terao nos proximos
anos, e de extrema importancia conhecer os sistemas operacionais moveis do mercado
e quais tipos de aplicacoes cada um deles suporta. Assim, e apresentada uma breve
analise dos principais sistemas operacionais para dispositivos moveis mais importantes da
atualidade.
Neste capıtulo tambem sao explanados os principais tipos de dispositivos moveis e suas
tecnologias, visando uma abordagem completa dos requisitos necessarios para construir
aplicativos de sucesso.
2.1 Dispositivos Moveis
Primeiramente e importante esclarecer que o termo Palm e utilizado para PDAs (As-
sistente Pessoal Digital) ou Handhelds, que sao computadores de mao que fornecem as
funcoes basicas de um computador pessoal, como acesso a Internet, programas de cadas-
tros, agenda, controle financeiro, controle de vendas, planilhas, documentos entre outras
aplicacoes da categoria (PALMBRASIL, 2009a).
O smartphone e uma categoria de telefone celular com 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, integracao
com GPS (Global Positioning System), enfim, tecnologias que o tornam mais robusto
(MICROSOFT, 2009b).
2.2 Sistemas Operacionais e suas tecnologias
Nesta secao abordaremos as principais caracterısticas dos sistemas operacionais moveis
mais utilizados no mercado, bem como suas tecnologias.
2.2.1 Symbian
Comecaremos entao com o sistema operacional para telefones moveis que desde 1998
lidera o mercado mundial, o Symbian OS, ou simplesmente Symbian. Ele possui suporte
MMS (Multimedia Messaging Service), bluetooh, wireless, infra-vermelho, entre outras
funcoes que tornam-se extremamente importantes quando o assunto e mobilidade. Este
SO possui um sistema grafico bem simples e atualmente e o sistema mais usado pelos
maiores fabricantes de telefones moveis do mundo, porem com o surgimento de novas
tecnologias e plataformas, vem apresentando queda. Por ser um sistema operacional
que controla muito bem o consumo de memoria, o consumo de energia, o processamento,
entre outros fatores essenciais, as empresas mais poderosas da telecomunicacao investiram
bastante para que este fosse um sistema promissor para o mercado.
Empresas como Nokia, Samsung, Panasonic, Ericsson e Sony Ericsson, foram as res-
ponsaveis pela ascendencia desse modelo de sistema operacional movel. Segundo a INFO
(2008), atualmente a Nokia possui a totalidade das acoes da empresa britanica de software
(Symbian), liderando o mercado mundial com 38,9% de participacao e promete concorrer
com o mais novo sistema operacional para dispositivos moveis - Android.
O Symbian suporta sistemas divididos em modulos, desta forma cada empresa pode
criar sua propria interface. Permite o uso de varias linguagens de programacao, entre
as mais importantes estao: Symbian C/C++, Java ME, FlashLite, Perl, Python, Ruby,
entre outras. Assim se o aparelho nao possui certa funcionalidade, fica facil de integrar a
mesma (SYMBIANBRASIL, 2009).
2.2.2 Android
O Android e um sistema operacional baseado em Linux voltado para smartphones,
criado pela Google em consorcio com mais de 40 empresas. Utiliza uma maquina virtual
que foi projetada para otimizar a memoria e os recursos de hardware em um ambiente
2.2. Sistemas Operacionais e suas tecnologias 8
movel. E a primeira plataforma open source para desenvolvimento de aplicacoes moveis,
portanto e livre para incorporar novas tecnologias. Por ser um SO mais novo no mercado
esta em aceitacao, positiva por sinal, pelos usuarios e desenvolvedores, pois agrega todas
as funcionalidades que os aparelhos moveis mais atuais fornecem. E importante ressaltar
que os servicos da Google passam a ser facilmente acoplados com as tecnologias moveis
apos o surgimento do Android, ja que o interesse e os investimentos atuais da empresa
visam a mobilidade.
Entre os servicos oferecidos estao: Cliente de e-mail, programa para SMS (Short Mes-
sage Service), calendario, mapas, navegador e gerenciador de contatos. Tudo 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.
Alem dos aplicativos feitos em Java, o Android possui um conjunto de bibliotecas
C/C++ usadas por diversos componentes que permitem trabalhar com arquivos de mıdia,
exibicao de conteudo em 2D e 3D, inclusive bibliotecas implementadas utilizando OpenGL
(Open Graphics Library) e um poderoso banco de dados relacional, o SQLite (Developers,
2009).
2.2.3 Windows Mobile
Windows Mobile e um sistema operacional para dispositivos moveis, projetado para
realizar boa parte das funcoes existentes no Windows para PC. Ele pode ser instalado
em PDAs, PocketPC, smartphones e aparelhos de 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, alem de versoes moveis
dos aplicativos da Microsoft Office, como: Word, Excel e Power Point. O SO suporta
aplicativos desenvolvidos em linguagens como C, C#, VB.Net, Java ME, Visual Basic,
Python, FlashLite, entre outras, alem de possuir um interpretador para PHP (MICRO-
SOFT, 2009a).
2.2.4 Palm OS
Palm OS e um sistema operacional desenvolvido pela PalmSource para rodar em PDAs.
Entre as versoes da linha temos: O Palm OS Garnet e, o atualmente mais usado, Palm
OS Cobalt.
No Palm OS Cobalt o sistema roda em 32 bits, possibilitando que os aplicativos fiquem
muito mais rapidos e com recursos extras. No Palm OS Garnet (5.x) apenas algumas
partes dos aplicativos sao em 32 bits, ja que maior parte simula processadores antigos da
2.2. Sistemas Operacionais e suas tecnologias 9
Motorola. A desvantagem e que as aplicacoes criadas utilizando os novos recursos nao
irao funcionar em equipamentos com versoes anteriores do sistema.
As linguagens mais utilizadas para o desenvolvimento de aplicacoes no Palm OS e
o Pascal e o C/C++. Vale ressaltar que a ultima possui uma grande quantidade de
frameworks e e mais usada no desenvolvimento de jogos. Importante dizer que existem
aplicativos que convertem aplicacoes em Java para que possam ser utilizadas em Palm
OS, uma otima saıda para escapar do padrao de desenvolvimento em palms. Existem
ainda outras linguagens para Palm OS, mas que nao possuem tantos recursos, tais como:
Satellite Forms, Codewarrior, AppForge, NSBasic, CASL e PDAToolBox.
Existem ferramentas RAD (Rapid Application Development) muito bem documenta-
das para auxiliar no desenvolvimento em Palm OS, e o caso da Handheld Basic (HB++),
que e muito bem aceita pela comunidade de desenvolvedores . O PocketStudio e outra
ferramenta de desenvolvimento do tipo RAD, semelhante ao Delphi, que ajuda muitos
desenvolvedores a construir aplicacoes com maior facilidade para o Palm OS. Atualmente
essas sao as mais usadas no desenvolvimento de aplicacoes comerciais para palms.
Apos a PalmSource ser comprada pela Access as proximas versoes devem ser baseadas
no sistema operacional Linux. Atualmente os dispositivos palms estao sendo comerciali-
zados tambem com Windows Mobile justamente pelas restricoes para o desenvolvimento
no sistema operacional Palm OS (PALMBRASIL, 2009b).
2.2.5 BlackBerry OS
O BlackBerry OS e o sistema operacional para smartphones BlackBerry da empresa
Canadense RIM (Research in Motion). O SO possui como ponto sobressalente a sua
consagrada ferramenta de sincronizacao de e-mails. Assim que o servidor recebe o e-mail
este e enviado para o dispositivo. Inicialmente deixava a desejar no quesito design, porem
passa por constantes aprimoramentos neste quesito e em outros recursos. Suas versoes
mais atuais apresentam recursos como menus recolhıveis, navegacao por fotos, gerenciador
de arquivos dedicado e oferece suporte para aplicativos desenvolvidos em Java ME (RIM,
2009).
E o terceiro sistema operacional para dispositivos moveis mais vendido do mundo e o
segundo dos Estados Unidos. Teve um crescimento muito rapido, chegando a ser o mais
vendido nos Estados Unidos no primeiro trimestre de 2009 (ADMOB, 2009).
2.2.6 Iphone OS
O Iphone OS e o sistema operacional proprietario do Iphone, desenvolvido pela Apple.
Atualmente conhecido como Mac OS X Snow Leopard, semelhante ao sistema OS X que
roda nos computadores Macintosh. Este SO introduziu diversas tecnologias de primeira
2.3. Analise do Mercado 10
linha com uso de 64 bits, proporcionando a mais rapida implementacao de javascript e
acesso a Web, chegando a ser 53 vezes mais rapido quando usa o mini navegador Safari.
Outra poderosa tecnologia implementada e o OpenCL(Open Computing Language) que
possibilita aos desenvolvedores maior otimizacao em aplicacoes que usam recursos grafi-
cos. Possui uma tecnologia de multicondutores que agiliza a distribuicao de tarefas em
multiplos processadores (APPLE, 2009a).
Em comparacao ao Android por exemplo, e notavel que o sistema operacional do
Iphone e muito superior em qualidade e eficiencia, ainda mais se compararmos o acesso a
Web, pois o Iphone ja conquista e domina o mercado e nao deixa a desejar em nenhum
aspecto, com excecao do custo. A linguagem de desenvolvimento para o iPhone e o
Objective-C, que e muito utilizada na plataforma MAC. Ela e orientada a objetos e
difere do C no acrescimo de transmissao de mensagens, ao estilo da linguagem Smalltalk.
Tambem existem iniciativas Open Source para converter codigos em Python para C ou
tambem de Java para Objective-C.
Para desenvolver aplicativos para o Iphone OS e necessario utilizar o Cocoa, um con-
junto de frameworks orientado a objetos que disponibiliza um ambiente de execucao para
as aplicacoes serem executadas em MAC OSX e Iphone OS. E o unico ambiente de apli-
cacao para Iphone OS. As aplicacoes existentes no MAC OSX e no Iphone OS sao Cocoa,
portanto para desenvolver aplicacoes Java para o sistema operacional do Iphone e neces-
sario usar ferramentas que convertem o codigo Java para a implementacao da biblioteca
Cocoa. Tambem existem frameworks para converter Python, Ruby, Perl, C# e Objective-
Basic em Objective-C, utilizando o Cocoa (APPLE, 2009b).
2.3 Analise do Mercado
As plataformas da Apple, Google e Palm sao, hoje, as que mais se destacam no mer-
cado mundial. Segundo JONES (2009), analista de mobilidade e tecnologias sem fio do
Gatener, a Microsoft esta lutando para sobreviver no celular, pois se voltou demais para
o mercado corporativo e deixou de lado o mercado domestico, ficando fraca diante do
iPhone, Symbian e Android.
Apenas tres plataformas devem sobreviver, mas e difıcil dizer hoje exatamente quais
sao. ”E uma batalha de ecossistemas que dependem de fatores como recursos do equi-
pamento, estilo, preco e oferta de aplicativos e nao so da plataforma em si.” (JONES,
2009).
Capıtulo 3
Java Micro Edition
Neste capıtulo sao apresentadas as caracterısticas da plataforma Java Micro Edition
(Java ME), bem como suas tecnologias e arquitetura.
3.1 Visao geral
Segundo a SUN (2009b), o Java ME e uma colecao de tecnologias e especificacoes que criam
uma plataforma que se ajusta aos requisitos de dispositivos moveis tais como produtos de
consumo, dispositivos embarcados e dispositivos moveis avancados.
O Java ME e a plataforma Java voltada para dispositivos que possuam capacidade de
memoria, tela e processamento restritos. Foi construıda com o objetivo de fornecer um
ambiente de execucao 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 tres elementos, especificados pela comunidade JCP, que define todos requisitos da
plataforma Java, incluindo a especificacao de APIs. Os tres elementos citados sao: Con-
figuracoes, perfis e pacotes opcionais, os quais funcionam sobre uma maquina virtual
Java, por sua vez ligada a um sistema operacional. Dessa forma podemos representar a
hierarquia dos elementos nas camadas apresentadas na Figura 3.1.
11
3.1. Visao geral 12
Figura 3.1: Elementos da plataforma Java ME.
Na camada de configuracao sao definidas as bibliotecas necessarias para o funciona-
mento da maquina virtual. A JCP especificou o Java ME em duas configuracoes de acordo
com as necessidades dos dispositivos: CLDC (Connected, Limited Device Configuration)
e CDC (Connected Device Configuration), de forma que:
• CLDC especifica o ambiente Java para dispositivos com capacidades mais restritas,
como telefones celulares, PDAs e smartphones.
• CDC e destinada a dispositivos com maior capacidade de memoria e processamento,
como TV digital, dispositivos sem fio de alto nıvel e sistemas automotivos.
Dentro da configuracao existe uma outra classificacao, os perfis. Estes formam um
conjunto de aplicacoes que complementa uma configuracao e fornece funcionalidades para
desenvolver um aplicativo para determinado dispositivo.
O perfil associado a CLDC e o MIDP (Mobile Information Device Profile). E os asso-
ciados a CDC sao: FP (Foundation Profile), PP (Personal Profile), PBP (Personal Basis
Profile), RMIP (Remote Method Invocation Profile) e GP (Game Profile) (JOHNSON,
2007).
Os principais pacotes opcionais estao inseridos em um conjunto de APIs utilizadas com
as configuracoes e perfis para estender funcionalidades nao encontradas nos respectivos
pacotes, como APIs para bluetooh e wireless.
Quanto a maquina virtual, a JCP especifica a CDC HotSpot Implementaion e a CLDC
HotSpot Implementation, que substituıram respectivamente a CVM (Compact Virtual
Machine), vinculada a configuracao CDC e a KVM (Kilo Virtual Machine), vinculada a
CLDC. A Figura 3.2 mostra a arquitetura da plataforma Java.
3.2. Configuracoes 13
Figura 3.2: Arquitetura da plataforma Java.
3.2 Configuracoes
A configuracao define uma especificacao padrao para uma mesma classe de dispositivos,
definidos por caracterısticas individuais de hardware, como interface, processamento, me-
moria, vıdeo, tipo de conexao de rede, entre outras (TOPLEY, 2002). Esta camada possui
as bibliotecas basicas da linguagem, representando a plataforma mınima de desenvolvi-
mento para cada tipo de dispositivo. Tais configuracoes sao definidas pelos fabricantes a
fim de proporcionar um ambiente de desenvolvimento para funcionar em um determinado
dispositivo.
Cada configuracao consiste de uma maquina virtual Java (Java Virtual Machine -
JVM), seja da Sun, do proprio fabricante, ou de terceiros e de uma colecao de classes
Java. Devido as restricoes de hardware dos dispositivos moveis, as maquinas virtuais
utilizadas na plataforma Java ME nao suportam todas as caracterısticas da linguagem
Java, instrucoes bytecodes e softwares de otimizacao providenciados pela plataforma Java
SE nao sao suportados, sendo assim diferentes das demais JVMs (TOPLEY, 2002).
A JCP especificou duas configuracoes para Java ME, CLDC e CDC. Dentre elas abor-
daremos a configuracao CLDC, visto que esta aborda celulares e smartphones, cujo e o
objetivo deste trabalho.
A Connected, Limited Device Configuration - CLDC e a configuracao mınima do Java
ME, formada por um subconjunto de pacotes disponıveis na plataforma Java para desktop
3.2. Configuracoes 14
e abrange os dispositivos com grandes restricoes de processamento, memoria e vıdeo, como
celulares, smartphones, pagers e PDAs.
Os dispositivos desta configuracao tem pelo menos 16 ou 32 bits, 160k de memoria
nao volatil (onde sao armazenadas as bibliotecas e a maquina virtual), fonte limitada de
energia e pelo menos 16 Mhz de velocidade. Alem disso e necessario 192k de memoria
para a plataforma Java e suportar conexao com rede sem fio, porem com capacidade de
transmissao limitada (JOHNSON, 2007).
A CLDC esta disponıvel nas versoes 1.0 (JSR 30) e 1.1 (JSR 139) (SUN, 2006e). A
principal caracterıstica da versao 1.0 e a ausencia de operacoes que use ponto flutuante,
porem ja existem classes que simulam esta propriedade para dada configuracao (CLAU-
SEN, 2003).
Segundo a SUN (2007), as classes desta configuracao estao restritas a apenas quatro
pacotes:
• java.io - Tratamento de entrada e saıda de dados usando streams (abstracao).
• java.lang - Classes basicas da linguagem Java.
• java.util - Classes de utilidades genericas (estruturas de dados e manipulacao de
dados).
• java.microedition.io - Exclusivamente da plataforma Java ME, incluindo as classes
de conexao.
A CLDC 1.1 e uma configuracao que engloba os pacotes da versao 1.0 e suporta as
seguintes caracterısticas:
• Ponto flutuante - Possibilita operacoes com variaveis do tipo float/double.
• ClassLoading - Classe abstrata responsavel por carregar outras classes.
• Garbage Collector - Coletor de lixo dos objetos.
• Finalize() - Com esse metodo e possıvel liberar recursos e executar outras operacoes
de limpeza antes que o objeto seja recuperado por coleta de lixo (garbage collector).
• JNI (Java Native Interface) - Classe de interface nativa que possibilita a maquina
virtual acessar bibliotecas acessadas com o codigo nativo de um sistema.
• ThreadGroups - Possibilita que os processos sejam executados simultaneamente,
possibilitando a organizacao das threads em grupos. A multiThreading suporta
multiplas linhas de execucao atraves das funcoes start(), interrupt(), pause(), re-
sume() e stop() para o controle das threads.
3.3. Perfis 15
• RMI (Remote Method Invocation) - Permite o acesso a objetos remotos que podem
ser invocados de diferentes maquinas Java.
3.3 Perfis
Perfil e definido como um conjunto de APIs que especificam o nıvel de interface de
aplicacoes para um classe de dispositivos (JCP, 2009c). Assim um perfil pode especificar
varios tipos de servicos e funcionalidades de alto nıvel, como o ciclo de vida da aplicacao,
elementos de interface grafica, persistencia de dados e meios de comunicacao. Um perfil e
implementado no topo de uma configuracao, sendo assim intimamente ligado a esta, po-
rem compreende bibliotecas mais especıficas que as disponibilizadas pelas configuracoes,
ou seja, o perfil complementa a configuracao adicionando classes que fornecem caracte-
rısticas apropriadas para um tipo particular de dispositivos. Tanto os perfis quanto as
configuracoes sao especificacoes de baixo nıvel.
As aplicacoes moveis sao portanto construıdas sobre configuracoes e perfis e podem
apenas usar bibliotecas especificadas por estas. Uma configuracao pode conter varios
perfis, porem um perfil e ligado somente a uma configuracao. E um perfil ainda pode ter
outros perfis ligados a ele (TOPLEY, 2002).
Para a configuracao CLDC temos o perfil MIDP (Mobile Information Device Profile
- JSR 37 ), que e amplamente utilizado e providencia o desenvolvimento para pequenos
dispositivos, de recursos limitados e com capacidade de conexao sem fio, como os celulares,
smartphones e alguns PDAs. No proximo capıtulo serao abordados mais detalhes sobre o
perfil MIDP.
3.4 Maquinas Virtuais
A Sun especifica duas maquinas virtuais para a configuracao CLDC: KVM e CLDC
HotSpot Implementation.
• KVM
E uma maquina virtual com funcoes reduzidas, com uma pequena memoria e com
um coletor de lixo (garbage collector) incorporado para a otimizacao da memoria
(TOPLEY, 2002). Esta e uma VM (Virtual Machine) especificada pela SUN, que
implementa as necessidades e restricoes impostas pela configuracao CLDC. O K do
termo KVM surgiu para fazer alusao aos poucos kilobytes necessarios para que a
VM execute uma aplicacao. Ela nao compila o codigo e sim o interpreta para o
sistema operacional.
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 memoria restrita que os pequenos
dispositivos oferecem. Esta maquina virtual suporta CLDC 1.0 e 1.1, porem agora
exige do processador pelo menos 32 bits com uma velocidade de clock de 60 MHz,
600KB de memoria RAM e 2 MB de memoria flash e ROM. Aplica tecnologias
utilizadas na plataforma Java SE e Java EE, incorpora diversos designs inovadores,
diminui o tempo de inıcio das aplicacoes, oferece vida longa a bateria e possui
compilacao dinamica das instrucoes de bytecode em instrucoes nativas, chamada de
compilacao Just-in-time (SUN, 2008a).
Segundo LUZ (2009), a compilacao Just-in-time e uma das mudancas mais impor-
tantes, pois a compilacao dinamica pode ser cinquenta vezes mais rapida que uma
instrucao interpretada.
3.5 Pacotes Opcionais
Pacotes opcionais sao componentes muito importantes da plataforma Java ME. Po-
demos enxergar como extensoes de perfis, alem de oferecerem apoio em areas com fun-
cionalidades restritas que alguns dispositivos e aplicacoes precisam, tais como troca de
mensagens, multimıdia, servicos e localizacao geografica.
Os perfis podem concentrar-se em apoiar apenas as capacidades que a maioria ou
todos os dispositivos em uma classe necessitam, enquanto pacotes opcionais fornecem
tipos especıficos de funcionalidades. Todos os pacotes opcionais do Java ME sao definidos
pela JCP, estes pacotes tambem sao chamados de APIs. Podendo ser obrigatorios ou
nao, tal decisao cabe aos desenvolvedores ou fabricantes incluı-los em um determinado
produto.
Os pacotes opcionais passam por um processo de aprovacao atraves da MSA (Mobile
Service Architecture) apos serem construıdos pelos desenvolvedores. Depois de aprovados
sao disponibilizados seguindo as especificacoes da JCP. Alguns exemplos de pacotes opcio-
nais sao: API para suporte bluetooth (JSR 82), API para acesso as funcionalidades nativas
do aparelho como agenda, calendario e acesso a arquivos (JSR 75 - File Connection API ),
API de seguranca e servicos confiaveis (JSR 177), entre outras (SUN, 2009a).
Capıtulo 4
Perfil MIDP
Neste capıtulo sao apresentadas as caracterısticas do perfil MIDP, bem como o fun-
cionamento de uma aplicacao. Serao apresentados os principais conceitos relacionados a
interface e armazenamento persistente.
4.1 Visao Geral do MIDP
O MIDP - Mobile Information Device Profile e um perfil suportado pela configuracao
CDLC, onde juntos providenciam um ambiente padrao de execucao Java para os mais
populares dispositivos moveis, como os celulares e PDAs. Este perfil prove um conjunto de
bibliotecas e classes que fornecem suporte ao desenvolvimento de aplicacoes que referem-
se a diferentes aspectos, como sistema de armazenamento persistente, interface com o
usuario, transacoes seguras, gerencia de sons, entre outros.
De acordo com JOHNSON (2007), o MIDP apresenta diversas funcionalidades, entre
elas estao a reproducao de multimıdia, suporte a protocolos dos tipos HTTP e sockets,
suporte ao sistema de cores RGB, definicao de formularios e itens, APIs para jogos e
validacao de permissoes de seguranca e assinaturas digitais.
Segundo a SUN (2006e), os recursos mınimos de hardware do perfil MIDP sao:
• 130KB de memoria nao volatil para persistencia de dados e bibliotecas da CLDC
• 32KB de memoria volatil para a execucao do Java
• Conectividade com algum tipo de rede sem fio
• Interface grafica
• Uma tela de pelo menos 96 pixels de largura por 54 de altura
17
4.1. Visao Geral do MIDP 18
Alguns recursos mınimos de software tambem sao requeridos, tais como: possuir re-
cursos suficientes para executar a maquina virtual Java, tratamento de excecoes, pro-
cessamento de interrupcoes, acesso de leitura e escrita a rede sem fio, mecanismos para
capturar a entrada de dispositivos de entrada, recursos para ler e gravar em memoria nao
volatil, oferecendo suporte persistente aos dados e escrita de elementos graficos na tela
(JOHNSON, 2007).
As especificacoes deste perfil sao definidas pela JCP, definindo uma plataforma para
desenvolvimento seguro e dinamico. Atualmente o MIDP possui as versoes 1.0 (JSR
37), 2.0 (JSR 118), 2.1 (JSR 118) e 3.0 (JSR 271). Porem esta ultima ainda nao esta
disponıvel para utilizacao. A versao 1.0 trabalha integrada com a configuracao CLDC
1.0 ou 1.1. Nao tem nenhuma API ativa para renderizacao, nao oferece suporte para
acesso direto aos pixels de imagens, nao tem suporte para full screen/full canvas sem
uma API proprietaria e tambem nao possui suporte direto para audio. Inclui APIs para
o ciclo de vida de aplicacoes, conectividade de redes HTTP, interface com o usuario e
armazenamento persistente. O unico protocolo de rede que o MIDP 1.0 suporta e o
HTTP (SUN, 2002).
Segundo a SUN (2006c), os pacotes suportados pela versao 1.0 sao:
• javax.microedition.io - Fornece suporte ao framework GenericConnection da confi-
guracao CLDC.
• javax.microedition.lcdui - API que providencia um conjunto de caracterısticas para
a implementacao de interfaces com o usuario.
• javax.microedition.rms - Providencia um mecanismo de persistencia de dados para
MIDlets.
• javax.microedition.midlet - O pacote MIDlet define aplicacoes MIDP e interacoes
entre as aplicacoes e o ambiente no qual a aplicacao e executada.
A versao 2.0 e compatıvel com a versao 1.0 e adiciona novas melhorias como suporte
a conexao segura (HTTPS), biblioteca de multimıdia, formulario de entrada de dados
aprimorada, sensıvel melhoria na API de suporte a games, conceito de aplicacoes confiaveis
(trusted) e nao confiaveis (untrusted). Alem de HTTPS, o MIDP 2.0 suporta HTTP,
datagramas, sockets e SMS (Short Message Service). Quanto a multimıdia, um conjunto
de APIs foram introduzidas, que sao na verdade um subconjunto da Mobile Media API
(MMAPI). Com estas APIs podem ser gerados simples toques, sequencias mais completas
ou ate mesmo musicas completas no formato WAV, alem de poderem ser implementados
em outros formatos.
Dentre as mudancas nos formularios de entrada destacam-se a nova aparencia do Form
que e consideravelmente mais sofisticada do que era no MIDP 1.0 e a classe Item, onde
4.1. Visao Geral do MIDP 19
agora podem ser especificados layouts horizontais, verticais, novas linhas antes ou depois
de itens, entre outros. Um novo item tambem foi criado, o Spacer, que serve pra colocar
espacamentos entre os demais itens disponıveis. Tambem foi introduzido o tipo pop up ao
item choiceGroup, que sera estudado a frente.
No MIDP 2.0 tambem foram estendidos os comandos de manuseio. Adicionar co-
mandos aos itens agora e permitido. Tambem foi introduzida a classe CustomItem, que
permite ao programador criar seus proprios itens. Nesta versao o suporte a jogos ganha
uma melhoria com o suporte a camadas na tela. Uma camada pode conter um fundo, ou-
tra mostrar objetos, uma terceira camada poderia mostrar esfeitos especias ou qualquer
outra coisa. Outra mudanca e o surgimento da classe GameCanvas, uma subclasse de
Canvas - classe de baixo nıvel que proporciona o desenvolvimento de jogos. Nesta versao
as imagens podem ser representadas em arrays de inteiros e tambem suporta imagens em
RGB (SUN, 2002).
Segundo a SUN (2006d), os pacotes que foram adicionados a esta versao sao:
• javax.microedition.lcdui.game - Providencia classes para o desenvolvimento de con-
teudo rico para jogos em dispositivos wireless.
• javax.microedition.media - Compatıvel com as especificacoes 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 informacoes para conexoes seguras, atraves de
certificados.
A versao 2.1 do MIDP reforca a especificacao MIDP 2.0 tornando a diretiva layout LC-
DUI obrigatoria, os pacotes javax.microedition.io.SocketConnection e javax.microedition-
.io.HTTPConnection nao sao mais opcionais, entre outros requisitos para aprimorar a
versao 2.0.
A versao 3.0 traz melhor suporte para dispositivos com telas maiores, suporte a MI-
Dlets para desenhar em telas secundarias, armazenamento RMS seguro e acesso remoto a
bancos RMS (JCP, 2009a). Esta versao requer no mınimo 1MB de memoria volatil 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 versoes do MIDP. No MIDP 3.0 a tela de
splash pode ser carregada sem a necessidade de ser criada uma classe em canvas com uma
imagem e tempo controlado manualmente. Isto pode ser feito atraves de um atributo no
arquivo JAD, um arquivo de descricao da aplicacao, que sera explicado posteriormente.
Os protetores de tela agora sao aplicacoes que sao destruıdas pelo gerenciador quando
4.2. MIDlets 20
alguma tecla e pressionada ou algum evento e disparado. Alem destas funcionalidades,
o MIDP 3.0 apresenta suporte a IP versao 6, o que possibilita fazer parse de um ende-
reco IPv6 e a possibilidade de compartilhar bibliotecas entre os MIDlets em tempo de
execucao, conhecido como LIBlets (LUZ, 2009).
4.2 MIDlets
E uma aplicacao Java destinada para dispositivos moveis desenvolvida com a utilizacao
do perfil MIDP, que esta vinculado a configuracao CLDC (MUCHOW, 2001).
Todo dispositivo movel tem um gerenciador de aplicativos (AM - Application Mana-
ger) que controla os aplicativos a serem instalados, onde e como serao armazenados e
como serao executados. A comunicacao do gerenciador com o MIDlet acontece pela classe
MIDlet do pacote javax.microedition.midlet.MIDlet. Os MIDlets devem herdar esta classe
MIDlet que contem metodos que inicializam, resumem, interrompem a execucao e des-
troem MIDlets.
Uma aplicacao e iniciada quando o AM invoca o metodo startApp(), colocando a
aplicacao no modo ativo. Enquanto estiver executando ela pode ser pausada pela AM
atraves do metodo pauseApp(), isto pode ocorrer quando uma chamada for recebida por
exemplo ou o proprio usuario pode pausar a aplicacao. E quando a aplicacao e encerrada
ela passa para o estado destruıdo, atraves do metodo destroyApp(), que limpa todos os
recursos para fechar a aplicacao (JOHNSON, 2007).
O ciclo de vida do MIDlet e apresentado na Figura 4.1.
Figura 4.1: Ciclo de vida do MIDlet.
Estes tres metodos, segundo MUCHOW (2001), trata-se da comunicacao que parte
do gerenciador de aplicativos para o MIDlet. Alem destes metodos, tambem existem
outros tres onde a comunicacao parte do MIDlet para o gerenciador de aplicativos. Estes
metodos sao:
4.3. MIDlets Suite 21
notifyDestroy(): Avisa ao gerenciador que pode desligar a MIDlet.
notifyPaused(): Envia o pedido de pausa para o gerenciador caso a MIDlet queira
pausar.
resumeRequest(): Avisa ao gerenciador que a MIDlet pode tornar-se ativa novamente.
4.3 MIDlets Suite
MIDlet Suite consiste em um ou mais MIDlets que sao juntados em um Java Ar-
chive (JAR). E composto por classes Java, recursos e um arquivo de manifesto, que estao
situados dentro do arquivo JAR e um arquivo de descricao, chamado Java Application
Descriptor (JAD). Dentre os recursos estao imagens, dados da aplicacao, entre outros.
No arquivo de manifesto, cuja extensao e .mf, esta a descricao do JAR. E o arquivo JAD
descreve os detalhes da aplicacao, repetindo muitos do dados que estao no arquivo de
manifesto, porem este arquivo esta fora do JAR e pode ser acessado antes de se insta-
lar o arquivo JAR no aplicativo (JOHNSON, 2007). As proximas subsecoes descrevem
detalhadamente cada um desses arquivos.
4.3.1 JAR
Todas as MIDlets sao empacotadas antes de serem transferidas a um dispositivo, isso
e feito atraves de um metodo de compressao onde sao colocadas todas as informacoes em
um unico arquivo cuja extensao e .JAR. Este arquivo engloba classes Java, recursos e
informacoes do empacotamento, com citado anteriormente (MUCHOW, 2001).
O arquivo JAR providencia muitos benefıcios, como: seguranca, atraves de assinaturas
digitais; compressao; empacotamento de extensoes, juntando varios tipos de extensoes
diferentes em uma unica: o .JAR; portabilidade e o fato de quando e necessario fazer o
download de uma aplicacao apenas um arquivo deve ser baixado (SUN, 2008b).
4.3.2 JAD
Conforme estudado, alem do JAR e criado um arquivo em separado de extensao .JAD
que contem informacoes sobre o MIDlet. Este arquivo e usado muitas vezes para preparar
o JAR para ser instalado, otimizando a instalacao do aplicativo, porem nem todos os
aparelhos precisam ler o .JAD para realizar a instalacao. O arquivo JAD possui a seguinte
estrutura:
MIDlet-Name: Nome da Suite MIDlet.
MIDlet-Version: Versao da MIDlet.
MIDlet-Vendor : Desenvolvedor da MIDlet.
4.4. Interface 22
MIDlet-Icon: Especifica o ıcone da tela inicial da aplicacao.
MIDlet-Description: Descricao da aplicacao.
MIDlet-info-URL: Endereco para um arquivo de informacoes (JAR).
MIDlet-DATA-Size: Tamanho dos dados.
4.4 Interface
Os dispositivos moveis que implementam o perfil MIDP possuem diversas restricoes
quando se trata de interface, podendo variar em tamanho de tela, numero de cores apresen-
tadas na tela, disposicao dos botoes, etc. E estas informacoes sao acessadas pela MIDlet
somente em tempo de execucao. Sendo assim, o MIDP so permite a utilizacao de objetos
visuais simples, nao sendo permitida a implementacao de objetos comuns na versao Java
para desktop (JOHNSON, 2007).
O Java ME tem como padrao para construcao de interfaces a biblioteca LCDUI, que
e responsavel pelos componentes que formam a interface de aplicacoes MIDP. Nesta se-
cao estudaremos algumas classes desta biblioteca, que estao dispostas de acordo com a
hierarquia mostrada na Figura 4.2.
Figura 4.2: Hierarquia de classes.
4.4. Interface 23
Display e Displayable
Para desenvolver interfaces que se encaixem em dispositivos moveis com diferentes
caracterısticas de tela, as aplicacoes sao desenvolvidas com uma certa abstracao. Para
acessar as informacoes de um determinado aparelho existe a classe Display e cada MIDlet
possui sua propria instancia desta classe que pode ser acessada pelo metodo getDisplay(),
que geralmente esta contido no metodo startApp(), pois o Display so pode ser acessado
depois que aplicacao tenha sido iniciada.
Portanto, a tela do dispositivo e representada por uma instancia da classe Display,
que representa o hardware, e para que seja mostrado algo na tela devemos passar um
objeto Displayable para o objeto da classe Display. Displayable e uma classe abstrata
que controla o que e mostrado na tela e os comandos enviados pelos usuarios. Eles
representam conteudos de uma tela na qual ha interacao com o usuario (JOHNSON,
2007). Cada aplicacao possui apenas uma instancia da classe Display, sendo assim podem
existir varios objetos Displayable mas apenas um e mostrado por vez (MUCHOW, 2001).
Os objetos Displayable que estao na memoria, mas nao estao sendo mostrados estao no
chamado background e o objeto que esta sendo mostrado esta no foreground. Portanto os
objetos que estao no background nao tem acesso ao Display. Para mostrar um Displayable
na tela usamos o metodo setCurrent() e para obter qual objeto esta sendo mostrado no
Display usamos o metodo getCurrent() (JOHNSON, 2007).
A classe Displayable da origem a duas outras classes: Screen e Canvas. Ambas sao
classes para representar interfaces, porem a primeira classe, juntamente com suas subclas-
ses formam componentes de interface de alto nıvel e a segunda de baixo nıvel (MUCHOW,
2001).
Screen
Screen e uma classe que contem objetos graficos prontos, onde cada uma pode ter uma
aparencia, variando de acordo com o dispositivo em que esta sendo executada a aplicacao
(JOHNSON, 2007). Screen e suas herancas sao classificadas como objetos de interface de
alto nıvel (High-Level APIs) e as herancas desta classe sao as classes Form, List, Alert e
Textbox (MUCHOW, 2001).
Form
Form e um formulario o qual pode conter textos, imagens e outros componentes para
serem exibidos no visor. Varios componentes podem ser colocados em um Form e se
houver necessidade ele apresenta barra de rolagem automatica para mostrar todos estes
componentes visuais. Porem nada muito extenso e viavel para aplicacoes moveis.
4.4. Interface 24
Esses componentes que podem ser adicionados em um Form sao subclasses da classe
Item e serao estudados posteriormente. Um Form possui metodos para adicionar, inserir,
apagar e substituir componentes. Estes componentes da classe Item so pode ser inseri-
dos em um Form e nao em outras telas da classe Screen, como List, Alert ou Textbox
(MUCHOW, 2001).
Item
Conforme mostrado um Item e um componente que pode ser inserido em um Form e
suas subclasses sao:
• StringItem
E um simples texto estatico, ou seja, nao pode ser editado.
• TextField
E um campo para entrada e/ou edicao de texto. Podendo ser associadas regras a
este. Por exemplo: aceitar somente numeros, qualquer caracter, ser um campo de
senha, entre outros.
• ImageItem
Permite inserir uma imagem.
• ChoiceGroup
E uma lista de escolhas, dentro de um Form. Possui os tipos: multiplo, exclusivo
ou pop up.
1. Multiplo: Podem ser selecionadas varias opcoes, marcando uma caixa de che-
cagem que acompanha os elementos da lista;
2. Exclusivo: Pode ser selecionado apenas uma opcao e esta e marcada com um
radioButton.
3. Pop up: Pode ser selecionada apenas uma opcao. A lista e exibida como
uma comboBox, ou seja, os elementos ficam escondidos e quando clicada esta
lista toda e exibida. Apos a selecao de um elementos os outros elementos sao
escondidos novamente.
• DataField
Campo utilizado para exibir e/ou entrar com data e/ou hora.
4.4. Interface 25
• Gauge
E uma representacao grafica de um numero inteiro. Ele permite que o usuario
defina um nıvel, como o volume por exemplo, se for um Gauge interativo. Se for
nao interativo e somente o programa que o controla (MUCHOW, 2001).
• Spacer
Determina um espacamento vertical e/ou horizontal mınimo entre os componentes
de um Form. Ele e utilizado por questoes de design de layout.
• CustomItem
Utilizado para criar itens especıficos, atraves de desenhos, utilizando a classe Graphics
da API de baixo nıvel (MATTOS, 2005).
List
E uma lista que permite ao usuario selecionar opcoes. Estas podem ser tanto uma
String quanto uma imagem. O List pode ser exclusivo, multiplo ou implıcito. Implıcito e
quanto a lista e exibida sem nenhum marcador e somente uma opcao pode ser escolhida,
gerando um evento quando e selecionada uma das opcoes. Os outros dois tipos funcionam
igualmente ao ChoiceGroup (MATTOS, 2005).
Alert
E uma tela de informacao ao usuario. Pode conter uma mensagem de erro, de sucesso,
de informacao, entre outras. Ele pode ser programado para ser exibido durante um tempo
pre determinado, pode ser composto de um texto e uma imagem e sua aparencia varia de
acordo com o dispositivo movel usado (MATTOS, 2005).
TextBox
Basicamente e uma tela que serve para entrada e edicao de texto. E como se fosse um
Item textField, porem so existe ele na tela. Em um textBox tambem podem ser usadas
regras, assim como em um textField (SUN, 2006b).
Canvas
Canvas e uma classe de baixo nıvel, que proporciona maior liberdade na implementacao
dos graficos e eventos. E destinada a aplicacoes que necessitam de posicionamento preciso
dos elementos graficos, sendo portanto muito utilizada para a criacao de jogos.
4.5. Armazenamento Persistente 26
Atraves da utilizacao desta classe e possıvel desenhar na tela. O desenvolvedor cria
o que sera mostrado para o usuario final. Para criar uma interface grafica com canvas e
utilizado a classe Graphics, que fornece metodos para desenhar linhas, arcos, retangulos
e textos, alem de especificar cores e fontes (MUCHOW, 2001).
Alem de desenhar interfaces, a classe canvas permite controlar eventos primitivos,
como teclas pressionadas e liberadas e acessar dispositivos de entrada de dados, como
teclados em geral, toques, em telas touchScreen, entre outros (MATTOS, 2005).
Command
A classe Command permite adicionar comandos, ou seja, funcoes, aos objetos mostra-
dos na tela (JOHNSON, 2007). Os comandos sao usados para a interacao do usuario com
a aplicacao podendo ser atribuıdos a qualquer Displayable, de alto ou baixo nıvel, e a um
Item. Quando um comando e acionado pelo usuario, e notificado a um CommandListener
que e definido no objeto Displayable. Um command contem somente uma informacao
sobre o comando e nao sobre qual acao realizar. A acao e definida no CommandListener
associado ao Displayable (SUN, 2006a).
CommandListener: E uma interface usada para tratar os eventos, controlando quais
e quando os eventos foram acionados. O commandListener vincula um comando a um
gatilho, detectando quais comandos foram ativados e definindo gatilhos para eles. Quando
um comando e acionado, o commadAction o captura, juntamente com o Displayable atual
(JOHNSON, 2007).
4.5 Armazenamento Persistente
Os dispositivos moveis que usam o perfil MIDP possuem, como memoria volatil, a
memoria RAM e, como memoria de armazenamento persistente, a memoria flash. Esta
permite armazenar dados por longos perıodos de tempo, sem a necessidade de ser mantida
energizada por uma bateria ou fonte eletrica.
As vantagens da memoria flash sao: o pequeno tamanho fısico, a resistencia a choques,
o alto desempenho para a leitura de dados, entre outros. E algumas de suas desvantagens
sao o fato de as operacoes de escrita serem lentas e a capacidade de armazenamento ser
restrita. Porem, a maioria dos dispositivos moveis contam com um cartao de memoria,
que serve como um drive de armazenamento. O cartao oferece solucao ao armazenamento
restrito, porem o seu acesso e mais lento se comparado com o acesso a memoria flash
interna.
Para o armazenamento persistente o perfil MIDP utiliza a API RMS (Record Mana-
gement System - Sistema de gerenciamento de armazenamento) e a API JSR-75 - File
4.5. Armazenamento Persistente 27
Connection, que implementa um sistema de armazenamento em arquivos. Porem nao sao
todos os dispositivos que fornecem acesso a esta ultima API (LUGON, 2005).
4.5.1 RMS
A API RMS e o mecanismo padrao para persistencia de dados oferecido pelo MIDP. O
RMS funciona como um banco de dados orientado a registros, apresentando-se diferente
dos tradicionais bancos de dados relacionais conhecidos. Ele e composto por Record Stores,
que sao como armazens de dados, conforme mostra a Figura 4.3.
Figura 4.3: Record Management System.
Um Record Store e identificado por um nome, que e case sensitive e e criado por um
MIDlet. Entao quando um MIDlet e removido de um dispositivos todos os Record Stores
relacionados a ele serao removidos tambem. O limite de armazenamento e o mesmo que
o dispositivo oferecer.
A API RMS nao suporta tipos 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 aplicacao deve converter os dados para array de bytes para poderem ser
armazenados. Para ler os dados o processo inverso deve ser feito (MUCHOW, 2001).
Contudo, podemos imaginar o Record Store como um conjunto de linhas, onde cada
linha e um registro (Record) e estes sao identificados por uma chave primaria, chamada
Record ID, que e um inteiro. Logo, cada registro e formado por um inteiro e um array de
bytes. A API fornece metodos para abrir, fechar e deletar um RecordStore inteiro. Alem
destes existem metodos para a manipulacao 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
Atraves de frameworks e APIs especıficas e possıvel construir aplicacoes com mais
recursos, dispondo de varias funcionalidades extras, que nao sao encontradas nas especi-
ficacoes do perfil MIDP, alem de otimizar o desenvolvimento. Este capıtulo lista algumas
APIs e frameworks mais utilizados no desenvolvimento de aplicacoes para celulares e
smartphones, utilizando a plataforma Java ME, destacando-se os que foram utilizados no
estudo de caso e explica o porque da escolha destes.
5.1 APIs
Com APIs podemos desenvolver aplicacoes que se conectam a servidores remotos, com
outros aparelhos, aplicacoes que utilizam bluetooth, que executam musicas e vıdeos, entre
outras. Algumas das APIs opcionais disponıveis para o perfil MIDP sao citadas por
(JOHNSON, 2007).
• Java APIs for Bluetooh (JSR 82) - Permite o desenvolvimento de aplicacoes para
acesso a rede bluetooh.
• Location API (JSR 179) - Permite o desenvolvimento de aplicativos baseados em
localizacao fısica (LBS).
• Mobile Game API (JSR 178) - Voltada para criacao de jogos.
• Mobile Media API (JSR 135) - Permite reproducao de mıdia.
• Security and Trust Services API for J2ME (JSR 177) - Usada para adicionar segu-
ranca as aplicacoes.
• Wireless Messaging (JSR 120 e 205) - Permite troca de mensagens SMS.
28
5.1. APIs 29
Entre outras APIs opcionais importantes para auxiliar no desenvolvimento de aplica-
coes temos:
• File Connection API (JSR 75) - Permite acesso e armazenamento em arquivos e
acesso a programas nativos do dispositivo, como agenda, calendario, entre outros.
• Mobile Sensor API (JSR 256) - Permite a recuperacao de dados de sensores internos
ou externos ao aparelho celular.
• MECHART - Uma API de terceiro, ainda nao catalogada pela JCP, que permite
construir graficos de maneira simples e rapida, sem a necessidade de programar
diretamente na classe Canvas.
Dentre estas, vamos estudar a FileConnection API, pois alem de ser uma das mais
usadas por desenvolvedores da plataforma Java ME, possui maior reconhecimento e sera
de grande utilidade para o projeto que desenvolveremos posteriormente.
E importante dizer que a JCP ate o momento tem catalogado 927 JSRs na plataforma
Java (JCP, 2009b). E para a plataforma Java ME foram especificadas 83 JSRs, entre elas
APIs opcionais.
File Connection API
A JSR 75 especifica dois pacotes obrigatorios para a plataforma Java ME:
• O PIM - Pacote que permite desenvolvedores acessar os dados de PIM do aparelho,
tais como agenda, livro de enderecos e listas de tarefas, que existe na maioria dos
dispositivos moveis.
• O Pacote opcional de conexao de arquivos (FCOP) - Permite aos desenvolvedores
o acesso a diversas formas de dados, tais como: imagens, sons, vıdeos, textos en-
tre outros tipos de dados do sistema de arquivo do dispositivo movel. Isto inclui
dispositivos de armazenamento removıveis, como cartoes de memoria.
O PIM e os arquivos de dados permitem a integracao de aplicacoes com informacoes
sobre o dispositivo, permitindo aplicacoes mais inteligentes (SUN, 2009c).
Abaixo estao as importantes classes e interfaces:
• ConnectionClosedException - Lancada quando um metodo e invocado em uma Fi-
leConnection quando a conexao e fechada.
5.2. Frameworks 30
• FileSystemRegistry - Classe central de registros que possui a habilidade de listar
roots montadas atraves do metodo listRoots(). Ela tambem providencia metodos
para os ouvintes de registros (Registering listeners), estes sao notificados se sistemas
de arquivos sao adicionados ou removidos durante o tempo de execucao.
• A FileSystemListener interface - Usada para recepcao de notificacoes de status
quando e adicionado ou removido um sistema de arquivo raız.
• A FileConnection interface - Usada para acessar diretorios e arquivos no dispositivo.
Ela estende a Connection interface e mantem inumeros metodos uteis para criar,
remover diretorios e arquivos, lista de conteudo de diretorios, configurar permissoes,
obter informacoes de arquivos e efetuar operacoes de entrada e saıda nos arquivo.
Os pacotes usados sao:
• javax.microedition.pim
• javax.microedition.io.file
No desenvolvimento do estudo de caso foi explorado o pacote opcional de conexao de
arquivos (FCOP), dependente apenas do nucleo de classes definidas pelo CLDC.
A forma de acessar os arquivos e utilizando a FCOP atraves da interface FileConnec-
tion, muito usada por sinal. Para isto basta importar o pacote javax.microedition.io.file.-
FileConnection.
A FileConnection estende StreamConnection pela adicao de metodos de arquivo e
diretorio de manipulacao. A funcionalidade adicional e semelhante a que se 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 metodos 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 otimizacao no desenvolvimento de aplica-
coes para dispositivos moveis estao:
• Floggy - Framework para persistencia de dados.
• J2MicroDB - Fornece um banco de dados relacional limitado para dispositivos mo-
veis.
5.2. Frameworks 31
• Perst Lite - Banco de dados orientado a objetos para aplicacoes embarcadas.
• JMESQL - Banco de dados relacional escrito em Java.
• KXML - Realiza o parser de arquivos XML.
• LWUIT - Possibilita o desenvolvimento de interfaces ricas (RIA) e robustas.
• Java2ME Polish - Framework para personalizar a UI (User Interface) do MIDlet
sem alterar o codigo fonte.
• Diamont Powder - Acelera a criacao de aplicacoes para coleta de dados.
• Fire (Flexible Interface Rendering Engine) - Framework para o desenvolvimento de
interfaces mais atraentes que as compreendidas pelo MIDP.
• Marge - Facilita o desenvolvimento de aplicacoes em Java que fazem uso de bluetooth
Entre os frameworks citados neste trabalho, astraves de testes, os que melhor atende-
ram ao desenvolvimento do estudo de caso foram: o Floggy, pois abstrai significativamente
a complexidade dos codigos RMS para a persistencia de dados, o LWUIT, que fornece in-
terfaces bastante atraentes, alem de estar caminhando para ser o framework referencia
em UI, por fim o KXML, para fazer o parse de XMLs, usado para interpretar os dados
trocados entre servidor e aplicacao movel.
5.2.1 Floggy
Uma das limitacoes impostas pelo perfil MIDP e a utilizacao da API RMS, na maioria
dos dispositivos, para a persistencia de dados. Visando a dificuldade dos codigos utilizados
para acessar esta API surgiu o Floggy, framework de persistencia free para J2ME/MIDP,
desenvolvido por brasileiros. Seu principal objetivo e abstrair os detalhes da persistencia
de dados para o desenvolvedor, reduzindo os esforcos de desenvolvimento e manutencao
(FLOGGY, 2009).
O Floggy utiliza comandos de alto nıvel para encapsular os comandos necessarios para
o armazenamento e recuperacao de objetos, ou seja, o que esta por tras deste framework
sao codigos para acessar a API RMS (LUGON, 2005).
O framework e composto por dois modulos:
- Framework : responsavel por fornecer os metodos de persistencia como salvar, remover
e recuperar os dados, atraves de um arquivo JAR (11KB) que deve ser adicionada na
aplicacao.
5.2. Frameworks 32
- Compilador: responsavel por analisar, gerar e compilar o bytecode. Bytecode e o
codigo binario gerado pelo compilador Java, que mais tarde sera interpretado por uma
JVM, sendo assim executada uma aplicacao (FLOGGY, 2009).
O modulo framework apresenta as seguintes classes:
Persistable
Funciona como um marcador, assim as classes que o implementam sao consideradas
persistentes para o Floggy.
PersistableManager
E a classe principal do framework, pois gerencia a persistencia e permite executar
todas as operacoes de persistencia, como carregar, salvar, recuperar, remover, listar, entre
outros.
Filter
As classes que implementam esta interface definem criterios para selecao dos registros
que devem ser listados ou capturados.
Comparator
As classes que implementam esta interface definem criterios para ordenar registros que
foram selecionados.
ObjectSet
Os resultados de selecao de registros resultam em objetos da classe ObjectSet. Assim
esta classe serve para obter uma lista de registros e funciona como um cursor.
PersistableMetaData
Reune informacoes sobre os objetos de uma determinada classe, como numero de
objetos, data da ultima modificacao, entre outros (LUGON, 2005).
5.2.2 KXML
O KXML e um framework que faz o parser de XML, utilizando a tecnica pull parser,
que sera discutida na secao 6.2.1, do capıtulo 6. Ele e utilizado para simplificar e otimizar
5.2. Frameworks 33
o acesso, parse e exibicao de XMLs e e destinado principalmente a ambientes restritos
como em dispositivos que usam o perfil MIDP (HAUSTEIN, 2007).
Possui as tres versoes. A primeira versao foi criada para dispor a tecnica pull parser
em dispositivos moveis e embarcados e e baseada em eventos de objetos. A segunda versao
e a versao corrente e possui caracterısticas de cursor em vez de se basear em eventos de
objetos. A terceira versao ainda esta sendo produzida.
Segundo LECHETA (2006), as principais operacoes do KXML sao:
• nextTag(): Aponta para o proximo inıcio ou fim de tag, pulando eventos insignifi-
cantes como espacos em branco ou comentarios.
• Require(): Obriga o cursor a ser posicionado onde for indicado.
• nextText(): Exige que a posicao corrente seja uma tag de inıcio. Retorna o texto
contido no elemento correspondente.
• getName(): Obtem o nome da tag na posicao corrente.
Um analisador de XML deveria nao aceitar ou reconhecer documentos com erros,
porem devido as restricoes dos dispositivos moveis isto nao e 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 aplicacao que sera desenvolvida (HAUSTEIN,
2007).
5.2.3 LWUIT
O LWUIT (LightWeight User Interface Toolkit) e um framework para a criacao de
interfaces graficas ricas em dispositivos moveis, que suportam a tecnologia Java ME.
Inspirado no Swing da plataforma Java SE, foi projetado para ser o mais leve possıvel,
comprometendo o mınimo possıvel a aplicacao final, visto que foi desenvolvido para dis-
positivos com capacidades restritas (SUN, 2009d).
Com o LWUIT nao ha mais necessidade de se desenhar telas em canvas para construir
interfaces mais amigaveis, e uma grande evolucao visto que a complexidade para tal
tarefa e muito alta. O framework oferece melhorias a componentes graficos de alto nıvel
ja existentes no Java ME, como List, Form, Alert, entre outros. Ainda oferece varias
outras vantagens como suporte a touch Screen, diversas fontes, animacoes, transicoes de
telas animadas e temas variados, que podem ser incluıdos pelos proprios usuarios.
Alem das caracterısticas citadas acima, o LWUIT tambem inclui: a utilizacao de
layouts, que organizam a disposicao dos componentes na tela, alem de oferecer melhor
5.2. Frameworks 34
portabilidade, integracao 3D (se o dispositivo possuir bibliotecas 3D), caixas de dialogo,
utilizacao de abas (como no Java SE) e internacionalizacao. O LWUIT roda no perfil
MIDP 2.0 e esta sob a licenca GPL v2.0 com a Classpath Excepption, o que significa que
pode ser utilizado em aplicacoes de codigos nao abertos, desde de que nao haja modificacao
nas classes do framework (NETO, 2008).
O framework foi recentemente incorporado pela Sun como uma de suas bibliotecas
padroes, no Java ME Plataform SDK 3, que substitui o WTK (Wireless ToolKit) - para
CLDC e o CDC ToolKit, o que promete ainda mais alavancar a utilizacao do LWUIT
dentro da comunidade de desenvolvedores (DOEDERLEIN, 2009).
Capıtulo 6
Comunicacao com o Servidor
Neste capıtulo sao apresentadas algumas caracterısticas da plataforma Java Enterprise
Edition (Java EE), a fim de estudar um metodo eficiente para a construcao de servidores
de dados remotos para alimentar qualquer sistema movel que necessite deste tipo de
comunicacao.
6.1 A Plataforma Java EE
Existem diversas tecnologias que fornecem aplicacoes com conteudo dinamico e per-
sonalizado, seja para construir um simples site de conteudo dinamico ou um sistema
complexo de e-business com banco de dados que integram sistemas corporativos. A pla-
taforma Java EE fornece um conjunto de tecnologias para o desenvolvimento de aplicacoes
robustas para a Web. Dentre as tecnologias disponıveis atualmente, destacam-se para o
desenvolvimento de aplicacoes os servlets e paginas JSP (JavaServer Pages). servlets e
JSP sao duas tecnologias desenvolvidas pela Sun para desenvolvimento de aplicacoes na
Web a partir de componentes Java que executam no lado do servidor. A Figura 6.1 ilustra
a arquitetura da plataforma Java EE.
A utilizacao de servlets oferece diversas vantagens em relacao a outras tecnologias para
o desenvolvimento de aplicacoes Web. As principais vantagens sao herdadas da propria
linguagem Java, entre elas estao: Portabilidade, facilidade de programacao e a flexibilidade
da linguagem para o desenvolvimento. Em particular, os servlets sao mais eficientes,
apresentam melhor usabilidade, maior poder na programacao, sao mais portateis, mais
seguros e mais baratos que um CGI (Common Gateway Interface) tradicional (HALL,
1998).
35
6.1. A Plataforma Java EE 36
Figura 6.1: Arquitetura da plataforma Java EE.
CGI e um padrao que determina a forma de comunicacao entre o servidor Web e
uma outra aplicacao rodando neste servidor e um script CGI e um programa que atende
requisicoes enviadas por um cliente e repassa para um servidor HTTP (QUIN, 2009).
Um servlet tem um modelo de programacao parecido com um script CGI, porem os
programas de CGI necessitam de um processo para tratar cada nova solicitacao e no caso
dos servlets, podem existir varios ligados ao mesmo servidor, que estes sao executados
dentro de um mesmo processo. E este processo roda dentro de uma JVM, que gera
um encadeamento de processos para tratar cada solicitacao. Estes encadeamentos geram
muito menos overheads do que processos completos (PITTELLA, 2009).
6.1.1 Servlets
Segundo HALL (1998), servlet e uma resposta da tecnologia Java para a programacao
CGI. Sao programas que rodam em sevidores Web agindo como uma camada mediana
entre um pedido que vem de um browser Web ou outro cliente de HTTP.
O trabalho dos servlets se resumem em:
• Ler qualquer dado enviado pelo usuario.
• Observar qualquer outra informacao sobre o pedido que e embutido no pedido de
HTTP.
• Gerar os resultados.
• Formatar os resultados dentro de um documento.
• Fixar parametros de resposta de HTTP apropriados.
6.1. A Plataforma Java EE 37
• Enviar de volta o documento ao cliente.
Servlets sao classes Java instaladas junto a um Servidor que implemente um Servlet
Container, interagindo com clientes Web usando o paradigma request-response, ou seja,
um programa Java que estende funcionalidades de um servidor de aplicacoes Java que
permite a execucao de servlets comunicando com clientes.
O componente container, ou conteiner, e resposnsavel por dar suporte as APIs de
servlets e JSP. Gerencia as instancias dos servlets e fornece os servicos de rede necessarios
para as requisicoes e respostas. O container pode criar varias threads permitindo que
uma unica instancia servlet atenda mais de uma requisicao simultaneamente. A Figura
6.2 ilustra a relacao entre esses componentes.
Figura 6.2: Servlet container.
Os servlets sao independentes de protocolos e plataformas, podendo trabalhar com
diversos tipos de servidores, pois a API dos servlets nao assume nada a respeito do am-
biente do servidor. Diversas requisicoes podem ser feitas ao mesmo tempo em um unico
servidor.
O comportamento dos servlets que sera estudado para a construcao de aplicacoes
esta definido na classe HttpServlet do pacote javax.servlet. Tendo em vista o paradigma
request-response, cujo atende requisicoes realizadas por meio do protocolo HTTP, os ob-
jetos dos servlets podem capturar parametros desta requisicao, efetuar qualquer proces-
samento inerente a uma classe Java e enviar respostas na forma de paginas HTML, XML,
imagens entre outros (TEMPLE, 2004).
Um servlet e basicamente definido pela Interface Servlet, uma classe de interface que
implementa os metodos init(), service() e destroy(), e a estrutura de uma classe servlet
contem os metodos doGet() e doPost(), como ilustrado na Figura 6.3.
Todos os seguintes metodos sao invocados por meio do metodo service() da classe de
interface.
6.2. XML - Linguaguem de marcacao extensıvel 38
Figura 6.3: Ciclo de vida do servlet.
• Metodo doGet: Trata requisicoes do tipo GET. Esse tipo pode ser enviado varias
vezes e alocado em um bookmark.
• Metodo doPost: Trata requisicoes do tipo POST, permitindo que o cliente envie
dados do servidor Web uma unica vez.
• Metodo doPut: Trata requisicoes do tipo PUT, permitindo que o cliente envie
arquivos para o servidor, semelhante ao FTP.
• Metodo doDelete: Trata requisicoes do tipo DELETE, permitindo que o cliente
remova determinada pagina ou documento do servidor.
Um servlet nao possui interface grafica, porem dentro de um servlet e possıvel construir
um HTML, mas a visualizacao e entendimento e de alta complexidade quando se trata
de logicas extensas. Tendo em vista que o foco do estudo de caso esta em um ambiente
movel, nao e necessario a construcao de uma interface grafica para trabalhar junto com o
servlet.
6.2 XML - Linguaguem de marcacao extensıvel
A Extensible Markup Language (XML) e uma linguagem de marcacao de dados sem
nenhum elemento de apresentacao embutido, ou seja, apenas com elementos de definicao
6.2. XML - Linguaguem de marcacao extensıvel 39
de conteudo. O XML prove um formato para descrever dados estruturados que facilita
declaracoes mais precisas do conteudo e resultados mais significativos de busca atraves de
multiplas plataformas.
Segundo TITTEL (2002), a palavra extensıvel reflete o fato de que a linguagem e
flexıvel, escalonavel e adaptavel. Com esses tres fatores o desenvolvimento de aplicacoes
em tres camadas (three-tier), que e o caso deste projeto, e altamente factıvel com o XML.
Os dados podem ser distribuıdos entre as aplicacoes desktop para serem visualizados em
um navegador ou em servidores intermediarios para o processamento, permitindo que tais
dados possam ser facilmente combinados via software, com bancos de dados nas extremi-
dades da rede. Desta forma a troca de informacoes entre dispositivos moveis e servidores
remotos seria realizada de maneira mais comprimida e escalavel, alem de proporcionar
buscas mais eficientes. Esse ponto e de suma importancia, pois os dispositivos moveis
tipicamente possuem memoria limitada e baixo poder de processamento.
A estrutura de um documento XML e baseada em um modelo de arvore rotulada.
Geralmente possui um no raiz especial acima do elemento raiz. Os nos internos sao
elementos rotulados com um nome e um conjunto de atributos (valor). Os nos folhas
contem:
• Sequencias de caracteres
• Anotacoes de processamento, normalmente no cabecalho do documento
• Um comentario
• Uma declaracao de entidade
• Nos DTD (Document Type Declaration)
Podemos visualizar uma breve estrutura de um documento XML com sua respectiva
arvore na Figura 6.4.
6.2.1 Analise de documentos XML
A partir de um modelo no formato XML e necessario realizar a analise dos dados
embutidos atraves de uma tecnica denominada Parse. Segundo VELOSO (2007), Par-
sing e o processo de leitura e divisao do documento em elementos, atributos, entidades,
comentarios e outros tipos de dados, por meio do qual poderao ser analisados e validados.
Existem algumas tecnicas para realizar o parse de um XML, como o pull parser, o
DOM e o push parser. No pull parser uma quantidade de dados e analisada de cada
vez, durante o parse sempre e solicitado a proxima parte que deve ser processada ate
chegar ao fim, geralmente isto e feito em um loop. Assim sao obtidas as informacoes do
6.2. XML - Linguaguem de marcacao extensıvel 40
Figura 6.4: Estrutura do XML.
XML a medida que o parser e efetuado. Uma outra tecnica e o DOM, que utiliza um
modelo baseado em arvore e cria uma estrutura de dados na memoria, onde e possıvel
acessar essa estrutura atraves de um conjunto de objetos. E muito simples de se utilizar,
porem e necessario ler o documento inteiro para montar a estrutura de arvore, para depois
exibir as informacoes que foram lidas, alem disso, pode ter muitos objetos armazenados na
memoria entao nao e recomendado para ser usado em Java ME. E o modelo push parser
e orientado a eventos, portanto ao ler um XML um objeto listener e notificado sempre
que novas tags sao encontradas.
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 praticas do extreme
programming durante um perıodo de tres meses.
7.1 Extreme programming
Extreme programming (Programacao extrema), ou XP, e uma metodologia agil de de-
senvolvimento de software voltada para projetos cujos requisitos mudam com frequencia.
O desenvolvimento e orientado a objetos e possui equipes de desenvolvimento pequenas.
Assim como outros metodos ageis, 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 praticas do
XP e que o cliente esteja sempre presente (TELES, 2004).
No XP todas as funcionalidades do sistema sao descritas em estorias, escritas pelos
clientes, e os desenvolvedores implementam as partes do sistema baseados nestas estorias.
Em uma reuniao, chamada jogo de planejamento, o tempo de implementacao de cada
estoria e definido utilizando um sistema de pontos, onde um ponto significa um dia ideal
de trabalho, cujo desenvolvedor gaste todo o tempo somente na implementacao. O cliente
prioriza quais as estorias que devem ser implementadas primeiro e entao o sistema e
desenvolvido em partes, podendo assim ser entregue periodicamente releases do sistema.
Estes releases sao 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 razao eles sao divididos em espacos de tempo menores, chamados de
41
7.2. Arquitetura do sistema 42
iteracoes. Cada iteracao contem um conjunto de estorias e no final desta o cliente pode
validar as implementacoes efetuadas e dar seu feedback. O XP utiliza ainda o conceito de
programacao em par. Enquanto uma das pessoas esta escrevendo o codigo a outra pessoa,
chamada de navegador, esta permanentemente revisando. Todo codigo desenvolvido e
coletivo, portanto utiliza-se padronizacao para simplificar o desenvolvimento (TELES,
2004).
O XP oferece agilidade no processo de desenvolvimento de software e um feedback
rapido do cliente, o que e necessario quando se trata de desenvolvimento para celulares e
smartphones, por ser um sistema enxuto. Portanto, para este estudo de caso foi adotado
as praticas da metodologia agil XP, onde foram definidos dois releases, cada um composto
por duas iteracoes. As iteracoes dos releases foram descritas no decorrer deste trabalho.
7.2 Arquitetura do sistema
Para o trabalho que segue, foi abordado juntamente da plataforma Java ME, o uso
de servlets, dentro da arquitetura Java EE, interagindo com um cliente via HTTP para
estabelecer a comunicacao com o dispositivo movel. Visto que um servlet pode efetuar
qualquer processamento inerente a uma classe Java e enviar respostas na forma de docu-
mentos XML, para efetuar a troca de dados entre o dispositivo movel e o servidor remoto
de dados, que alimentara o sistema movel, foi utilizado os recursos que a linguagem XML
oferece.
A Figura 7.1 mostra o esquema de comunicacao para o trabalho proposto. Definido
por uma arquitetura Cliente - Servidor e baseado nas tres seguintes camadas:
Figura 7.1: Esquema de comunicacao.
7.3. Visao geral do sistema 43
7.3 Visao geral do sistema
E proposto um sistema movel gerador de pedidos para uma empresa revendedora de
bebidas. O sistema sera responsavel por cadastrar e editar clientes, gerar os 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 atraves de consultas a
catalogos e toda informacao coletada e registrada em listas e repassada para a central da
empresa, onde os dados eram digitalizados para serem armazenados no banco de dados
central da distribuidora.
A empresa possui um sistema Web, que e o responsavel por alimentar o sistema movel.
Com este sistema a gerencia otimiza o acesso aos dados de forma segura, alem de facilitar
o trabalho dos revendedores. O revendedor realiza o pedido via celular ou smartphone, e
este e armazenado no aparelho. Quando o dispositivo acessar uma rede sem fio e possıvel
atualizar o banco de dados do dispositivo e enviar os pedidos para um sistema Web que
ira armazenar as informacoes no banco de dados central da distribuidora, controlando
todas as informacoes referente a forca de vendas.
7.4 Diagrama de Caso de Uso
Para o melhor entendimento do sistema, o diagrama de casos de uso mostrado na
Figura 7.2, descreve o cenario que mostra as funcionalidades do sistema do ponto de vista
do usuario.
Figura 7.2: Diagrama de Caso de Uso.
7.5. Estorias 44
7.5 Estorias
As Figuras 7.3 a 7.7 ilustram estorias, que na pratica sao escritas pelo cliente. Estas
estorias contem as funcionalidades que um cliente deseja possuir em seu sistema e forne-
cem a base para os desenvolvedores implementarem as solucoes necessarias, ou seja essas
estorias fornecem os requisitos do sistema. O modelo classico dos cartoes de estorias foi
adotado, a fim de seguir padroes das praticas XP.
Figura 7.3: Estoria 1-A: Consulta de produtos.
A estoria 1-A corresponde ao caso de uso ”Consultar Produto”.
Figura 7.4: Estoria 1-B: Consulta e cadastro de clientes.
A estoria 1-B corresponde ao caso de uso ”Gerenciar Cliente”.
7.5. Estorias 45
Figura 7.5: Estoria 2-A: Cadastro de pedidos.
Figura 7.6: Estoria 2-B: Alteracao de pedidos.
As estorias 2-A e 2-B correspondem aos casos de uso ”Gerenciar Pedido”.
7.6. Release 1 46
Figura 7.7: Estoria 2-C: Envio dos dados para o banco central da empresa.
A estoria 2-C corresponde ao caso de uso ”Exportar dados”.
Os casos de uso ”Autenticar Usuario”e ”Atualizar Banco”nao estao descritos nas esto-
rias, porem sao necessidades do sistema.
7.6 Release 1
Este release e dividido nas seguintes iteracoes:
7.6.1 Iteracao A
Nesta iteracao foi utilizada a estoria 1-A (”Consulta de produtos”) como base para
implementacao. Neste ponto foram implementados os metodos para importacao de um
documento XML do servidor, que contem 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 usuario 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 negocio, com o proposito 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 Iteracao B
Para esta iteracao foi utilizada a estoria 1-B (”Consulta e cadastro de clientes”) como
base para implementacao. Foram implementados os metodos para construcao do banco
de dados local a partir dos dados dos clientes que estao no XML importado na Iteracao
A. Foi desenvolvida a interface com o usuario 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 iteracoes:
7.7.1 Iteracao A
Nesta iteracao foi utilizada a estoria 2-A (”Cadastro de pedidos”) como base para
implementacao. Foram implementados os metodos de cadastro e listagem de pedidos,
bem como as interfaces de usuario correspondentes.
7.7.2 Iteracao B
Nesta iteracao foram utilizadas as estorias 2-B (”Alteracao de pedidos”) e 2-C (”Envio
dos dados para o banco central da empresa”) como base para implementacao. Foram
implementados os metodos de edicao e exclusao dos pedidos cadastrados e as interfaces
correspondentes. Neste ponto tambem foram implementadas as funcionalidades necessa-
rias para exportacao 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 Aplicacao 49
7.8 A Aplicacao
A aplicacao desenvolvida no estudo de caso, um sistema movel de forca de venda
para uma distribuidora de bebidas, teve seu foco sobre a plataforma Java ME, utilizando
tambem o Java EE para a construcao de um servidor que armazena documentos XMLs,
com dados que alimentam a aplicacao movel. Estes XMLs contem dados dos produtos
e clientes ja cadastrados, alem de oferecer uma gama de logins e senhas validos para a
autenticacao do usuario.
A aplicacao movel foi construıda utilizando os frameworks ja citados anteriormente:
LWUIT, KXML e Floggy. O LWUIT, proporcionou uma interface rica para a aplica-
cao 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 metodos de per-
sistencia, simplificando os metodos para o armazenamento dos dados, em Records Stores,
armazens de dados gravados na memoria do celular ou smartphone.
Alem dos frameworks citados, o sistema movel faz uso da File Connection API, res-
ponsavel, dentre outras funcoes, pelo acesso a arquivos situados no sistema de arquivos
local do dispositivo movel utilizado. Na aplicacao, esta API proporciona a gravacao de
um arquivo XML de saida, com os novos dados obtidos na aplicacao, ou seja, dados de
pedidos e novos clientes.
Quando a aplicacao e executada faz um acesso ao servidor, obtendo dados do XML
que contem os logins e senhas validos e faz uma comparacao com o login e senha digitados,
procurando se o login existe na lista e se a senha confere. A tela de autenticacao pode
ser observada na Figura 7.11. Autenticado, o usuario possui acesso ao menu principal
da aplicacao, ilustrado na Figura 7.12. Este menu fornece acesso: a Clientes, permitindo
funcoes de busca e cadastro; Produtos, permitindo funcoes de somente de busca; Pedidos,
onde e possıvel cadastrar novos pedidos, utilizando as funcoes de busca de clientes e
produtos; Lista de Pedidos, que dispoe uma lista de pedidos ja cadastrados permitindo
que estes sejam alterados ou excluıdos; Importacao, permite que a aplicacao acesse o
servidor remoto, trazendo os dados dos XMLs de produtos e clientes para o banco de
dados local do dispositivo movel; e Exportacao, gera um arquivo XML de saıda com
os dados dos clientes e pedidos cadastrados. Este arquivo e armazanado no cartao de
memoria do celular ou smartphone, para ser enviado para o servidor ou utilizada de outra
forma desejada.
7.8. A Aplicacao 50
Figura 7.11: Autenticacao do usuario.
7.8. A Aplicacao 51
Figura 7.12: Menu principal da aplicacao movel.
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 atraves do menu clientes e as duas ultimas atraves 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 opcoes de editar ou excluir um pedido realizado. Estas telas
podem ser obtidas respectivamente nos menus Pedidos e Lista de Pedidos.
7.8. A Aplicacao 52
Figura 7.13: Cadastro de Clientes.
7.8. A Aplicacao 53
Figura 7.14: Busca de Produtos.
7.8. A Aplicacao 54
Figura 7.15: Detalhamento de produto.
7.8. A Aplicacao 55
Figura 7.16: Cadastro de pedidos.
7.8. A Aplicacao 56
Figura 7.17: Lista de pedidos.
Capıtulo 8
Consideracoes Finais
Apos estudos que culminaram nesta dissertacao e atraves do desenvolvimento do es-
tudo de caso podemos chegar nas seguintes conclusoes.
Atualmente o uso de telefones celulares no mundo e bastante elevado. Organizacoes
corporativas estao evoluindo juntamente com tecnologias moveis para a otimizacao do
processo de negocio. Dessa forma o uso de smartphones vem se tornando de grande utili-
dade tanto nestas organizacoes quanto para o uso particular. Visto que a plataforma Java
Micro Edition e bem aceita pelo mercado de software, torna-se viavel o desenvolvimento
de aplicacoes moveis e embarcadas usando tal tecnologia.
O perfil MIDP e suportado pela configuracao CLDC, providenciando um ambiente
padrao de execucao de aplicacoes Java para os dispositivos moveis mais convencionais.
Este perfil prove um conjunto de bibliotecas e classes que fornecem um sistema de arma-
zenamento persistente, interface com o usuario, transacoes seguras, gerencia de sons, entre
outras caracterısticas que proporcionam um bom ambitente de desenvolvimento. Atraves
de MIDlets foi possıvel desenvolver aplicacoes utilizando o perfil MIDP. Estas aplicacoes
Java podem ser construıdas atraves da biblioteca LCDUI, que fornece componentes para
o desenvolvimento da interface das aplicacoes. Porem, tambem existem frameworks que
porporcionam o desenvolvimento de interfaces com o usuario mais robustas.
Para a comunicacao da aplicacao movel com um servidor remoto de dados, o uso
da plataforma Java EE com a implementacao de servlets se torna algo muito eficiente,
tanto para a seguranca dos dados quanto para a compatibilidade entre as plataformas.
A transferencia dos dados pode ser realizada atraves de diversas extensoes de arquivos,
seja no formato de documentos XML, imagens, arquivos compactados ou ate mesmo em
formato de strings, atraves de requiscoes HTTP. Vale ressaltar que a transferecia de dados
utilizando documentos XML e muito bem organizada e segue um padrao de transferencia
de informacao unificado, porem o uso desse tipo de documento causa um leve retardo
57
58
tanto no desempenho da aplicacao durante a leitura das informacoes quanto ao tamanho
do arquivo de tranferencia, que fica levemente extenso devido a padronizacao e organizacao
das informacoes.
Atraves de alguns frameworks foi possıvel construir uma aplicacao com mais recur-
sos, alem de otimizar o desenvolvimento. As tarefas mais rotineiras utilizadas para o
desenvolvimento de aplicacoes comerciais tratam do armazenamento persistente dos da-
dos no proprio dispositivo, construcao de interfaces com o usuario mais robustas e da
transferencia de dados padronizados na forma de documentos XML. Tendo em vista es-
tas caracterısticas, atraves de testes e do levantamento bibliografico, os frameworks que
melhor atenderam para a execucao de tais tarefas foram respectivamente o Floggy - para
persistencia 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 manipulacao de arquivos e diretorios do
dispositivo. Visando uma possıvel implementacao deste tipo de funcionalidade, seja para
contrucao de um XML de saıda ou de qualquer outro arquivo, o uso desta API e de suma
importancia para aplicacoes moveis.
Para auxiliar no desenvolvimento do estudo caso, a metodologia agil extreme program-
ming organizou o processo de desenvolvimento, proporcionando um estudo de caso bem
elaborado e definido seguindo referencias da Engenharia de Software. A agilidade no
desenvolvimento de sistemas moveis e essencial, pois trata-se de um sistema exuto, que
necessita de constante feedback do cliente.
Desenvolver aplicacoes moveis 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 viavel
o desenvolvimento, o que e uma tarefa difıcil. O Android e uma plataforma nova, em
fase de construcao, possui diversas APIs opicionais para o desenvolvimento, mas ainda
a oferta de dispositivos nao alcanca o mundo todo. Restringir o desenvolvimento ao
Windows Mobile ou Symbian OS tambem nao torna-se viavel, visto que estes suportam
aplicacoes Java ME com a utilizacao de maquinas virtuais Java. O Palm OS e uma
plataforma que esta em decadencia, tanto que a Palm esta disponibilizando aparelhos
com Windows Mobile. A empresa ainda esta investindo em seu SO, porem nao esta
conseguindo superar os outros existentes no mercado. O iPhone possui um SO muito
robusto e atrativo, o que torna o desenvolvimento de aplicacoes para este muito lucrativas,
porem restringe as aplicacoes a apenas este SO. Em contra partida a plataforma Java ME
oferece portabilidade e acessibilidade, alem de concentrar isto em uma unica linguagem.
Referencias Bibliograficas
ADMOB (2009). Admob mobile metrics report. Disponıvel on-line em maio de 2009 no
endereco http://www.admob.com/marketing/pdf/mobile metrics jul 08.pdf.
AGENCIAESTADO (2009). Paıs supera 152 milhoes de celulares em fe-
vereiro. G1. Disponıvel on-line em marco de 2009 no endereco
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 endereco
http://www.apple.com/macosx/technology/.
APPLE (2009b). What is cocoa? Disponıvel on-line em maio de 2009 no endereco
http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/
WhatIsCocoa/WhatIsCocoa.html.
CLAUSEN, D. (2003). Microfloat. Disponıvel on-line em abril de 2009 no endereco
http://www.dclausen.net/projects/microfloat/.
Developers, A. (2009). What is android? Disponıvel on-line em maio de 2009 no endereco
http://developer.android.com/guide/basics/what-is-android.html.
DOEDERLEIN, O. P. (2009). Java: Uma perspectiva. revista Java Magazine, edicao 65.
FLOGGY (2009). Welcome to floggy. Disponıvel on-line em Julho de 2009 no endereco
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 endereco http://www.kobjects.org/kxml/.
INFO (2008). Nokia compra acoes da samsung na symbian. Disponıvel on-line em maio de
2009 no endereco http://info.abril.com.br/aberto/infonews/092008/02092008-13.shl.
59
REFERENCIAS BIBLIOGRAFICAS 60
JCP (2009a). Jsr 271: Mobile information device profile 3. Disponıvel on-line em maio
de 2009 no endereco http://jcp.org/en/jsr/detail?id=271.
JCP (2009b). Jsrs: Java specification requests. Disponıvel on-line em Julho de 2009 no
endereco http://jcp.org/en/jsr/all.
JCP, J. C. P. (2009c). Connected device configuration. Disponıvel on-line em maio de
2009 no endereco http://jcp.org/en/jsr/detail?id=218.
JOHNSON, M. T. (2007). Java para Dispositivos Moveis - Desenvolvendo Aplicacoes com
J2ME. Novatec, 1th edition.
JONES (2009). Qual sera seu proximo 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 endereco
http://www.devmedia.com.br/articles/viewcomp.asp?comp=2099.
LUGON, P. T. R. T. (2005). Floggy: Framework de persistencia para j2me/midp.
LUZ, M. (2009). Midp 3.0: O que vem por ai. a nova especificacao do principal perfil do
java me. Revista Java Magazine, edicao 44.
MATTOS, r. T. d. (2005). Programacao 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 endereco http://www.microsoft.com/brasil/windowsmobile/partners/default.mspx.
MICROSOFT (2009b). Qual e a diferenca entre um pocket pc e um
smartphone? Disponıvel on-line em maio de 2009 no endereco
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, edicao 60.
NOKIA (2008). Jsr 75 fille connection api. Disponıvel on-line em Julho de 2009 no
endereco http://wiki.forum.nokia.com/index.php/JSR 75 File connection API.
PALMBRASIL (2009a). Conheca o palm. Disponıvel on-line em maio de 2009 no endereco
http://www.palmbrasil.com.br/palm-os-webos/conheca-palm.
REFERENCIAS BIBLIOGRAFICAS 61
PALMBRASIL (2009b). Palm os. Disponıvel on-line em maio de 2009 no endereco
http://www.palmbrasil.com.br/vocab/palmos.html.
PITTELLA, F. (2009). Cgi x servlets. Disponıvel on-line em Junho de 2009 no endereco
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 endereco http://www.w3.org/CGI/.
REUTERS (2008). Mundo tera 4 bi de celulares este ano.
Abril. Disponıvel on-line em marco de 2009 no endereco
http://info.abril.com.br/aberto/infonews/092008/25092008-21.shl.
RIM (2009). Visao geral. Disponıvel on-line em maio de 2009 no endereco
http://br.blackberry.com/ataglance/.
SOUSA, A. E. J. (2006). Persistencia em aplicativos para dispositivos moveis com j2me.
Revista WebMobile, edicao 3.
SUN (2002). What’s new in midp 2.0. Disponıvel on-line em maio de 2009 no endereco
http://developers.sun.com/mobility/midp/articles/midp20/.
SUN (2006a). Class command. Disponıvel on-line em maio de 2009 no
endereco 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
endereco 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 endereco
http://java.sun.com/javame/reference/apis/jsr037/.
SUN (2006d). Mid profile. Disponıvel on-line em maio de 2009 no endereco
http://java.sun.com/javame/reference/apis/jsr118/.
SUN (2006e). Summary of cldc-based profiles. Disponıvel on-line em maio de 2009 no
endereco 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 endereco
http://developers.sun.com/mobility/getstart/articles/survey/.
REFERENCIAS BIBLIOGRAFICAS 62
SUN (2008a). Cldc hotspot implementation architecture guide. Disponıvel on-line
em maio de 2009 no endereco 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 endereco 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
endereco 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 endereco http://java.sun.com/javame/technology/index.jsp.
SUN (2009c). Jsr 75 - pda optional packages. Disponıvel on-line em Julho de 2009 no
endereco 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 endereco
http://java.sun.com/developer/technicalArticles/javame/lwuit intro/.
SYMBIANBRASIL (2009). Symbian os. Disponıvel on-line em maio de 2009 no endereco
http://www.symbianbrasil.com/Sobre.
TELES, V. M. (2004). Extreme Programming: Aprenda como encantar seus usuarios
desenvolvendo software com agilidade e alta qualidade. Novatec, 1ed edition.
TEMPLE, Andre; MELLO, R. F. C. D. T. S. M. (2004). Programacao 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 lanca novo software java para celulares. Abril. Disponıvel on-line
em marco de 2009 no endereco http://www.abril.com.br/noticias/tecnologia/sun-lanca-
novo-software-java-celulares-266915.shtml.