• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Desenvolvendo um estudo de caso utilizando a plataforma Java ME
 

Desenvolvendo um estudo de caso utilizando a plataforma Java ME

on

  • 5,909 views

Trabalho de Conclusão de Curso

Trabalho de Conclusão de Curso

Statistics

Views

Total Views
5,909
Views on SlideShare
4,802
Embed Views
1,107

Actions

Likes
1
Downloads
267
Comments
1

4 Embeds 1,107

http://www.javamovel.com 1102
http://static.slidesharecdn.com 2
http://webcache.googleusercontent.com 2
http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Excelente
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Desenvolvendo um estudo de caso utilizando a plataforma Java ME Desenvolvendo um estudo de caso utilizando a plataforma Java ME Document Transcript

    • Coordena¸ao do Curso de Ciˆncia da Computa¸ao c˜ e c˜ Universidade Estadual de Mato Grosso do Sul Desenvolvendo um Estudo de Caso Utilizando a Plataforma Java ME Lais Claudia Zanfolim Rodolfo Chaves Fernandes Andr´ Chastel Lima (Orientador) e Celso G. Camilo Jr (Co-orientador) Dezembro de 2009
    • Desenvolvendo um Estudo de Caso Utilizando a Plataforma Java ME Lais Claudia Zanfolim Rodolfo Chaves Fernandes Este exemplar corresponde a reda¸ao final ` c˜ 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 obten¸ao do t´ c˜ ıtulo de Bacharel em Ciˆncia da Computa¸ao. e c˜ Dourados, 11 de dezembro de 2009. Andr´ Chastel Lima (Orientador) e Celso G. Camilo Jr (Co-orientador) ii
    • Coordena¸ao do Curso de Ciˆncia da Computa¸ao c˜ e c˜ Universidade Estadual de Mato Grosso do Sul Desenvolvendo um Estudo de Caso Utilizando a Plataforma Java ME Lais Claudia Zanfolim Rodolfo Chaves Fernandes Dezembro de 2009 Banca Examinadora: • Andr´ Chastel Lima (Orientador) e • Celso G. Camilo Jr (Co-orientador) • Raquel Marcia M¨ller u • Nielsen Cassiano Sim˜es o iii
    • Resumo A plataforma Java Micro Edition ´ o conjunto de tecnologias que permitem o de- e senvolvimento de aplica¸oes Java para dispositivos com processamento, mem´ria e v´ c˜ o ıdeo limitados, como celulares e smartphones. Assim como as outras edi¸oes Java, essa pla- c˜ taforma foi desenvolvida com o mesmo intuito, a portabilidade, al´m de possuir diversas e APIs para o desenvolvimento, o Java ME tamb´m fornece compatibilidade entre as edi- e ¸oes Java, possibilitando a comunica¸˜o com aplica¸oes constru´ c˜ ca c˜ ıdas em Java SE e Java EE. Mantendo o foco em Java Micro Edition, este trabalho prop˜e o desenvolvimento de o uma aplica¸ao m´vel que una as tecnologias Java ME e Java EE. Como o Java Enterprise c˜ o Edition possui v´rias funcionalidades de redes e Internet e cont´m classes especialmente a e desenvolvidas para acesso a servidores e banco de dados, parte da aplica¸˜o foi constru´ ca ıda usando esta tecnologia, possibilitando a comunica¸ao entre dispositivos m´veis e um servi- c˜ o 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 m´vel atrav´s do protocolo HTTP para estabelecer a comunica¸˜o com o e ca 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 m´vel e o servidor remoto de dados, que alimenta o o sistema m´vel, utilizamos os recursos que a linguagem XML nos oferece. Para auxiliar o 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 aplica¸ao desenvolvida durante o trabalho ´ respons´vel por agilizar o processo c˜ e a de vendas de uma distibuidora de bebidas, a fim de automatizar a for¸a de vendas e foi c testada em celulares e smartphones com o sistema operacional m´vel Symbian e Windows o Mobile, interagindo com o servidor via requisi¸oes HTTP. c˜ 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 aben¸oado durante toda nossa vida c e principalmente por ter nos dado for¸as durante todo o decorrer do trabalho. c Aos nossos familiares, pela confian¸a, apoio e educa¸ao durante toda nossa caminhada. c c˜ Ao nosso orientador Andr´ Chastel Lima, pelo apoio e compreens˜o. e a Ao nosso co-orientador Celso Camilo, pelo incentivo e paciˆncia. e A toda academia, que nos proporcionou as condi¸oes necess´rias para o desenvolvi- c˜ a mento deste trabalho, em especial os professores Odival Faccenda e Glaucia Gabriel Sass. Aos funcion´rios da eXclaim, por nos dar a oportunidade de estagiar na empresa e a 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 n˜o tiveram seus nomes inclu´ a ıdos aqui. vi
    • Sum´rio a Resumo iv Abstract v Agradecimentos vi 1 Introdu¸˜o ca 3 1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2 Sistemas operacionais para dispositivos m´veis o 6 2.1 Dispositivos M´veis . . . . . . . . . . . . . . . . o . . . . . . . . . . . . . . . 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 An´lise do Mercado . . . . . . . . . . . . . . . . a . . . . . . . . . . . . . . . 10 3 Java Micro Edition 11 3.1 Vis˜o geral . . . . . a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2 Configura¸˜es . . . co . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3 Perfis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.4 M´quinas Virtuais a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.5 Pacotes Opcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 vii
    • 4 Perfil MIDP 17 4.1 Vis˜o Geral do MIDP . . . . a . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Comunica¸˜o com o Servidor ca 35 6.1 A Plataforma Java EE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.1.1 Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 6.2 XML - Linguaguem de marca¸˜o extens´ ca ıvel . . . . . . . . . . . . . . . . . . 38 6.2.1 An´lise de documentos XML . . . . a . . . . . . . . . . . . . . . . . . 39 7 Estudo de Caso 41 7.1 Extreme programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 7.2 Arquitetura do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 7.3 Vis˜o geral do sistema . . a . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 7.4 Diagrama de Caso de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 7.5 Est´rias . . . . . . . . . . o . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 7.6 Release 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 7.6.1 Itera¸ao A . . . . . c˜ . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 7.6.2 Itera¸ao B . . . . . c˜ . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 7.7 Release 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 7.7.1 Itera¸ao A . . . . . c˜ . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 7.7.2 Itera¸ao B . . . . . c˜ . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 7.8 A Aplica¸˜o . . . . . . . . ca . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 8 Considera¸˜es Finais co 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 comunica¸˜o. . . . . . . . . . . . . . ca . . . . . . . . . . . . . . 42 7.2 Diagrama de Caso de Uso. . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 7.3 Est´ria 1-A: Consulta de produtos. . . . . . . . . o . . . . . . . . . . . . . . 44 7.4 Est´ria 1-B: Consulta e cadastro de clientes. . . . o . . . . . . . . . . . . . . 44 7.5 Est´ria 2-A: Cadastro de pedidos. . . . . . . . . . o . . . . . . . . . . . . . . 45 7.6 Est´ria 2-B: Altera¸˜o de pedidos. . . . . . . . . . o ca . . . . . . . . . . . . . . 45 7.7 Est´ria 2-C: Envio dos dados para o banco central o 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 Autentica¸ao do usu´rio. . . . . . . . . . . . . . . c˜ a . . . . . . . . . . . . . . 50 7.12 Menu principal da aplica¸˜o m´vel. . . . . . . . . ca o . . . . . . . . . . . . . . 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 (Servi¸o de Mensagem Multim´dia) c ı 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 Introdu¸˜o ca Com a expans˜o da Internet e da utiliza¸˜o de aplica¸˜es, surgiram diversas linguagens a ca co de programa¸˜o, tendo destaque as de multiplataforma, como ´ o caso do Java, que pode ca e ser aplicado em diversos setores, como aparelhos eletrˆnicos, telefones celulares, aplica¸oes o c˜ para Web e desktop, entre outros. Levando em considera¸ao os diferentes setores, tornou- c˜ se necess´rio a cria¸˜o de kits de desenvolvimento diferenciados. a ca A proposta inicial parte do interesse pela linguagem de programa¸ao Java, em espe- c˜ c´ ´ ıfico Java Micro Edition - Java ME. E uma plataforma que permite o desenvolvimento de aplica¸˜es Java para dispositivos com processamento, mem´ria e v´ co o ıdeo limitados, tais como celulares e smartphones. Assim como as outras edi¸oes Java, essa tecnologia foi c˜ desenvolvida com o mesmo intuito, a portabilidade, al´m de possuir diversas APIs (Ap- e plication Programming Interface) para o desenvolvimento. O Java ME tamb´m fornecee compatibilidade entre as edi¸˜es Java, possibilitando a comunica¸ao com aplica¸oes Java co c˜ c˜ 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 aplica¸oes embarcadas. c˜ Dentro desta ultima configura¸ao existe uma outra classifica¸ao que define os perfis dos ´ c˜ c˜ dispositivos. No caso de celulares e smartphones a classifica¸ao usada ´ o MIDP, Mobile c˜ e Information Device Profile. Dentro desta classifica¸˜o, se ocorrer a migra¸ao de aplica¸oes ca c˜ c˜ para outros celulares com a mesma configura¸˜o elas n˜o perdem sua funcionalidade ca a (TOPLEY, 2002). Para otimizar o funcionamento de aplica¸oes em celulares a Sun desenvolveu m´quinas c˜ a virtuais Java espec´ ıficas para cada configura¸ao, que manipulam de maneira mais eficiente c˜ 3
    • 1.1. Objetivos 4 a codifica¸˜o desse tipo de dispositivos. ca Com a cria¸ao deste ambiente de desenvolvimento torna-se vi´vel a constru¸˜o de c˜ a ca aplica¸˜es para dispositivos m´veis com maior produtividade e portabilidade (MUCHOW, co o 2001). 1.1 Objetivos O objetivo principal deste trabalho ´ desenvolver um estudo de caso aplicando os prin- e cipais conceitos da plataforma Java ME e utilizar a plataforma Java EE para constru¸˜o ca de um servidor que ser´ respons´vel pela troca de dados com a aplica¸ao m´vel. a a c˜ o Para alcan¸ar o objetivo principal, as seguintes etapas foram efetuadas: c • Fazer um breve estudo sobre as plataformas de dispositivos m´veis; o • Estudar a plataforma Java ME, voltada para dispositivos m´veis; o • Estudar a plataforma Java EE para a constru¸˜o de um servidor remoto; ca • Estudar a comunica¸ao entre o servidor e a aplica¸˜o m´vel; c˜ ca o • Estudar alguns frameworks Java ME e definir quais ser˜o utilizados no estudo de a caso; • Definir os padr˜es da Engenharia de Software que ser˜o utilizados na aplica¸ao; o a c˜ • Definir o estudo de caso; • Desenvolver e testar o estudo de caso. 1.2 Justificativa Segundo dados divulgados pela Agˆncia Nacional de Telecomunica¸oes (Anatel), o e c˜ n´mero de linhas de telefones m´veis no pa´ chegou a aproximadamente 152,4 milh˜es, u o ıs o ˆ em fevereiro de 2009, o que corresponde a 79,94% da popula¸ao (AGENCIAESTADO, c˜ 2009). Em n´ mundial, o n´mero de usu´rios de telefones m´veis chegou perto de 3 bilh˜es ıvel u a o o em 2007, atingindo 48% da popula¸ao e a estimativa para o final de 2008 era de 4 bilh˜es, c˜ o o que corresponde a 61%, segundo a Uni˜o Internacional de Telecomunica¸oes (UIT) a c˜ (REUTERS, 2008). Segundo Eric Klein, vice-presidente de marketing do Java, em entrevista a Reuters, o ` Java est´ instalado em 2,6 bilh˜es de telefones em todo o mundo (VIRKI, 2009). Visto a o
    • 1.3. Metodologia 5 que o n´mero de usu´rios de aparelhos celulares ´ significativo, que est´ em crescimento e u a e a que a plataforma Java ME ´ bem aceita pelo mercado de software para dispositivos m´veis e o e tamb´m est´ em ascendˆncia no mercado, o desenvolvimento para esta plataforma se e a e torna bastante atraente. 1.3 Metodologia Mantendo o foco em Java Micro Edition, propomos fazer uma revis˜o bibliogr´fica dos a a conceitos chaves desta plataforma e desenvolver uma aplica¸ao para celular ou smartphone c˜ que una as plataformas Java ME e Java EE. Como o Java Enterprise Edition possui v´riasa funcionalidades de redes e Internet e cont´m bibliotecas especialmente desenvolvidas para e acesso a servidores e banco de dados, parte da aplica¸˜o ser´ constru´ usando esta ca a ıda plataforma, possibilitando a comunica¸ao entre dispositivos m´veis e um servidor disposto c˜ o na rede ou Internet. A plataforma Java EE cont´m uma s´rie de especifica¸oes, cada uma com funciona- e e c˜ lidades distintas, entre elas, utilizamos servlets, utilizados para o desenvolvimento Web com conte´do dinˆmico e cont´m uma API que simplifica os recursos do servidor Web u a e para o programador (HALL, 1998). Foi realizado um levantamento de diferentes frameworks Java ME e os que se apresen- taram mais vi´veis para o desenvolvimento da aplica¸ao foram utilizados. a c˜ 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 aplica¸˜o m´vel. ca o O estudo de caso foi desenvolvido com base na metodologia agil extreme programming ´ - (XP), e diagramas da UML ser˜o apresentados para o melhor entendimento da aplica¸ao. a c˜ Os testes foram realizados em celulares e smartphones com o sistema operacional Symbian e Windows Mobile com a configura¸ao CLDC 1.1 e perfil MIDP 2.1, por´m a c˜ e aplica¸˜o poder´ ser executada em outros sistemas operacionais m´veis que possuam uma ca a o m´quina virtual Java compat´ com estas caracter´ a ıvel ısticas.
    • Cap´ ıtulo 2 Sistemas operacionais para dispositivos m´veis o A tecnologia da informa¸˜o atinge a maior parte das empresas e institui¸˜es de forma ca co que fiquem dependentes de sistemas que ajudam ou otimizam o trabalho e a comunica¸ao c˜ dentro das mesmas. Com a massifica¸ao de computadores e Internet surge um outro c˜ conceito: Mobilidade. O poder de carregar as informa¸oes para qualquer ambiente ´ c˜ e evidentemente util para empresas que trabalham com base de dados e um fator essencial ´ para se destacar no mercado ´ ter acesso as informa¸oes em tempo real. e c˜ Sendo evidente o impacto que solu¸˜es de softwares m´veis tˆm e ter˜o nos pr´ximos co o e a o anos, ´ de extrema importˆncia conhecer os sistemas operacionais m´veis do mercado e a o e quais tipos de aplica¸oes cada um deles suporta. Assim, ´ apresentada uma breve c˜ e an´lise dos principais sistemas operacionais para dispositivos m´veis mais importantes da a o atualidade. Neste cap´ ıtulo tamb´m s˜o explanados os principais tipos de dispositivos m´veis e suas e a o tecnologias, visando uma abordagem completa dos requisitos necess´rios para construir a aplicativos de sucesso. 2.1 Dispositivos M´veis o Primeiramente ´ importante esclarecer que o termo Palm ´ utilizado para PDAs (As- e e sistente Pessoal Digital) ou Handhelds, que s˜o computadores de m˜o que fornecem as a a fun¸˜es b´sicas de um computador pessoal, como acesso a Internet, programas de cadas- co a tros, agenda, controle financeiro, controle de vendas, planilhas, documentos entre outras aplica¸˜es da categoria (PALMBRASIL, 2009a). co O smartphone ´ uma categoria de telefone celular com caracter´ e ısticas que antes eram encontradas somente em Palms e PCs (Personal Computers). PoketPC ´ o nome que e 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´ a toque, suporte wi-fi, bluetooh, integra¸ao ıvel c˜ com GPS (Global Positioning System), enfim, tecnologias que o tornam mais robusto (MICROSOFT, 2009b). 2.2 Sistemas Operacionais e suas tecnologias Nesta se¸ao abordaremos as principais caracter´ c˜ ısticas dos sistemas operacionais m´veis o mais utilizados no mercado, bem como suas tecnologias. 2.2.1 Symbian Come¸aremos ent˜o com o sistema operacional para telefones m´veis que desde 1998 c a o lidera o mercado mundial, o Symbian OS, ou simplesmente Symbian. Ele possui suporte MMS (Multimedia Messaging Service), bluetooh, wireless, infra-vermelho, entre outras fun¸˜es que tornam-se extremamente importantes quando o assunto ´ mobilidade. Este co e SO possui um sistema gr´fico bem simples e atualmente ´ o sistema mais usado pelos a e maiores fabricantes de telefones m´veis do mundo, por´m com o surgimento de novas o e tecnologias e plataformas, vem apresentando queda. Por ser um sistema operacional que controla muito bem o consumo de mem´ria, o consumo de energia, o processamento, o entre outros fatores essenciais, as empresas mais poderosas da telecomunica¸˜o investiram ca bastante para que este fosse um sistema promissor para o mercado. Empresas como Nokia, Samsung, Panasonic, Ericsson e Sony Ericsson, foram as res- pons´veis pela ascendˆncia desse modelo de sistema operacional m´vel. Segundo a INFO a e o (2008), atualmente a Nokia possui a totalidade das a¸˜es da empresa britˆnica de software co a (Symbian), liderando o mercado mundial com 38,9% de participa¸ao e promete concorrer c˜ com o mais novo sistema operacional para dispositivos m´veis - Android. o O Symbian suporta sistemas divididos em m´dulos, desta forma cada empresa pode o criar sua pr´pria interface. Permite o uso de v´rias linguagens de programa¸ao, entre o a c˜ as mais importantes est˜o: Symbian C/C++, Java ME, FlashLite, Perl, Python, Ruby, a entre outras. Assim se o aparelho n˜o possui certa funcionalidade, fica f´cil de integrar a a a mesma (SYMBIANBRASIL, 2009). 2.2.2 Android O Android ´ um sistema operacional baseado em Linux voltado para smartphones, e criado pela Google em cons´rcio com mais de 40 empresas. Utiliza uma m´quina virtual o a que foi projetada para otimizar a mem´ria e os recursos de hardware em um ambiente o
    • 2.2. Sistemas Operacionais e suas tecnologias 8 o ´ m´vel. E a primeira plataforma open source para desenvolvimento de aplica¸˜es m´veis, co o portanto ´ livre para incorporar novas tecnologias. Por ser um SO mais novo no mercado e est´ em aceita¸˜o, positiva por sinal, pelos usu´rios e desenvolvedores, pois agrega todas a ca a ´ as funcionalidades que os aparelhos m´veis mais atuais fornecem. E importante ressaltar o que os servi¸os da Google passam a ser facilmente acoplados com as tecnologias m´veis c o ap´s o surgimento do Android, j´ que o interesse e os investimentos atuais da empresa o a visam a mobilidade. Entre os servi¸os oferecidos est˜o: Cliente de e-mail, programa para SMS (Short Mes- c a sage Service), calend´rio, mapas, navegador e gerenciador de contatos. Tudo constru´ a ıdo em Java, desta forma os desenvolvedores Java podem construir aplicativos e disponibiliz´- a los. Os desenvolvedores tem acesso a mesma API utilizada nos aplicativos centrais, po- dendo aproveit´-las livremente. a Al´m dos aplicativos feitos em Java, o Android possui um conjunto de bibliotecas e C/C++ usadas por diversos componentes que permitem trabalhar com arquivos de m´ ıdia, exibi¸ao de conte´do em 2D e 3D, inclusive bibliotecas implementadas utilizando OpenGL c˜ u (Open Graphics Library) e um poderoso banco de dados relacional, o SQLite (Developers, 2009). 2.2.3 Windows Mobile Windows Mobile ´ um sistema operacional para dispositivos m´veis, projetado para e o realizar boa parte das fun¸˜es existentes no Windows para PC. Ele pode ser instalado co em PDAs, PocketPC, smartphones e aparelhos de multim´ ıdia em geral. (MICROSOFT, 2009b). Possui uma interface intuitiva, ´ seguro, permite acesso a Internet, inclusive envio e e recebimento de e-mails, possui conectividade bluetooth e wi-fi, al´m de vers˜es m´veis e o o 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, al´m de possuir um interpretador para PHP (MICRO- e SOFT, 2009a). 2.2.4 Palm OS Palm OS ´ um sistema operacional desenvolvido pela PalmSource para rodar em PDAs. e Entre as vers˜es da linha temos: O Palm OS Garnet e, o atualmente mais usado, Palm o OS Cobalt. No Palm OS Cobalt o sistema roda em 32 bits, possibilitando que os aplicativos fiquem muito mais r´pidos e com recursos extras. No Palm OS Garnet (5.x) apenas algumas a partes dos aplicativos s˜o em 32 bits, j´ que maior parte simula processadores antigos da a a
    • 2.2. Sistemas Operacionais e suas tecnologias 9 Motorola. A desvantagem ´ que as aplica¸oes criadas utilizando os novos recursos n˜o e c˜ a ir˜o funcionar em equipamentos com vers˜es anteriores do sistema. a o As linguagens mais utilizadas para o desenvolvimento de aplica¸oes no Palm OS ´ c˜ e o Pascal e o C/C++. Vale ressaltar que a ultima possui uma grande quantidade de ´ frameworks e ´ mais usada no desenvolvimento de jogos. Importante dizer que existem e aplicativos que convertem aplica¸˜es em Java para que possam ser utilizadas em Palm co OS, uma otima sa´ para escapar do padr˜o de desenvolvimento em palms. Existem ´ ıda a ainda outras linguagens para Palm OS, mas que n˜o possuem tantos recursos, tais como: a 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, ´ o caso da Handheld Basic (HB++), e que ´ muito bem aceita pela comunidade de desenvolvedores . O PocketStudio ´ outra e e ferramenta de desenvolvimento do tipo RAD, semelhante ao Delphi, que ajuda muitos desenvolvedores a construir aplica¸oes com maior facilidade para o Palm OS. Atualmente c˜ essas s˜o as mais usadas no desenvolvimento de aplica¸˜es comerciais para palms. a co Ap´s a PalmSource ser comprada pela Access as pr´ximas vers˜es devem ser baseadas o o o no sistema operacional Linux. Atualmente os dispositivos palms est˜o sendo comerciali- a zados tamb´m com Windows Mobile justamente pelas restri¸˜es para o desenvolvimento e co no sistema operacional Palm OS (PALMBRASIL, 2009b). 2.2.5 BlackBerry OS O BlackBerry OS ´ o sistema operacional para smartphones BlackBerry da empresa e Canadense RIM (Research in Motion). O SO possui como ponto sobressalente a sua consagrada ferramenta de sincroniza¸ao de e-mails. Assim que o servidor recebe o e-mail c˜ este ´ enviado para o dispositivo. Inicialmente deixava a desejar no quesito design, por´m e e passa por constantes aprimoramentos neste quesito e em outros recursos. Suas vers˜es o mais atuais apresentam recursos como menus recolh´ ıveis, navega¸ao por fotos, gerenciador c˜ de arquivos dedicado e oferece suporte para aplicativos desenvolvidos em Java ME (RIM, 2009). ´ E o terceiro sistema operacional para dispositivos m´veis mais vendido do mundo e o o segundo dos Estados Unidos. Teve um crescimento muito r´pido, chegando a ser o mais a vendido nos Estados Unidos no primeiro trimestre de 2009 (ADMOB, 2009). 2.2.6 Iphone OS O Iphone OS ´ o sistema operacional propriet´rio do Iphone, desenvolvido pela Apple. e a 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. An´lise do Mercado a 10 linha com uso de 64 bits, proporcionando a mais r´pida implementa¸˜o de javascript e a ca acesso a Web, chegando a ser 53 vezes mais r´pido quando usa o mini navegador Safari. a Outra poderosa tecnologia implementada ´ o OpenCL(Open Computing Language) que e possibilita aos desenvolvedores maior otimiza¸ao em aplica¸˜es que usam recursos gr´fi- c˜ co a cos. Possui uma tecnologia de multicondutores que agiliza a distribui¸˜o de tarefas em ca multiplos processadores (APPLE, 2009a). Em compara¸˜o ao Android por exemplo, ´ not´vel que o sistema operacional do ca e a Iphone ´ muito superior em qualidade e eficiˆncia, ainda mais se compararmos o acesso a e e Web, pois o Iphone j´ conquista e domina o mercado e n˜o deixa a desejar em nenhum a a aspecto, com exce¸ao do custo. A linguagem de desenvolvimento para o iPhone ´ o c˜ e Objective-C, que ´ muito utilizada na plataforma MAC. Ela ´ orientada a objetos e e e difere do C no acr´scimo de transmiss˜o de mensagens, ao estilo da linguagem Smalltalk. e a Tamb´m existem iniciativas Open Source para converter c´digos em Python para C ou e o tamb´m de Java para Objective-C. e Para desenvolver aplicativos para o Iphone OS ´ necess´rio utilizar o Cocoa, um con- e a junto de frameworks orientado a objetos que disponibiliza um ambiente de execu¸ao para c˜ as aplica¸oes serem executadas em MAC OSX e Iphone OS. E ´ c˜ ´ o unico ambiente de apli- ca¸ao para Iphone OS. As aplica¸˜es existentes no MAC OSX e no Iphone OS s˜o Cocoa, c˜ co a portanto para desenvolver aplica¸oes Java para o sistema operacional do Iphone ´ neces- c˜ e s´rio usar ferramentas que convertem o c´digo Java para a implementa¸ao da biblioteca a o c˜ Cocoa. Tamb´m existem frameworks para converter Python, Ruby, Perl, C# e Objective- e Basic em Objective-C, utilizando o Cocoa (APPLE, 2009b). 2.3 An´lise do Mercado a As plataformas da Apple, Google e Palm s˜o, hoje, as que mais se destacam no mer- a cado mundial. Segundo JONES (2009), analista de mobilidade e tecnologias sem fio do Gatener, a Microsoft est´ lutando para sobreviver no celular, pois se voltou demais para a o mercado corporativo e deixou de lado o mercado dom´stico, ficando fraca diante do e iPhone, Symbian e Android. Apenas trˆs plataformas devem sobreviver, mas ´ dif´ dizer hoje exatamente quais e e ıcil ´ s˜o. ”E uma batalha de ecossistemas que dependem de fatores como recursos do equi- a pamento, estilo, pre¸o e oferta de aplicativos e n˜o s´ da plataforma em si.” (JONES, c a o 2009).
    • Cap´ ıtulo 3 Java Micro Edition Neste cap´ ıtulo s˜o apresentadas as caracter´ a ısticas da plataforma Java Micro Edition (Java ME), bem como suas tecnologias e arquitetura. 3.1 Vis˜o geral a Segundo a SUN (2009b), o Java ME ´ uma cole¸˜o de tecnologias e especifica¸oes que criam e ca c˜ uma plataforma que se ajusta aos requisitos de dispositivos m´veis tais como produtos de o consumo, dispositivos embarcados e dispositivos m´veis avan¸ados. o c O Java ME ´ a plataforma Java voltada para dispositivos que possuam capacidade de e mem´ria, tela e processamento restritos. Foi constru´ com o objetivo de fornecer um o ıda ambiente de execu¸˜o Java capaz de lidar com as caracter´ ca ısticas particulares de pequenos dispositivos. Para utilizar a mesma plataforma em dispositivos diferentes o Java ME foi baseado em trˆs elementos, especificados pela comunidade JCP, que define todos requisitos da e plataforma Java, incluindo a especifica¸˜o de APIs. Os trˆs elementos citados s˜o: Con- ca e a figura¸oes, perfis e pacotes opcionais, os quais funcionam sobre uma m´quina virtual c˜ a 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. Vis˜o geral a 12 Figura 3.1: Elementos da plataforma Java ME. Na camada de configura¸ao s˜o definidas as bibliotecas necess´rias para o funciona- c˜ a a mento da m´quina virtual. A JCP especificou o Java ME em duas configura¸oes de acordo a c˜ 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 ´ destinada a dispositivos com maior capacidade de mem´ria e processamento, e o como TV digital, dispositivos sem fio de alto n´ e sistemas automotivos. ıvel Dentro da configura¸ao existe uma outra classifica¸˜o, os perfis. Estes formam um c˜ ca conjunto de aplica¸oes que complementa uma configura¸ao e fornece funcionalidades para c˜ c˜ desenvolver um aplicativo para determinado dispositivo. O perfil associado a CLDC ´ o MIDP (Mobile Information Device Profile). E os asso- e ciados a CDC s˜o: FP (Foundation Profile), PP (Personal Profile), PBP (Personal Basis a Profile), RMIP (Remote Method Invocation Profile) e GP (Game Profile) (JOHNSON, 2007). Os principais pacotes opcionais est˜o inseridos em um conjunto de APIs utilizadas com a as configura¸oes e perfis para estender funcionalidades n˜o encontradas nos respectivos c˜ a pacotes, como APIs para bluetooh e wireless. Quanto a m´quina virtual, a JCP especifica a CDC HotSpot Implementaion e a CLDC a HotSpot Implementation, que substitu´ ıram respectivamente a CVM (Compact Virtual Machine), vinculada a configura¸˜o CDC e a KVM (Kilo Virtual Machine), vinculada a ca CLDC. A Figura 3.2 mostra a arquitetura da plataforma Java.
    • 3.2. Configura¸oes c˜ 13 Figura 3.2: Arquitetura da plataforma Java. 3.2 Configura¸oes c˜ A configura¸˜o define uma especifica¸ao padr˜o para uma mesma classe de dispositivos, ca c˜ a definidos por caracter´ ısticas individuais de hardware, como interface, processamento, me- m´ria, v´ o ıdeo, tipo de conex˜o de rede, entre outras (TOPLEY, 2002). Esta camada possui a as bibliotecas b´sicas da linguagem, representando a plataforma m´ a ınima de desenvolvi- mento para cada tipo de dispositivo. Tais configura¸oes s˜o definidas pelos fabricantes a c˜ a fim de proporcionar um ambiente de desenvolvimento para funcionar em um determinado dispositivo. Cada configura¸ao consiste de uma m´quina virtual Java (Java Virtual Machine - c˜ a JVM), seja da Sun, do pr´prio fabricante, ou de terceiros e de uma cole¸ao de classes o c˜ Java. Devido as restri¸oes de hardware dos dispositivos m´veis, as m´quinas virtuais c˜ o a utilizadas na plataforma Java ME n˜o suportam todas as caracter´ a ısticas da linguagem Java, instru¸oes bytecodes e softwares de otimiza¸ao providenciados pela plataforma Java c˜ c˜ SE n˜o s˜o suportados, sendo assim diferentes das demais JVMs (TOPLEY, 2002). a a A JCP especificou duas configura¸oes para Java ME, CLDC e CDC. Dentre elas abor- c˜ daremos a configura¸ao CLDC, visto que esta aborda celulares e smartphones, cujo ´ o c˜ e objetivo deste trabalho. A Connected, Limited Device Configuration - CLDC ´ a configura¸˜o m´ e ca ınima do Java ME, formada por um subconjunto de pacotes dispon´ ıveis na plataforma Java para desktop
    • 3.2. Configura¸oes c˜ 14 e abrange os dispositivos com grandes restri¸˜es de processamento, mem´ria e v´ co o ıdeo, como celulares, smartphones, pagers e PDAs. Os dispositivos desta configura¸ao tˆm pelo menos 16 ou 32 bits, 160k de mem´ria c˜ e o n˜o vol´til (onde s˜o armazenadas as bibliotecas e a m´quina virtual), fonte limitada de a a a a energia e pelo menos 16 Mhz de velocidade. Al´m disso ´ necess´rio 192k de mem´ria e e a o para a plataforma Java e suportar conex˜o com rede sem fio, por´m com capacidade de a e transmiss˜o limitada (JOHNSON, 2007). a A CLDC est´ dispon´ nas vers˜es 1.0 (JSR 30) e 1.1 (JSR 139) (SUN, 2006e). A a ıvel o principal caracter´ıstica da vers˜o 1.0 ´ a ausˆncia de opera¸oes que use ponto flutuante, a e e c˜ por´m j´ existem classes que simulam esta propriedade para dada configura¸˜o (CLAU- e a ca SEN, 2003). Segundo a SUN (2007), as classes desta configura¸˜o est˜o restritas a apenas quatro ca a pacotes: • java.io - Tratamento de entrada e sa´ de dados usando streams (abstra¸ao). ıda c˜ • java.lang - Classes b´sicas da linguagem Java. a • java.util - Classes de utilidades gen´ricas (estruturas de dados e manipula¸ao de e c˜ dados). • java.microedition.io - Exclusivamente da plataforma Java ME, incluindo as classes de conex˜o. a A CLDC 1.1 ´ uma configura¸˜o que engloba os pacotes da vers˜o 1.0 e suporta as e ca a seguintes caracter´ ısticas: • Ponto flutuante - Possibilita opera¸oes com vari´veis do tipo float/double. c˜ a • ClassLoading - Classe abstrata respons´vel por carregar outras classes. a • Garbage Collector - Coletor de lixo dos objetos. • Finalize() - Com esse m´todo ´ poss´ liberar recursos e executar outras opera¸˜es e e ıvel co 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 m´quina a virtual acessar bibliotecas acessadas com o c´digo nativo de um sistema. o • ThreadGroups - Possibilita que os processos sejam executados simultaneamente, possibilitando a organiza¸ao das threads em grupos. A multiThreading suporta c˜ m´ltiplas linhas de execu¸ao atrav´s das fun¸oes start(), interrupt(), pause(), re- u c˜ e c˜ 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 m´quinas Java. a 3.3 Perfis Perfil ´ definido como um conjunto de APIs que especificam o n´ de interface de e ıvel aplica¸˜es para um classe de dispositivos (JCP, 2009c). Assim um perfil pode especificar co v´rios tipos de servi¸os e funcionalidades de alto n´ a c ıvel, como o ciclo de vida da aplica¸ao, c˜ elementos de interface gr´fica, persistˆncia de dados e meios de comunica¸˜o. Um perfil ´ a e ca e implementado no topo de uma configura¸ao, sendo assim intimamente ligado a esta, po- c˜ r´m compreende bibliotecas mais espec´ e ıficas que as disponibilizadas pelas configura¸oes, c˜ ou seja, o perfil complementa a configura¸ao adicionando classes que fornecem caracte- c˜ r´ ısticas apropriadas para um tipo particular de dispositivos. Tanto os perfis quanto as configura¸oes s˜o especifica¸˜es de baixo n´ c˜ a co ıvel. As aplica¸oes m´veis s˜o portanto constru´ c˜ o a ıdas sobre configura¸˜es e perfis e podem co apenas usar bibliotecas especificadas por estas. Uma configura¸ao pode conter v´rios c˜ a perfis, por´m um perfil ´ ligado somente a uma configura¸ao. E um perfil ainda pode ter e e c˜ outros perfis ligados a ele (TOPLEY, 2002). Para a configura¸˜o CLDC temos o perfil MIDP (Mobile Information Device Profile ca - JSR 37 ), que ´ amplamente utilizado e providencia o desenvolvimento para pequenos e dispositivos, de recursos limitados e com capacidade de conex˜o sem fio, como os celulares, a smartphones e alguns PDAs. No pr´ximo cap´ o ıtulo ser˜o abordados mais detalhes sobre o a perfil MIDP. 3.4 M´quinas Virtuais a A Sun especifica duas m´quinas virtuais para a configura¸ao CLDC: KVM e CLDC a c˜ HotSpot Implementation. • KVM ´ E uma m´quina virtual com fun¸oes reduzidas, com uma pequena mem´ria e com a c˜ o um coletor de lixo (garbage collector ) incorporado para a otimiza¸ao da mem´ria c˜ o (TOPLEY, 2002). Esta ´ uma VM (Virtual Machine) especificada pela SUN, que e implementa as necessidades e restri¸oes impostas pela configura¸˜o CLDC. O K do c˜ ca termo KVM surgiu para fazer alus˜o aos poucos kilobytes necess´rios para que a a a VM execute uma aplica¸ao. Ela n˜o compila o c´digo e sim o interpreta para o c˜ a 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 mem´ria restrita que os pequenos o dispositivos oferecem. Esta m´quina virtual suporta CLDC 1.0 e 1.1, por´m agora a e exige do processador pelo menos 32 bits com uma velocidade de clock de 60 MHz, 600KB de mem´ria RAM e 2 MB de mem´ria flash e ROM. Aplica tecnologias o o utilizadas na plataforma Java SE e Java EE, incorpora diversos designs inovadores, diminui o tempo de in´ ıcio das aplica¸oes, oferece vida longa a bateria e possui c˜ compila¸˜o dinˆmica das instru¸oes de bytecode em instru¸oes nativas, chamada de ca a c˜ c˜ compila¸˜o Just-in-time (SUN, 2008a). ca Segundo LUZ (2009), a compila¸˜o Just-in-time ´ uma das mudan¸as mais impor- ca e c tantes, pois a compila¸˜o dinˆmica pode ser cinquenta vezes mais r´pida que uma ca a a instru¸ao interpretada. c˜ 3.5 Pacotes Opcionais Pacotes opcionais s˜o componentes muito importantes da plataforma Java ME. Po- a demos enxergar como extens˜es de perfis, al´m de oferecerem apoio em ´reas com fun- o e a cionalidades restritas que alguns dispositivos e aplica¸oes precisam, tais como troca de c˜ mensagens, multim´ ıdia, servi¸os e localiza¸ao geogr´fica. c c˜ a 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 s˜o definidos a pela JCP, estes pacotes tamb´m s˜o chamados de APIs. Podendo ser obrigat´rios ou e a o n˜o, tal decis˜o cabe aos desenvolvedores ou fabricantes inclu´ a a ı-los em um determinado produto. Os pacotes opcionais passam por um processo de aprova¸ao atrav´s da MSA (Mobile c˜ e Service Architecture) ap´s serem constru´ o ıdos pelos desenvolvedores. Depois de aprovados s˜o disponibilizados seguindo as especifica¸oes da JCP. Alguns exemplos de pacotes opcio- a c˜ nais s˜o: API para suporte bluetooth (JSR 82), API para acesso as funcionalidades nativas a do aparelho como agenda, calend´rio e acesso a arquivos (JSR 75 - File Connection API ), a API de seguran¸a e servi¸os confi´veis (JSR 177), entre outras (SUN, 2009a). c c a
    • Cap´ ıtulo 4 Perfil MIDP Neste cap´ıtulo s˜o apresentadas as caracter´ a ısticas do perfil MIDP, bem como o fun- cionamento de uma aplica¸ao. Ser˜o apresentados os principais conceitos relacionados ` c˜ a a interface e armazenamento persistente. 4.1 Vis˜o Geral do MIDP a O MIDP - Mobile Information Device Profile ´ um perfil suportado pela configura¸˜o e ca CDLC, onde juntos providenciam um ambiente padr˜o de execu¸ao Java para os mais a c˜ populares dispositivos m´veis, como os celulares e PDAs. Este perfil provˆ um conjunto de o e bibliotecas e classes que fornecem suporte ao desenvolvimento de aplica¸˜es que referem- co se a diferentes aspectos, como sistema de armazenamento persistente, interface com o usu´rio, transa¸oes seguras, gerˆncia de sons, entre outros. a c˜ e De acordo com JOHNSON (2007), o MIDP apresenta diversas funcionalidades, entre elas est˜o a reprodu¸ao de multim´ a c˜ ıdia, suporte a protocolos dos tipos HTTP e sockets, suporte ao sistema de cores RGB, defini¸˜o de formul´rios e itens, APIs para jogos e ca a valida¸ao de permiss˜es de seguran¸a e assinaturas digitais. c˜ o c Segundo a SUN (2006e), os recursos m´ ınimos de hardware do perfil MIDP s˜o: a • 130KB de mem´ria n˜o vol´til para persistˆncia de dados e bibliotecas da CLDC o a a e • 32KB de mem´ria vol´til para a execu¸˜o do Java o a ca • Conectividade com algum tipo de rede sem fio • Interface gr´fica a • Uma tela de pelo menos 96 pixels de largura por 54 de altura 17
    • 4.1. Vis˜o Geral do MIDP a 18 Alguns recursos m´ ınimos de software tamb´m s˜o requeridos, tais como: possuir re- e a cursos suficientes para executar a m´quina virtual Java, tratamento de exce¸oes, pro- a c˜ cessamento de interrup¸˜es, acesso de leitura e escrita ` rede sem fio, mecanismos para co a capturar a entrada de dispositivos de entrada, recursos para ler e gravar em mem´ria n˜o o a vol´til, oferecendo suporte persistente aos dados e escrita de elementos gr´ficos na tela a a (JOHNSON, 2007). As especifica¸˜es deste perfil s˜o definidas pela JCP, definindo uma plataforma para co a desenvolvimento seguro e dinˆmico. Atualmente o MIDP possui as vers˜es 1.0 (JSR a o 37), 2.0 (JSR 118), 2.1 (JSR 118) e 3.0 (JSR 271). Por´m esta ultima ainda n˜o est´ e ´ a a dispon´ ıvel para utiliza¸ao. A vers˜o 1.0 trabalha integrada com a configura¸˜o CLDC c˜ a ca 1.0 ou 1.1. N˜o tem nenhuma API ativa para renderiza¸˜o, n˜o oferece suporte para a ca a acesso direto aos pixels de imagens, n˜o tem suporte para full screen/full canvas sem a uma API propriet´ria e tamb´m n˜o possui suporte direto para audio. Inclui APIs para a e a ´ o ciclo de vida de aplica¸˜es, conectividade de redes HTTP, interface com o usu´rio e co a armazenamento persistente. O unico protocolo de rede que o MIDP 1.0 suporta ´ o ´ e HTTP (SUN, 2002). Segundo a SUN (2006c), os pacotes suportados pela vers˜o 1.0 s˜o: a a • javax.microedition.io - Fornece suporte ao framework GenericConnection da confi- gura¸ao CLDC. c˜ • javax.microedition.lcdui - API que providencia um conjunto de caracter´ ısticas para a implementa¸˜o de interfaces com o usu´rio. ca a • javax.microedition.rms - Providencia um mecanismo de persistˆncia de dados para e MIDlets. • javax.microedition.midlet - O pacote MIDlet define aplica¸oes MIDP e intera¸oes c˜ c˜ entre as aplica¸˜es e o ambiente no qual a aplica¸ao ´ executada. co c˜ e A vers˜o 2.0 ´ compat´ com a vers˜o 1.0 e adiciona novas melhorias como suporte a e ıvel a a conex˜o segura (HTTPS), biblioteca de multim´ ` a ıdia, formul´rio de entrada de dados a aprimorada, sens´ melhoria na API de suporte a games, conceito de aplica¸˜es confi´veis ıvel co a (trusted ) e n˜o confi´veis (untrusted ). Al´m de HTTPS, o MIDP 2.0 suporta HTTP, a a e datagramas, sockets e SMS (Short Message Service). Quanto a multim´ ıdia, um conjunto de APIs foram introduzidas, que s˜o na verdade um subconjunto da Mobile Media API a (MMAPI). Com estas APIs podem ser gerados simples toques, sequˆncias mais completas e ou at´ mesmo m´sicas completas no formato WAV, al´m de poderem ser implementados e u e em outros formatos. Dentre as mudan¸as nos formul´rios de entrada destacam-se a nova aparˆncia do Form c a e que ´ consideravelmente mais sofisticada do que era no MIDP 1.0 e a classe Item, onde e
    • 4.1. Vis˜o Geral do MIDP a 19 agora podem ser especificados layouts horizontais, verticais, novas linhas antes ou depois de itens, entre outros. Um novo item tamb´m foi criado, o Spacer, que serve pra colocar e espa¸amentos entre os demais itens dispon´ c ıveis. Tamb´m foi introduzido o tipo pop up ao e item choiceGroup, que ser´ estudado a frente. a ` No MIDP 2.0 tamb´m foram estendidos os comandos de manuseio. Adicionar co- e mandos aos itens agora ´ permitido. Tamb´m foi introduzida a classe CustomItem, que e e permite ao programador criar seus pr´prios itens. Nesta vers˜o o suporte a jogos ganha o a 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 mudan¸a ´ o surgimento da classe GameCanvas, uma subclasse de c e Canvas - classe de baixo n´ que proporciona o desenvolvimento de jogos. Nesta vers˜o ıvel a as imagens podem ser representadas em arrays de inteiros e tamb´m suporta imagens em e RGB (SUN, 2002). Segundo a SUN (2006d), os pacotes que foram adicionados a esta vers˜o s˜o: a a • javax.microedition.lcdui.game - Providencia classes para o desenvolvimento de con- te´do rico para jogos em dispositivos wireless. u • javax.microedition.media - Compat´ com as especifica¸oes da API Mobile Media ıvel c˜ (JSR 135). • javax.microedition.media.control - Define o tipo espec´ ıfico, control, que pode ser usado como um player. • javax.microedition.pki - Autentica informa¸˜es para conex˜es seguras, atrav´s de co o e certificados. A vers˜o 2.1 do MIDP refor¸a a especifica¸˜o MIDP 2.0 tornando a diretiva layout LC- a c ca DUI obrigat´ria, os pacotes javax.microedition.io.SocketConnection e javax.microedition- o .io.HTTPConnection n˜o s˜o mais opcionais, entre outros requisitos para aprimorar a a a vers˜o 2.0. a A vers˜o 3.0 traz melhor suporte para dispositivos com telas maiores, suporte a MI- a Dlets para desenhar em telas secund´rias, armazenamento RMS seguro e acesso remoto a a bancos RMS (JCP, 2009a). Esta vers˜o requer no m´ a ınimo 1MB de mem´ria vol´til e tela o a de pelo menos 176x220 pixels. Ela ´ compat´ com o CLDC 1.0, mas o recomendado ´ e ıvel e o 1.1 e possui compatibilidade com as outras vers˜es do MIDP. No MIDP 3.0 a tela de o 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 atrav´s de um atributo no e arquivo JAD, um arquivo de descri¸ao da aplica¸ao, que ser´ explicado posteriormente. c˜ c˜ a Os protetores de tela agora s˜o aplica¸˜es que s˜o destru´ a co a ıdas pelo gerenciador quando
    • 4.2. MIDlets 20 alguma tecla ´ pressionada ou algum evento ´ disparado. Al´m destas funcionalidades, e e e o MIDP 3.0 apresenta suporte a IP vers˜o 6, o que possibilita fazer parse de um ende- a re¸o IPv6 e a possibilidade de compartilhar bibliotecas entre os MIDlets em tempo de c execu¸˜o, conhecido como LIBlets (LUZ, 2009). ca 4.2 MIDlets ´ E uma aplica¸ao Java destinada para dispositivos m´veis desenvolvida com a utiliza¸ao c˜ o c˜ do perfil MIDP, que est´ vinculado a configura¸˜o CLDC (MUCHOW, 2001). a ca Todo dispositivo m´vel tem um gerenciador de aplicativos (AM - Application Mana- o ger ) que controla os aplicativos a serem instalados, onde e como ser˜o armazenados e a como ser˜o executados. A comunica¸ao do gerenciador com o MIDlet acontece pela classe a c˜ MIDlet do pacote javax.microedition.midlet.MIDlet. Os MIDlets devem herdar esta classe MIDlet que cont´m m´todos que inicializam, resumem, interrompem a execu¸˜o e des- e e ca troem MIDlets. Uma aplica¸ao ´ iniciada quando o AM invoca o m´todo startApp(), colocando a c˜ e e aplica¸˜o no modo ativo. Enquanto estiver executando ela pode ser pausada pela AM ca atrav´s do m´todo pauseApp(), isto pode ocorrer quando uma chamada for recebida por e e exemplo ou o pr´prio usu´rio pode pausar a aplica¸ao. E quando a aplica¸ao ´ encerrada o a c˜ c˜ e ela passa para o estado destru´ ıdo, atrav´s do m´todo destroyApp(), que limpa todos os e e recursos para fechar a aplica¸˜o (JOHNSON, 2007). ca O ciclo de vida do MIDlet ´ apresentado na Figura 4.1. e Figura 4.1: Ciclo de vida do MIDlet. Estes trˆs m´todos, segundo MUCHOW (2001), trata-se da comunica¸˜o que parte e e ca do gerenciador de aplicativos para o MIDlet. Al´m destes m´todos, tamb´m existem e e e outros trˆs onde a comunica¸ao parte do MIDlet para o gerenciador de aplicativos. Estes e c˜ m´todos s˜o: e a
    • 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 s˜o juntados em um Java Ar- a chive (JAR). E´ composto por classes Java, recursos e um arquivo de manifesto, que est˜o a situados dentro do arquivo JAR e um arquivo de descri¸ao, chamado Java Application c˜ Descriptor (JAD). Dentre os recursos est˜o imagens, dados da aplica¸˜o, entre outros. a ca No arquivo de manifesto, cuja extens˜o ´ .mf, est´ a descri¸ao do JAR. E o arquivo JAD a e a c˜ descreve os detalhes da aplica¸˜o, repetindo muitos do dados que est˜o no arquivo de ca a manifesto, por´m este arquivo est´ fora do JAR e pode ser acessado antes de se insta- e a lar o arquivo JAR no aplicativo (JOHNSON, 2007). As pr´ximas subse¸oes descrevem o c˜ detalhadamente cada um desses arquivos. 4.3.1 JAR Todas as MIDlets s˜o empacotadas antes de serem transferidas a um dispositivo, isso a ´ feito atrav´s de um m´todo de compress˜o onde s˜o colocadas todas as informa¸oes em e e e a a c˜ um unico arquivo cuja extens˜o ´ .JAR. Este arquivo engloba classes Java, recursos e ´ a e informa¸˜es do empacotamento, com citado anteriormente (MUCHOW, 2001). co O arquivo JAR providencia muitos benef´ ıcios, como: seguran¸a, atrav´s de assinaturas c e digitais; compress˜o; empacotamento de extens˜es, juntando v´rios tipos de extens˜es a o a o diferentes em uma unica: o .JAR; portabilidade e o fato de quando ´ necess´rio fazer o ´ e a download de uma aplica¸˜o apenas um arquivo deve ser baixado (SUN, 2008b). ca 4.3.2 JAD Conforme estudado, al´m do JAR ´ criado um arquivo em separado de extens˜o .JAD e e a que cont´m informa¸oes sobre o MIDlet. Este arquivo ´ usado muitas vezes para preparar e c˜ e o JAR para ser instalado, otimizando a instala¸ao do aplicativo, por´m nem todos os c˜ e aparelhos precisam ler o .JAD para realizar a instala¸˜o. O arquivo JAD possui a seguinte ca estrutura: MIDlet-Name: Nome da Suite MIDlet. MIDlet-Version: Vers˜o da MIDlet. a MIDlet-Vendor : Desenvolvedor da MIDlet.
    • 4.4. Interface 22 MIDlet-Icon: Especifica o ´ ıcone da tela inicial da aplica¸ao. c˜ MIDlet-Description: Descri¸˜o da aplica¸˜o. ca ca MIDlet-info-URL: Endere¸o para um arquivo de informa¸oes (JAR). c c˜ MIDlet-DATA-Size: Tamanho dos dados. 4.4 Interface Os dispositivos m´veis que implementam o perfil MIDP possuem diversas restri¸oes o c˜ quando se trata de interface, podendo variar em tamanho de tela, n´mero de cores apresen- u tadas na tela, disposi¸˜o dos bot˜es, etc. E estas informa¸oes s˜o acessadas pela MIDlet ca o c˜ a somente em tempo de execu¸ao. Sendo assim, o MIDP s´ permite a utiliza¸˜o de objetos c˜ o ca visuais simples, n˜o sendo permitida a implementa¸˜o de objetos comuns na vers˜o Java a ca a para desktop (JOHNSON, 2007). O Java ME tem como padr˜o para constru¸ao de interfaces a biblioteca LCDUI, que a c˜ ` ´ respons´vel pelos componentes que formam a interface de aplica¸oes MIDP. Nesta se- e a c˜ ¸ao estudaremos algumas classes desta biblioteca, que est˜o dispostas de acordo com a c˜ 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 m´veis com diferentes o caracter´ısticas de tela, as aplica¸˜es s˜o desenvolvidas com uma certa abstra¸ao. Para co a c˜ acessar as informa¸oes de um determinado aparelho existe a classe Display e cada MIDlet c˜ possui sua pr´pria instˆncia desta classe que pode ser acessada pelo m´todo getDisplay(), o a e que geralmente est´ contido no m´todo startApp(), pois o Display s´ pode ser acessado a e o depois que aplica¸˜o tenha sido iniciada. ca Portanto, a tela do dispositivo ´ representada por uma instˆncia da classe Display, e a que representa o hardware, e para que seja mostrado algo na tela devemos passar um objeto Displayable para o objeto da classe Display. Displayable ´ uma classe abstrata e que controla o que ´ mostrado na tela e os comandos enviados pelos usu´rios. Eles e a representam conte´dos de uma tela na qual h´ intera¸ao com o usu´rio (JOHNSON, u a c˜ a 2007). Cada aplica¸ao possui apenas uma instˆncia da classe Display, sendo assim podem c˜ a existir v´rios objetos Displayable mas apenas um ´ mostrado por vez (MUCHOW, 2001). a e Os objetos Displayable que est˜o na mem´ria, mas n˜o est˜o sendo mostrados est˜o no a o a a a chamado background e o objeto que est´ sendo mostrado est´ no foreground. Portanto os a a objetos que est˜o no background n˜o tem acesso ao Display. Para mostrar um Displayable a a na tela usamos o m´todo setCurrent() e para obter qual objeto est´ sendo mostrado no e a Display usamos o m´todo getCurrent() (JOHNSON, 2007). e A classe Displayable da origem a duas outras classes: Screen e Canvas. Ambas s˜o a classes para representar interfaces, por´m a primeira classe, juntamente com suas subclas- e ses formam componentes de interface de alto n´ e a segunda de baixo n´ (MUCHOW, ıvel ıvel 2001). Screen Screen ´ uma classe que cont´m objetos gr´ficos prontos, onde cada uma pode ter uma e e a aparˆncia, variando de acordo com o dispositivo em que esta sendo executada a aplica¸ao e c˜ (JOHNSON, 2007). Screen e suas heran¸as s˜o classificadas como objetos de interface de c a alto n´ (High-Level APIs) e as heran¸as desta classe s˜o as classes Form, List, Alert e ıvel c a Textbox (MUCHOW, 2001). Form Form ´ um formul´rio o qual pode conter textos, imagens e outros componentes para e a serem exibidos no visor. V´rios componentes podem ser colocados em um Form e se a houver necessidade ele apresenta barra de rolagem autom´tica para mostrar todos estes a componentes visuais. Por´m nada muito extenso ´ vi´vel para aplica¸oes m´veis. e e a c˜ o
    • 4.4. Interface 24 Esses componentes que podem ser adicionados em um Form s˜o subclasses da classe a Item e ser˜o estudados posteriormente. Um Form possui m´todos para adicionar, inserir, a e apagar e substituir componentes. Estes componentes da classe Item s´ pode ser inseri- o dos em um Form e n˜o em outras telas da classe Screen, como List, Alert ou Textbox a (MUCHOW, 2001). Item Conforme mostrado um Item ´ um componente que pode ser inserido em um Form e e suas subclasses s˜o: a • StringItem ´ E um simples texto est´tico, ou seja, n˜o pode ser editado. a a • TextField ´ E um campo para entrada e/ou edi¸ao de texto. Podendo ser associadas regras a c˜ este. Por exemplo: aceitar somente n´meros, qualquer caracter, ser um campo de u senha, entre outros. • ImageItem Permite inserir uma imagem. • ChoiceGroup ´ E uma lista de escolhas, dentro de um Form. Possui os tipos: m´ltiplo, exclusivo u ou pop up. 1. M´ltiplo: Podem ser selecionadas v´rias op¸˜es, marcando uma caixa de che- u a co cagem que acompanha os elementos da lista; 2. Exclusivo: Pode ser selecionado apenas uma op¸ao e esta ´ marcada com um c˜ e radioButton. 3. Pop up: Pode ser selecionada apenas uma op¸ao. A lista ´ exibida como c˜ e uma comboBox, ou seja, os elementos ficam escondidos e quando clicada esta lista toda ´ exibida. Ap´s a sele¸ao de um elementos os outros elementos s˜o e o c˜ a escondidos novamente. • DataField Campo utilizado para exibir e/ou entrar com data e/ou hora.
    • 4.4. Interface 25 • Gauge ´ E uma representa¸ao gr´fica de um n´mero inteiro. Ele permite que o usu´rio c˜ a u a defina um n´ ıvel, como o volume por exemplo, se for um Gauge interativo. Se for n˜o interativo ´ somente o programa que o controla (MUCHOW, 2001). a e • Spacer Determina um espa¸amento vertical e/ou horizontal m´ c ınimo entre os componentes de um Form. Ele ´ utilizado por quest˜es de design de layout. e o • CustomItem Utilizado para criar itens espec´ ıficos, atrav´s de desenhos, utilizando a classe Graphics e da API de baixo n´ (MATTOS, 2005). ıvel List ´ E uma lista que permite ao usu´rio selecionar op¸oes. Estas podem ser tanto uma a c˜ String quanto uma imagem. O List pode ser exclusivo, m´ltiplo ou impl´ u ıcito. Impl´ ıcito ´ e quanto a lista ´ exibida sem nenhum marcador e somente uma op¸˜o pode ser escolhida, e ca gerando um evento quando ´ selecionada uma das op¸oes. Os outros dois tipos funcionam e c˜ igualmente ao ChoiceGroup (MATTOS, 2005). Alert ´ E uma tela de informa¸˜o ao usu´rio. Pode conter uma mensagem de erro, de sucesso, ca a de informa¸ao, entre outras. Ele pode ser programado para ser exibido durante um tempo c˜ pr´ determinado, pode ser composto de um texto e uma imagem e sua aparˆncia varia de e e acordo com o dispositivo m´vel usado (MATTOS, 2005). o TextBox e c˜ ´ Basicamente ´ uma tela que serve para entrada e edi¸ao de texto. E como se fosse um Item textField, por´m s´ existe ele na tela. Em um textBox tamb´m podem ser usadas e o e regras, assim como em um textField (SUN, 2006b). Canvas Canvas ´ uma classe de baixo n´ e ıvel, que proporciona maior liberdade na implementa¸˜o ca a ´ destinada a aplica¸oes que necessitam de posicionamento preciso dos gr´ficos e eventos. E c˜ dos elementos gr´ficos, sendo portanto muito utilizada para a cria¸ao de jogos. a c˜
    • 4.5. Armazenamento Persistente 26 Atrav´s da utiliza¸ao desta classe ´ poss´ desenhar na tela. O desenvolvedor cria e c˜ e ıvel o que ser´ mostrado para o usu´rio final. Para criar uma interface gr´fica com canvas ´ a a a e utilizado a classe Graphics, que fornece m´todos para desenhar linhas, arcos, retˆngulos e a e textos, al´m de especificar cores e fontes (MUCHOW, 2001). e Al´m de desenhar interfaces, a classe canvas permite controlar eventos primitivos, e 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, fun¸˜es, aos objetos mostra- co dos na tela (JOHNSON, 2007). Os comandos s˜o usados para a intera¸ao do usu´rio com a c˜ a a aplica¸˜o podendo ser atribu´ ca ıdos a qualquer Displayable, de alto ou baixo n´ ıvel, e a um Item. Quando um comando ´ acionado pelo usu´rio, ´ notificado a um CommandListener e a e que ´ definido no objeto Displayable. Um command cont´m somente uma informa¸˜o e e ca sobre o comando e n˜o sobre qual a¸ao realizar. A a¸˜o ´ definida no CommandListener a c˜ ca e 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 ´ acionado, o commadAction o captura, juntamente com o Displayable atual e (JOHNSON, 2007). 4.5 Armazenamento Persistente Os dispositivos m´veis que usam o perfil MIDP possuem, como mem´ria vol´til, a o o a mem´ria RAM e, como mem´ria de armazenamento persistente, a mem´ria flash. Esta o o o permite armazenar dados por longos per´ ıodos de tempo, sem a necessidade de ser mantida energizada por uma bateria ou fonte el´trica. e As vantagens da mem´ria flash s˜o: o pequeno tamanho f´ o a ısico, a resistˆncia a choques, e o alto desempenho para a leitura de dados, entre outros. E algumas de suas desvantagens s˜o o fato de as opera¸oes de escrita serem lentas e a capacidade de armazenamento ser a c˜ restrita. Por´m, a maioria dos dispositivos m´veis contam com um cart˜o de mem´ria, e o a o que serve como um drive de armazenamento. O cart˜o oferece solu¸ao ao armazenamento a c˜ restrito, por´m o seu acesso ´ mais lento se comparado com o acesso a mem´ria flash e e o 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. Por´m n˜o s˜o e a a todos os dispositivos que fornecem acesso a esta ultima API (LUGON, 2005). ´ 4.5.1 RMS A API RMS ´ o mecanismo padr˜o para persistˆncia de dados oferecido pelo MIDP. O e a e RMS funciona como um banco de dados orientado a registros, apresentando-se diferente dos tradicionais bancos de dados relacionais conhecidos. Ele ´ composto por Record Stores, e que s˜o como armaz´ns de dados, conforme mostra a Figura 4.3. a e Figura 4.3: Record Management System. Um Record Store ´ identificado por um nome, que ´ case sensitive e ´ criado por um e e e MIDlet. Ent˜o quando um MIDlet ´ removido de um dispositivos todos os Record Stores a e relacionados a ele ser˜o removidos tamb´m. O limite de armazenamento ´ o mesmo que a e e o dispositivo oferecer. A API RMS n˜o suporta tipos caracter´ a ısticos de outros banco de dados, como ta- belas, colunas ou linhas, nela cada registro, chamado Record, ´ um array de bytes. Por e causa disso a aplica¸ao deve converter os dados para array de bytes para poderem ser c˜ 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 ´ um registro (Record ) e estes s˜o identificados por uma chave prim´ria, chamada e a a Record ID, que ´ um inteiro. Logo, cada registro ´ formado por um inteiro e um array de e e bytes. A API fornece m´todos para abrir, fechar e deletar um RecordStore inteiro. Al´m e e destes existem m´todos para a manipula¸˜o dos registros como, adicionar, modificar, e ca deletar, recuperar um registro e a quantidade de registros existentes (SOUSA, 2006).
    • Cap´ ıtulo 5 APIs e Frameworks para Java ME Atrav´s de frameworks e APIs espec´ e ıficas ´ poss´ e ıvel construir aplica¸oes com mais c˜ recursos, dispondo de v´rias funcionalidades extras, que n˜o s˜o encontradas nas especi- a a a fica¸oes do perfil MIDP, al´m de otimizar o desenvolvimento. Este cap´ c˜ e ıtulo lista algumas APIs e frameworks mais utilizados no desenvolvimento de aplica¸˜es para celulares e co 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 aplica¸oes que se conectam a servidores remotos, com c˜ outros aparelhos, aplica¸oes que utilizam bluetooth, que executam m´sicas e v´ c˜ u ıdeos, entre outras. Algumas das APIs opcionais dispon´ ıveis para o perfil MIDP s˜o citadas por a (JOHNSON, 2007). • Java APIs for Bluetooh (JSR 82) - Permite o desenvolvimento de aplica¸oes para c˜ acesso a rede bluetooh. ` • Location API (JSR 179) - Permite o desenvolvimento de aplicativos baseados em localiza¸˜o f´ ca ısica (LBS). • Mobile Game API (JSR 178) - Voltada para cria¸ao de jogos. c˜ • Mobile Media API (JSR 135) - Permite reprodu¸˜o de m´ ca ıdia. • Security and Trust Services API for J2ME (JSR 177) - Usada para adicionar segu- ran¸a as aplica¸˜es. c ` co • 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- ¸oes temos: c˜ • File Connection API (JSR 75) - Permite acesso e armazenamento em arquivos e acesso a programas nativos do dispositivo, como agenda, calend´rio, entre outros. a • Mobile Sensor API (JSR 256) - Permite a recupera¸ao de dados de sensores internos c˜ ou externos ao aparelho celular. • MECHART - Uma API de terceiro, ainda n˜o catalogada pela JCP, que permite a construir gr´ficos de maneira simples e r´pida, sem a necessidade de programar a a diretamente na classe Canvas. Dentre estas, vamos estudar a FileConnection API, pois al´m de ser uma das mais e usadas por desenvolvedores da plataforma Java ME, possui maior reconhecimento e ser´a de grande utilidade para o projeto que desenvolveremos posteriormente. ´ E importante dizer que a JCP at´ o momento tem catalogado 927 JSRs na plataforma e 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 obrigat´rios para a plataforma Java ME: o • O PIM - Pacote que permite desenvolvedores acessar os dados de PIM do aparelho, tais como agenda, livro de endere¸os e listas de tarefas, que existe na maioria dos c dispositivos m´veis. o • O Pacote opcional de conex˜o de arquivos (FCOP) - Permite aos desenvolvedores a 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 m´vel. Isto inclui o dispositivos de armazenamento remov´ ıveis, como cart˜es de mem´ria. o o O PIM e os arquivos de dados permitem a integra¸ao de aplica¸oes com informa¸oes c˜ c˜ c˜ sobre o dispositivo, permitindo aplica¸oes mais inteligentes (SUN, 2009c). c˜ Abaixo est˜o as importantes classes e interfaces: a • ConnectionClosedException - Lan¸ada quando um m´todo ´ invocado em uma Fi- c e e leConnection quando a conex˜o ´ fechada. a e
    • 5.2. Frameworks 30 • FileSystemRegistry - Classe central de registros que possui a habilidade de listar roots montadas atrav´s do m´todo listRoots(). Ela tamb´m providencia m´todos e e e e para os ouvintes de registros (Registering listeners), estes s˜o notificados se sistemas a de arquivos s˜o adicionados ou removidos durante o tempo de execu¸ao. a c˜ • A FileSystemListener interface - Usada para recep¸ao de notifica¸oes de status c˜ c˜ quando ´ adicionado ou removido um sistema de arquivo ra´ e ız. • A FileConnection interface - Usada para acessar diret´rios e arquivos no dispositivo. o Ela estende a Connection interface e mantˆm in´meros m´todos uteis para criar, e u e ´ remover diret´rios e arquivos, lista de conte´do de diret´rios, configurar permiss˜es, o u o o obter informa¸oes de arquivos e efetuar opera¸oes de entrada e sa´ nos arquivo. c˜ c˜ ıda Os pacotes usados s˜o: a • javax.microedition.pim • javax.microedition.io.file No desenvolvimento do estudo de caso foi explorado o pacote opcional de conex˜o de a arquivos (FCOP), dependente apenas do n´cleo de classes definidas pelo CLDC. u A forma de acessar os arquivos ´ utilizando a FCOP atrav´s da interface FileConnec- e e tion, muito usada por sinal. Para isto basta importar o pacote javax.microedition.io.file.- FileConnection. A FileConnection estende StreamConnection pela adi¸˜o de m´todos de arquivo e ca e diret´rio de manipula¸ao. A funcionalidade adicional ´ semelhante a que se encontra o c˜ e dispon´ no J2SE, na classe java.io.File. Para a abertura de um arquivo ´ usado uma ıvel e URL no formato: file://host/path Enfim, com m´todos mais espec´ e ıficos desta API ´ poss´ manipular arquivos dentro e ıvel do aparelho, sem a necessidade de trabalhar com classes de baixo n´ (NOKIA, 2008). ıvel 5.2 Frameworks Entre os frameworks mais utilizados para a otimiza¸ao no desenvolvimento de aplica- c˜ ¸oes para dispositivos m´veis est˜o: c˜ o a • Floggy - Framework para persistˆncia de dados. e • J2MicroDB - Fornece um banco de dados relacional limitado para dispositivos m´- o veis.
    • 5.2. Frameworks 31 • Perst Lite - Banco de dados orientado a objetos para aplica¸˜es embarcadas. co • 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 c´digo fonte. o • Diamont Powder - Acelera a cria¸ao de aplica¸˜es para coleta de dados. c˜ co • Fire (Flexible Interface Rendering Engine) - Framework para o desenvolvimento de interfaces mais atraentes que as compreendidas pelo MIDP. • Marge - Facilita o desenvolvimento de aplica¸oes em Java que fazem uso de bluetooth c˜ Entre os frameworks citados neste trabalho, astrav´s de testes, os que melhor atende- e ram ao desenvolvimento do estudo de caso foram: o Floggy, pois abstrai significativamente a complexidade dos c´digos RMS para a persistˆncia de dados, o LWUIT, que fornece in- o e terfaces bastante atraentes, al´m de estar caminhando para ser o framework referˆncia e e em UI, por fim o KXML, para fazer o parse de XMLs, usado para interpretar os dados trocados entre servidor e aplica¸ao m´vel. c˜ o 5.2.1 Floggy Uma das limita¸˜es impostas pelo perfil MIDP ´ a utiliza¸ao da API RMS, na maioria co e c˜ dos dispositivos, para a persistˆncia de dados. Visando a dificuldade dos c´digos utilizados e o para acessar esta API surgiu o Floggy, framework de persistˆncia free para J2ME/MIDP, e desenvolvido por brasileiros. Seu principal objetivo ´ abstrair os detalhes da persistˆncia e e de dados para o desenvolvedor, reduzindo os esfor¸os de desenvolvimento e manuten¸ao c c˜ (FLOGGY, 2009). O Floggy utiliza comandos de alto n´ para encapsular os comandos necess´rios para ıvel a o armazenamento e recupera¸˜o de objetos, ou seja, o que est´ por tr´s deste framework ca a a s˜o c´digos para acessar a API RMS (LUGON, 2005). a o O framework ´ composto por dois m´dulos: e o - Framework : respons´vel por fornecer os m´todos de persistˆncia como salvar, remover a e e e recuperar os dados, atrav´s de um arquivo JAR (11KB) que deve ser adicionada na e aplica¸˜o. ca
    • 5.2. Frameworks 32 - Compilador: respons´vel por analisar, gerar e compilar o bytecode. Bytecode ´ o a e c´digo bin´rio gerado pelo compilador Java, que mais tarde ser´ interpretado por uma o a a JVM, sendo assim executada uma aplica¸ao (FLOGGY, 2009). c˜ O m´dulo framework apresenta as seguintes classes: o Persistable Funciona como um marcador, assim as classes que o implementam s˜o consideradas a persistentes para o Floggy. PersistableManager ´ E a classe principal do framework, pois gerencia a persistˆncia e permite executar e todas as opera¸oes de persistˆncia, como carregar, salvar, recuperar, remover, listar, entre c˜ e outros. Filter As classes que implementam esta interface definem crit´rios para sele¸˜o dos registros e ca que devem ser listados ou capturados. Comparator As classes que implementam esta interface definem crit´rios para ordenar registros que e foram selecionados. ObjectSet Os resultados de sele¸ao de registros resultam em objetos da classe ObjectSet. Assim c˜ esta classe serve para obter uma lista de registros e funciona como um cursor. PersistableMetaData Re´ne informa¸˜es sobre os objetos de uma determinada classe, como n´mero de u co u objetos, data da ultima modifica¸˜o, entre outros (LUGON, 2005). ca 5.2.2 KXML O KXML ´ um framework que faz o parser de XML, utilizando a t´cnica pull parser, e e que ser´ discutida na se¸ao 6.2.1, do cap´ a c˜ ıtulo 6. Ele ´ utilizado para simplificar e otimizar e
    • 5.2. Frameworks 33 o acesso, parse e exibi¸˜o de XMLs e ´ destinado principalmente a ambientes restritos ca e como em dispositivos que usam o perfil MIDP (HAUSTEIN, 2007). Possui as trˆs vers˜es. A primeira vers˜o foi criada para dispor a t´cnica pull parser e o a e em dispositivos m´veis e embarcados e ´ baseada em eventos de objetos. A segunda vers˜o o e a ´ a vers˜o corrente e possui caracter´ e a ısticas de cursor em vez de se basear em eventos de objetos. A terceira vers˜o ainda est´ sendo produzida. a a Segundo LECHETA (2006), as principais opera¸oes do KXML s˜o: c˜ a • nextTag(): Aponta para o pr´ximo in´ ou fim de tag, pulando eventos insignifi- o ıcio cantes como espa¸os em branco ou coment´rios. c a • Require(): Obriga o cursor a ser posicionado onde for indicado. • nextText(): Exige que a posi¸˜o corrente seja uma tag de in´ ca ıcio. Retorna o texto contido no elemento correspondente. • getName(): Obtˆm o nome da tag na posi¸˜o corrente. e ca Um analisador de XML deveria n˜o aceitar ou reconhecer documentos com erros, a por´m devido as restri¸oes dos dispositivos m´veis isto n˜o ´ poss´ e c˜ o a e ı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 estud´-lo para a aplica¸ao que ser´ desenvolvida (HAUSTEIN, a c˜ a 2007). 5.2.3 LWUIT O LWUIT (LightWeight User Interface Toolkit) ´ um framework para a cria¸˜o de e ca interfaces gr´ficas ricas em dispositivos m´veis, que suportam a tecnologia Java ME. a o Inspirado no Swing da plataforma Java SE, foi projetado para ser o mais leve poss´ ıvel, comprometendo o m´ ınimo poss´ a aplica¸ao final, visto que foi desenvolvido para dis- ıvel c˜ positivos com capacidades restritas (SUN, 2009d). Com o LWUIT n˜o h´ mais necessidade de se desenhar telas em canvas para construir a a interfaces mais amig´veis, ´ uma grande evolu¸˜o visto que a complexidade para tal a e ca tarefa ´ muito alta. O framework oferece melhorias a componentes gr´ficos de alto n´ e a ıvel j´ existentes no Java ME, como List, Form, Alert, entre outros. Ainda oferece v´rias a a outras vantagens como suporte a touch Screen, diversas fontes, anima¸oes, transi¸˜es de c˜ co telas animadas e temas variados, que podem ser inclu´ıdos pelos pr´prios usu´rios. o a Al´m das caracter´ e ısticas citadas acima, o LWUIT tamb´m inclui: a utiliza¸˜o de e ca layouts, que organizam a disposi¸ao dos componentes na tela, al´m de oferecer melhor c˜ e
    • 5.2. Frameworks 34 portabilidade, integra¸ao 3D (se o dispositivo possuir bibliotecas 3D), caixas de di´logo, c˜ a utiliza¸ao de abas (como no Java SE) e internacionaliza¸ao. O LWUIT roda no perfil c˜ c˜ MIDP 2.0 e est´ sob a licen¸a GPL v2.0 com a Classpath Excepption, o que significa que a c pode ser utilizado em aplica¸oes de c´digos n˜o abertos, desde de que n˜o haja modifica¸˜o c˜ o a a ca nas classes do framework (NETO, 2008). O framework foi recentemente incorporado pela Sun como uma de suas bibliotecas padr˜es, no Java ME Plataform SDK 3, que substitui o WTK (Wireless ToolKit) - para o CLDC e o CDC ToolKit, o que promete ainda mais alavancar a utiliza¸ao do LWUIT c˜ dentro da comunidade de desenvolvedores (DOEDERLEIN, 2009).
    • Cap´ ıtulo 6 Comunica¸˜o com o Servidor ca Neste cap´ ıtulo s˜o apresentadas algumas caracter´ a ısticas da plataforma Java Enterprise Edition (Java EE), a fim de estudar um m´todo eficiente para a constru¸ao de servidores e c˜ de dados remotos para alimentar qualquer sistema m´vel que necessite deste tipo de o comunica¸ao. c˜ 6.1 A Plataforma Java EE Existem diversas tecnologias que fornecem aplica¸˜es com conte´do dinˆmico e per- co u a sonalizado, seja para construir um simples site de conte´do dinˆmico ou um sistema u a 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 aplica¸˜es co robustas para a Web. Dentre as tecnologias dispon´ ıveis atualmente, destacam-se para o desenvolvimento de aplica¸oes os servlets e p´ginas JSP (JavaServer Pages). servlets e c˜ a JSP s˜o duas tecnologias desenvolvidas pela Sun para desenvolvimento de aplica¸oes na a c˜ Web a partir de componentes Java que executam no lado do servidor. A Figura 6.1 ilustra a arquitetura da plataforma Java EE. A utiliza¸ao de servlets oferece diversas vantagens em rela¸˜o a outras tecnologias para c˜ ca o desenvolvimento de aplica¸˜es Web. As principais vantagens s˜o herdadas da pr´pria co a o linguagem Java, entre elas est˜o: Portabilidade, facilidade de programa¸˜o e a flexibilidade a ca da linguagem para o desenvolvimento. Em particular, os servlets s˜o mais eficientes, a apresentam melhor usabilidade, maior poder na programa¸˜o, s˜o mais port´teis, mais ca a a 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 ´ um padr˜o que determina a forma de comunica¸˜o entre o servidor Web e e a ca uma outra aplica¸ao rodando neste servidor e um script CGI ´ um programa que atende c˜ e requisi¸oes enviadas por um cliente e repassa para um servidor HTTP (QUIN, 2009). c˜ Um servlet tem um modelo de programa¸˜o parecido com um script CGI, por´m os ca e programas de CGI necessitam de um processo para tratar cada nova solicita¸ao e no caso c˜ dos servlets, podem existir v´rios ligados ao mesmo servidor, que estes s˜o executados a a dentro de um mesmo processo. E este processo roda dentro de uma JVM, que gera um encadeamento de processos para tratar cada solicita¸ao. Estes encadeamentos geram c˜ muito menos overheads do que processos completos (PITTELLA, 2009). 6.1.1 Servlets Segundo HALL (1998), servlet ´ uma resposta da tecnologia Java para a programa¸˜o e ca CGI. S˜o programas que rodam em sevidores Web agindo como uma camada mediana a 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 usu´rio. a • Observar qualquer outra informa¸ao sobre o pedido que ´ embutido no pedido de c˜ e HTTP. • Gerar os resultados. • Formatar os resultados dentro de um documento. • Fixar parˆmetros de resposta de HTTP apropriados. a
    • 6.1. A Plataforma Java EE 37 • Enviar de volta o documento ao cliente. Servlets s˜o classes Java instaladas junto a um Servidor que implemente um Servlet a Container, interagindo com clientes Web usando o paradigma request-response, ou seja, um programa Java que estende funcionalidades de um servidor de aplica¸˜es Java que co permite a execu¸ao de servlets comunicando com clientes. c˜ O componente container, ou contˆiner, ´ resposns´vel por dar suporte as APIs de e e a servlets e JSP. Gerˆncia as instˆncias dos servlets e fornece os servi¸os de rede necess´rios e a c a para as requisi¸oes e respostas. O container pode criar v´rias threads permitindo que c˜ a uma unica instˆncia servlet atenda mais de uma requisi¸ao simultaneamente. A Figura ´ a c˜ 6.2 ilustra a rela¸ao entre esses componentes. c˜ Figura 6.2: Servlet container. Os servlets s˜o independentes de protocolos e plataformas, podendo trabalhar com a diversos tipos de servidores, pois a API dos servlets n˜o assume nada a respeito do am- a biente do servidor. Diversas requisi¸oes podem ser feitas ao mesmo tempo em um unico c˜ ´ servidor. O comportamento dos servlets que ser´ estudado para a constru¸˜o de aplica¸˜es a ca co est´ definido na classe HttpServlet do pacote javax.servlet. Tendo em vista o paradigma a request-response, cujo atende requisi¸˜es realizadas por meio do protocolo HTTP, os ob- co jetos dos servlets podem capturar parˆmetros desta requisi¸ao, efetuar qualquer proces- a c˜ samento inerente a uma classe Java e enviar respostas na forma de p´ginas HTML, XML, a imagens entre outros (TEMPLE, 2004). Um servlet ´ b´sicamente definido pela Interface Servlet, uma classe de interface que e a implementa os m´todos init(), service() e destroy(), e a estrutura de uma classe servlet e cont´m os m´todos doGet() e doPost(), como ilustrado na Figura 6.3. e e Todos os seguintes m´todos s˜o invocados por meio do m´todo service() da classe de e a e interface.
    • 6.2. XML - Linguaguem de marca¸ao extens´ c˜ ıvel 38 Figura 6.3: Ciclo de vida do servlet. • M´todo doGet: Trata requisi¸oes do tipo GET. Esse tipo pode ser enviado v´rias e c˜ a vezes e alocado em um bookmark. • M´todo doPost: Trata requisi¸oes do tipo POST, permitindo que o cliente envie e c˜ dados do servidor Web uma unica vez. ´ • M´todo doPut: Trata requisi¸oes do tipo PUT, permitindo que o cliente envie e c˜ arquivos para o servidor, semelhante ao FTP. • M´todo doDelete: Trata requisi¸oes do tipo DELETE, permitindo que o cliente e c˜ remova determinada p´gina ou documento do servidor. a Um servlet n˜o possui interface gr´fica, por´m dentro de um servlet ´ poss´ construir a a e e ıvel um HTML, mas a visualiza¸˜o e entendimento ´ de alta complexidade quando se trata ca e de l´gicas extensas. Tendo em vista que o foco do estudo de caso est´ em um ambiente o a m´vel, n˜o ´ necess´rio a constru¸ao de uma interface gr´fica para trabalhar junto com o o a e a c˜ a servlet. 6.2 XML - Linguaguem de marca¸˜o extens´ ca ıvel A Extensible Markup Language (XML) ´ uma linguagem de marca¸˜o de dados sem e ca nenhum elemento de apresenta¸ao embutido, ou seja, apenas com elementos de defini¸˜o c˜ ca
    • 6.2. XML - Linguaguem de marca¸ao extens´ c˜ ıvel 39 de conte´do. O XML provˆ um formato para descrever dados estruturados que facilita u e declara¸˜es mais precisas do conte´do e resultados mais significativos de busca atrav´s de co u e m´ltiplas plataformas. u Segundo TITTEL (2002), a palavra extens´ ıvel reflete o fato de que a linguagem ´ e flex´ıvel, escalon´vel e adapt´vel. Com esses trˆs fatores o desenvolvimento de aplica¸˜es a a e co em trˆs camadas (three-tier ), que ´ o caso deste projeto, ´ altamente fact´ com o XML. e e e ıvel Os dados podem ser distribu´ ıdos entre as aplica¸˜es desktop para serem visualizados em co um navegador ou em servidores intermedi´rios para o processamento, permitindo que tais a dados possam ser facilmente combinados via software, com bancos de dados nas extremi- dades da rede. Desta forma a troca de informa¸oes entre dispositivos m´veis e servidores c˜ o remotos seria realizada de maneira mais comprimida e escal´vel, al´m de proporcionar a e buscas mais eficientes. Esse ponto ´ de suma importˆncia, pois os dispositivos m´veis e a o tipicamente possuem mem´ria limitada e baixo poder de processamento. o A estrutura de um documento XML ´ baseada em um modelo de arvore rotulada. e ´ Geralmente possui um n´ raiz especial acima do elemento raiz. Os n´s internos s˜o o o a elementos rotulados com um nome e um conjunto de atributos (valor). Os n´s folhas o cont´m: e • Sequˆncias de caracteres e • Anota¸oes de processamento, normalmente no cabe¸alho do documento c˜ c • Um coment´rio a • Uma declara¸ao de entidade c˜ • N´s DTD (Document Type Declaration) o Podemos visualizar uma breve estrutura de um documento XML com sua respectiva arvore na Figura 6.4. ´ 6.2.1 An´lise de documentos XML a A partir de um modelo no formato XML ´ necess´rio realizar a an´lise dos dados e a a embutidos atrav´s de uma t´cnica denominada Parse. Segundo VELOSO (2007), Par- e e sing ´ o processo de leitura e divis˜o do documento em elementos, atributos, entidades, e a coment´rios e outros tipos de dados, por meio do qual poder˜o ser analisados e validados. a a Existem algumas t´cnicas para realizar o parse de um XML, como o pull parser, o e DOM e o push parser. No pull parser uma quantidade de dados ´ analisada de cada e vez, durante o parse sempre ´ solicitado a pr´xima parte que deve ser processada at´ e o e chegar ao fim, geralmente isto ´ feito em um loop. Assim s˜o obtidas as informa¸oes do e a c˜
    • 6.2. XML - Linguaguem de marca¸ao extens´ c˜ ıvel 40 Figura 6.4: Estrutura do XML. XML a medida que o parser ´ efetuado. Uma outra t´cnica ´ o DOM, que utiliza um e e e modelo baseado em ´rvore e cria uma estrutura de dados na mem´ria, onde ´ poss´ a o e ıvel acessar essa estrutura atrav´s de um conjunto de objetos. E e ´ muito simples de se utilizar, por´m ´ necess´rio ler o documento inteiro para montar a estrutura de arvore, para depois e e a ´ exibir as informa¸˜es que foram lidas, al´m disso, pode ter muitos objetos armazenados na co e mem´ria ent˜o n˜o ´ recomendado para ser usado em Java ME. E o modelo push parser o a a e ´ orientado a eventos, portanto ao ler um XML um objeto listener ´ notificado sempre e e que novas tags s˜o encontradas. a
    • 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 pr´ticas do extreme a programming durante um per´ ıodo de trˆs meses. e 7.1 Extreme programming Extreme programming (Programa¸ao extrema), ou XP, ´ uma metodologia ´gil de de- c˜ e a senvolvimento de software voltada para projetos cujos requisitos mudam com frequˆncia. e O desenvolvimento ´ orientado a objetos e possui equipes de desenvolvimento pequenas. e Assim como outros m´todos ageis, o XP parte da premissa que o cliente aprende quais e ´ as suas reais necessidades no decorrer do desenvolvimento do software, quando ele vai manipulando as funcionalidades do sistema. Sendo assim uma das principais pr´ticas do a XP ´ que o cliente esteja sempre presente (TELES, 2004). e No XP todas as funcionalidades do sistema s˜o descritas em est´rias, escritas pelos a o clientes, e os desenvolvedores implementam as partes do sistema baseados nestas est´rias. o Em uma reuni˜o, chamada jogo de planejamento, o tempo de implementa¸ao de cada a c˜ est´ria ´ definido utilizando um sistema de pontos, onde um ponto significa um dia ideal o e de trabalho, cujo desenvolvedor gaste todo o tempo somente na implementa¸ao. O cliente c˜ prioriza quais as est´rias que devem ser implementadas primeiro e ent˜o o sistema ´ o a e desenvolvido em partes, podendo assim ser entregue periodicamente releases do sistema. Estes releases s˜o intervalos de tempo menores, onde algumas funcionalidades que gerem a 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 raz˜o eles s˜o divididos em espa¸os de tempo menores, chamados de a a c 41
    • 7.2. Arquitetura do sistema 42 itera¸˜es. Cada itera¸˜o contˆm um conjunto de est´rias e no final desta o cliente pode co ca e o validar as implementa¸oes efetuadas e dar seu feedback. O XP utiliza ainda o conceito de c˜ programa¸ao em par. Enquanto uma das pessoas est´ escrevendo o c´digo a outra pessoa, c˜ a o chamada de navegador, est´ permanentemente revisando. Todo c´digo desenvolvido ´ a o e coletivo, portanto utiliza-se padroniza¸˜o para simplificar o desenvolvimento (TELES, ca 2004). O XP oferece agilidade no processo de desenvolvimento de software e um feedback r´pido do cliente, o que ´ necess´rio quando se trata de desenvolvimento para celulares e a e a smartphones, por ser um sistema enxuto. Portanto, para este estudo de caso foi adotado as pr´ticas da metodologia agil XP, onde foram definidos dois releases, cada um composto a ´ por duas itera¸oes. As itera¸˜es dos releases foram descritas no decorrer deste trabalho. c˜ co 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 comunica¸ao com o dispositivo m´vel. Visto que um servlet pode efetuar c˜ o qualquer processamento inerente a uma classe Java e enviar respostas na forma de docu- mentos XML, para efetuar a troca de dados entre o dispositivo m´vel e o servidor remoto o de dados, que alimentar´ o sistema m´vel, foi utilizado os recursos que a linguagem XML a o oferece. A Figura 7.1 mostra o esquema de comunica¸ao para o trabalho proposto. Definido c˜ por uma arquitetura Cliente - Servidor e baseado nas trˆs seguintes camadas: e Figura 7.1: Esquema de comunica¸˜o. ca
    • 7.3. Vis˜o geral do sistema a 43 7.3 Vis˜o geral do sistema a ´ E proposto um sistema m´vel gerador de pedidos para uma empresa revendedora de o bebidas. O sistema ser´ respons´vel por cadastrar e editar clientes, gerar os pedidos a a 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 ´ feita manualmente atrav´s de consultas a e e cat´logos e toda informa¸˜o coletada ´ registrada em listas e repassada para a central da a ca e empresa, onde os dados eram digitalizados para serem armazenados no banco de dados central da distribuidora. A empresa possui um sistema Web, que ´ o respons´vel por alimentar o sistema m´vel. e a o Com este sistema a gerˆncia otimiza o acesso aos dados de forma segura, al´m de facilitar e e o trabalho dos revendedores. O revendedor realiza o pedido via celular ou smartphone, e este ´ armazenado no aparelho. Quando o dispositivo acessar uma rede sem fio ´ poss´ e e ıvel atualizar o banco de dados do dispositivo e enviar os pedidos para um sistema Web que ir´ armazenar as informa¸oes no banco de dados central da distribuidora, controlando a c˜ todas as informa¸˜es referente ` for¸a de vendas. co a c 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 cen´rio que mostra as funcionalidades do sistema do ponto de vista a do usu´rio. a Figura 7.2: Diagrama de Caso de Uso.
    • 7.5. Est´rias o 44 7.5 Est´rias o As Figuras 7.3 a 7.7 ilustram est´rias, que na pr´tica s˜o escritas pelo cliente. Estas o a a est´rias cont´m as funcionalidades que um cliente deseja possuir em seu sistema e forne- o e cem a base para os desenvolvedores implementarem as solu¸oes necess´rias, ou seja essas c˜ a est´rias fornecem os requisitos do sistema. O modelo cl´ssico dos cart˜es de est´rias foi o a o o adotado, a fim de seguir padr˜es das pr´ticas XP. o a Figura 7.3: Est´ria 1-A: Consulta de produtos. o A est´ria 1-A corresponde ao caso de uso ”Consultar Produto”. o Figura 7.4: Est´ria 1-B: Consulta e cadastro de clientes. o A est´ria 1-B corresponde ao caso de uso ”Gerenciar Cliente”. o
    • 7.5. Est´rias o 45 Figura 7.5: Est´ria 2-A: Cadastro de pedidos. o Figura 7.6: Est´ria 2-B: Altera¸ao de pedidos. o c˜ As est´rias 2-A e 2-B correspondem aos casos de uso ”Gerenciar Pedido”. o
    • 7.6. Release 1 46 Figura 7.7: Est´ria 2-C: Envio dos dados para o banco central da empresa. o A est´ria 2-C corresponde ao caso de uso ”Exportar dados”. o Os casos de uso ”Autenticar Usu´rio”e ”Atualizar Banco”n˜o est˜o descritos nas est´- a a a o rias, por´m s˜o necessidades do sistema. e a 7.6 Release 1 Este release ´ dividido nas seguintes itera¸oes: e c˜ 7.6.1 Itera¸˜o A ca Nesta itera¸ao foi utilizada a est´ria 1-A (”Consulta de produtos”) como base para c˜ o implementa¸ao. Neste ponto foram implementados os m´todos para importa¸˜o de um c˜ e ca documento XML do servidor, que cont´m os dados de produtos e clientes armazenados no e banco de dados da empresa. Foi constru´ localmente o banco de dados dos produtos, ıdo desenvolvida a interface com o usu´rio da tela principal, busca, listagem e detalhes dos a 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 neg´cio, com o prop´sito de deixar de forma bem definida os o o dados envolvidos no estudo de caso.
    • 7.6. Release 1 47 Figura 7.8: Diagrama de classe de projeto - Produto. 7.6.2 Itera¸˜o B ca Para esta itera¸ao foi utilizada a est´ria 1-B (”Consulta e cadastro de clientes”) como c˜ o base para implementa¸˜o. Foram implementados os m´todos para constru¸ao do banco ca e c˜ de dados local a partir dos dados dos clientes que est˜o no XML importado na Itera¸˜o a ca A. Foi desenvolvida a interface com o usu´rio e implementada uma busca de clientes. Os a 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 ´ dividido nas seguintes itera¸oes: e c˜ 7.7.1 Itera¸˜o A ca Nesta itera¸ao foi utilizada a est´ria 2-A (”Cadastro de pedidos”) como base para c˜ o implementa¸ao. Foram implementados os m´todos de cadastro e listagem de pedidos, c˜ e bem como as interfaces de usu´rio correspondentes. a 7.7.2 Itera¸˜o B ca Nesta itera¸˜o foram utilizadas as est´rias 2-B (”Altera¸˜o de pedidos”) e 2-C (”Envio ca o ca dos dados para o banco central da empresa”) como base para implementa¸˜o. Foram ca implementados os m´todos de edi¸˜o e exclus˜o dos pedidos cadastrados e as interfaces e ca a correspondentes. Neste ponto tamb´m foram implementadas as funcionalidades necess´- e a rias para exporta¸ao dos dados dos pedidos e clientes cadastrados. Desta forma os dados c˜ podem ser exportados para o servidor em forma de um ducumento XML. Figura 7.10: Diagrama de classes de projeto.
    • 7.8. A Aplica¸ao c˜ 49 7.8 A Aplica¸˜o ca A aplica¸˜o desenvolvida no estudo de caso, um sistema m´vel de for¸a de venda ca o c para uma distribuidora de bebidas, teve seu foco sobre a plataforma Java ME, utilizando tamb´m o Java EE para a constru¸ao de um servidor que armazena documentos XMLs, e c˜ com dados que alimentam a aplica¸ao m´vel. Estes XMLs cont´m dados dos produtos c˜ o e e clientes j´ cadastrados, al´m de oferecer uma gama de logins e senhas v´lidos para a a e a autentica¸˜o do usu´rio. ca a A aplica¸ao m´vel foi constru´ utilizando os frameworks j´ citados anteriormente: c˜ o ıda a LWUIT, KXML e Floggy. O LWUIT, proporcionou uma interface rica para a aplica- ¸ao e trata os eventos touchScreem; o KXML facilitou a leitura dos documentos XMLs, c˜ armazenados no servidor, realizando o parse destes; e o floggy auxiliou os m´todos de per- e sistˆncia, simplificando os m´todos para o armazenamento dos dados, em Records Stores, e e armaz´ns de dados gravados na mem´ria do celular ou smartphone. e o Al´m dos frameworks citados, o sistema m´vel faz uso da File Connection API, res- e o pons´vel, dentre outras fun¸oes, pelo acesso ` arquivos situados no sistema de arquivos a c˜ a local do dispositivo m´vel utilizado. Na aplica¸ao, esta API proporciona a grava¸ao de o c˜ c˜ um arquivo XML de s´ida, com os novos dados obtidos na aplica¸ao, ou seja, dados de a c˜ pedidos e novos clientes. Quando a aplica¸˜o ´ executada faz um acesso ao servidor, obtendo dados do XML ca e que cont´m os logins e senhas v´lidos e faz uma compara¸ao com o login e senha digitados, e a c˜ procurando se o login existe na lista e se a senha confere. A tela de autentica¸ao pode c˜ ser observada na Figura 7.11. Autenticado, o usu´rio possui acesso ao menu principal a da aplica¸ao, ilustrado na Figura 7.12. Este menu fornece acesso: ` Clientes, permitindo c˜ a fun¸˜es de busca e cadastro; Produtos, permitindo fun¸oes de somente de busca; Pedidos, co c˜ onde ´ poss´ e ıvel cadastrar novos pedidos, utilizando as fun¸˜es de busca de clientes e co produtos; Lista de Pedidos, que disp˜e uma lista de pedidos j´ cadastrados permitindo o a que estes sejam alterados ou exclu´ ıdos; Importa¸ao, permite que a aplica¸ao acesse o c˜ c˜ servidor remoto, trazendo os dados dos XMLs de produtos e clientes para o banco de dados local do dispositivo m´vel; e Exporta¸˜o, gera um arquivo XML de sa´ com o ca ıda os dados dos clientes e pedidos cadastrados. Este arquivo ´ armazanado no cart˜o de e a mem´ria do celular ou smartphone, para ser enviado para o servidor ou utilizada de outra o forma desejada.
    • 7.8. A Aplica¸ao c˜ 50 Figura 7.11: Autentica¸ao do usu´rio. c˜ a
    • 7.8. A Aplica¸ao c˜ 51 Figura 7.12: Menu principal da aplica¸ao m´vel. c˜ o 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 atrav´s do menu clientes e as duas ultimas atrav´s do menu produtos. e ´ e E as Figuras 7.16 e 7.17 ilustram uma tela de cadastro de pedidos e a lista destes, onde podem ser escolhidas as op¸oes de editar ou excluir um pedido realizado. Estas telas c˜ podem ser obtidas respectivamente nos menus Pedidos e Lista de Pedidos.
    • 7.8. A Aplica¸ao c˜ 52 Figura 7.13: Cadastro de Clientes.
    • 7.8. A Aplica¸ao c˜ 53 Figura 7.14: Busca de Produtos.
    • 7.8. A Aplica¸ao c˜ 54 Figura 7.15: Detalhamento de produto.
    • 7.8. A Aplica¸ao c˜ 55 Figura 7.16: Cadastro de pedidos.
    • 7.8. A Aplica¸ao c˜ 56 Figura 7.17: Lista de pedidos.
    • Cap´ ıtulo 8 Considera¸oes Finais c˜ Ap´s estudos que culminaram nesta disserta¸ao e atrav´s do desenvolvimento do es- o c˜ e tudo de caso podemos chegar nas seguintes conclus˜es. o Atualmente o uso de telefones celulares no mundo ´ bastante elevado. Organiza¸oes e c˜ corporativas est˜o evoluindo juntamente com tecnologias m´veis para a otimiza¸ao do a o c˜ processo de neg´cio. Dessa forma o uso de smartphones vem se tornando de grande utili- o dade tanto nestas organiza¸oes quanto para o uso particular. Visto que a plataforma Java c˜ Micro Edition ´ bem aceita pelo mercado de software, torna-se vi´vel o desenvolvimento e a de aplica¸oes m´veis e embarcadas usando tal tecnologia. c˜ o O perfil MIDP ´ suportado pela configura¸˜o CLDC, providenciando um ambiente e ca padr˜o de execu¸˜o de aplica¸˜es Java para os dispositivos m´veis mais convencionais. a ca co o Este perfil provˆ um conjunto de bibliotecas e classes que fornecem um sistema de arma- e zenamento persistente, interface com o usu´rio, transa¸˜es seguras, gerˆncia de sons, entre a co e outras caracter´ ısticas que proporcionam um bom ambitente de desenvolvimento. Atrav´s e de MIDlets foi poss´ desenvolver aplica¸oes utilizando o perfil MIDP. Estas aplica¸oes ıvel c˜ c˜ Java podem ser constru´ ıdas atrav´s da biblioteca LCDUI, que fornece componentes para e o desenvolvimento da interface das aplica¸oes. Por´m, tamb´m existem frameworks que c˜ e e porporcionam o desenvolvimento de interfaces com o usu´rio mais robustas. a Para a comunica¸ao da aplica¸ao m´vel com um servidor remoto de dados, o uso c˜ c˜ o da plataforma Java EE com a implementa¸ao de servlets se torna algo muito eficiente, c˜ tanto para a seguran¸a dos dados quanto para a compatibilidade entre as plataformas. c A transferˆncia dos dados pode ser realizada atrav´s de diversas extens˜es de arquivos, e e o seja no formato de documentos XML, imagens, arquivos compactados ou at´ mesmo em e formato de strings, atrav´s de requis¸˜es HTTP. Vale ressaltar que a transferˆcia de dados e co e utilizando documentos XML ´ muito bem organizada e segue um padr˜o de transferˆncia e a e de informa¸˜o unificado, por´m o uso desse tipo de documento causa um leve retardo ca e 57
    • 58 tanto no desempenho da aplica¸˜o durante a leitura das informa¸oes quanto ao tamanho ca c˜ do arquivo de tranferˆncia, que fica levemente extenso devido a padroniza¸ao e organiza¸˜o e c˜ ca das informa¸oes. c˜ Atrav´s de alguns frameworks foi poss´ construir uma aplica¸ao com mais recur- e ıvel c˜ sos, al´m de otimizar o desenvolvimento. As tarefas mais rotineiras utilizadas para o e desenvolvimento de aplica¸oes comerciais tratam do armazenamento persistente dos da- c˜ dos no pr´prio dispositivo, constru¸ao de interfaces com o usu´rio mais robustas e da o c˜ a transferˆncia de dados padronizados na forma de documentos XML. Tendo em vista es- e tas caracter´ ısticas, atrav´s de testes e do levantamento bibliogr´fico, os frameworks que e a melhor atenderam para a execu¸ao de tais tarefas foram respectivamente o Floggy - para c˜ persistˆncia dos dados, o LWUIT - para interfaces mais robustas, e o KXML - para realizar e o parse de documentos XML. A File Connection API ´ a API usada para manipula¸˜o de arquivos e diret´rios do e ca o dispositivo. Visando uma poss´ implementa¸ao deste tipo de funcionalidade, seja para ıvel c˜ contru¸˜o de um XML de sa´ ou de qualquer outro arquivo, o uso desta API ´ de suma ca ıda e importˆncia para aplica¸oes m´veis. a c˜ o Para auxiliar no desenvolvimento do estudo caso, a metodologia ´gil extreme program- a ming organizou o processo de desenvolvimento, proporcionando um estudo de caso bem elaborado e definido seguindo referˆncias da Engenharia de Software. A agilidade no e desenvolvimento de sistemas m´veis ´ essencial, pois trata-se de um sistema exuto, que o e necessita de constante feedback do cliente. Desenvolver aplica¸oes m´veis nativas para diferentes plataformas requer conhecimento c˜ o 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 ´ mais vi´vel e a o desenvolvimento, o que ´ uma tarefa dif´ e ıcil. O Android ´ uma plataforma nova, em e fase de constru¸˜o, possui diversas APIs opicionais para o desenvolvimento, mas ainda ca a oferta de dispositivos n˜o alcan¸a o mundo todo. Restringir o desenvolvimento ao a c Windows Mobile ou Symbian OS tamb´m n˜o torna-se vi´vel, visto que estes suportam e a a aplica¸˜es Java ME com a utiliza¸ao de m´quinas virtuais Java. O Palm OS ´ uma co c˜ a e plataforma que est´ em decadˆncia, tanto que a Palm est´ disponibilizando aparelhos a e a com Windows Mobile. A empresa ainda est´ investindo em seu SO, por´m n˜o est´ a e a a conseguindo superar os outros existentes no mercado. O iPhone possui um SO muito robusto e atrativo, o que torna o desenvolvimento de aplica¸oes para este muito lucrativas, c˜ por´m restringe as aplica¸˜es a apenas este SO. Em contra partida a plataforma Java ME e co oferece portabilidade e acessibilidade, al´m de concentrar isto em uma unica linguagem. e ´
    • Referˆncias Bibliogr´ficas e a ADMOB (2009). Admob mobile metrics report. Dispon´ on-line em maio de 2009 no ıvel endere¸o http://www.admob.com/marketing/pdf/mobile metrics jul 08.pdf. c ˆ AGENCIAESTADO (2009). Pa´ supera 152 milh˜es de celulares em fe- ıs o vereiro. G1. Dispon´ıvel on-line em mar¸o de 2009 no endere¸o c c 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´ on-line em maio de 2009 no endere¸o ıvel c http://www.apple.com/macosx/technology/. APPLE (2009b). What is cocoa? Dispon´ ıvel on-line em maio de 2009 no endere¸o c http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/ WhatIsCocoa/WhatIsCocoa.html. CLAUSEN, D. (2003). Microfloat. Dispon´ ıvel on-line em abril de 2009 no endere¸o c http://www.dclausen.net/projects/microfloat/. Developers, A. (2009). What is android? Dispon´ on-line em maio de 2009 no endere¸o ıvel c http://developer.android.com/guide/basics/what-is-android.html. DOEDERLEIN, O. P. (2009). Java: Uma perspectiva. revista Java Magazine, edi¸˜o 65. ca FLOGGY (2009). Welcome to floggy. Dispon´ on-line em Julho de 2009 no endere¸o ıvel c 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´ on-line em Julho de ıvel 2009 no endere¸o http://www.kobjects.org/kxml/. c INFO (2008). Nokia compra a¸˜es da samsung na symbian. Dispon´ on-line em maio de co ıvel 2009 no endere¸o http://info.abril.com.br/aberto/infonews/092008/02092008-13.shl. c 59
    • ˆ ´ REFERENCIAS BIBLIOGRAFICAS 60 JCP (2009a). Jsr 271: Mobile information device profile 3. Dispon´ on-line em maio ıvel de 2009 no endere¸o http://jcp.org/en/jsr/detail?id=271. c JCP (2009b). Jsrs: Java specification requests. Dispon´ on-line em Julho de 2009 no ıvel endere¸o http://jcp.org/en/jsr/all. c JCP, J. C. P. (2009c). Connected device configuration. Dispon´ on-line em maio de ıvel 2009 no endere¸o http://jcp.org/en/jsr/detail?id=218. c JOHNSON, M. T. (2007). Java para Dispositivos M´veis - Desenvolvendo Aplica¸˜es com o co J2ME. Novatec, 1th edition. JONES (2009). Qual ser´ seu pr´ximo celular. revista info fevereiro de 2009. a o LECHETA, R. R. (2006). kxml - fazendo parser de um xml com j2me. Dispon´ ıvel on-line em Julho de 2009 no endere¸oc http://www.devmedia.com.br/articles/viewcomp.asp?comp=2099. LUGON, P. T. R. T. (2005). Floggy: Framework de persistˆncia para j2me/midp. e LUZ, M. (2009). Midp 3.0: O que vem por ai. a nova especifica¸˜o do principal perfil do ca java me. Revista Java Magazine, edi¸˜o 44. ca MATTOS, r. T. d. (2005). Programa¸˜o Java para Wireless - Aprenda a desenvolver ca sistemas em J2ME. Digerati Editorial, 1th edition. MICROSOFT (2009a). O que ´ o windows mobile? Dispon´ on-line em maio de 2009 e ıvel no endere¸o http://www.microsoft.com/brasil/windowsmobile/partners/default.mspx. c MICROSOFT (2009b). Qual ´ a diferen¸a entre um pocket pc e um e c smartphone? Dispon´ ıvel on-line em maio de 2009 no endere¸o c 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, edi¸˜o 60. ca NOKIA (2008). Jsr 75 fille connection api. Dispon´ ıvel on-line em Julho de 2009 no endere¸o http://wiki.forum.nokia.com/index.php/JSR 75 File connection API. c PALMBRASIL (2009a). Conhe¸a o palm. Dispon´ on-line em maio de 2009 no endere¸o c ıvel c 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 endere¸o c http://www.palmbrasil.com.br/vocab/palmos.html. PITTELLA, F. (2009). Cgi x servlets. Dispon´ on-line em Junho de 2009 no endere¸o ıvel c http://www.javafree.org/artigo/1406/CGI-X-Servlets.html. QUIN, L. (2009). Cgi: Common gateway interface. Dispon´ on-line em Junho de 2009 ıvel no endere¸o http://www.w3.org/CGI/. c REUTERS (2008). Mundo ter´ a 4 bi de celulares este ano. Abril. Dispon´ıvel on-line em mar¸o c de 2009 no endere¸o c http://info.abril.com.br/aberto/infonews/092008/25092008-21.shl. RIM (2009). Vis˜o geral. a Dispon´ıvel on-line em maio de 2009 no endere¸o c http://br.blackberry.com/ataglance/. SOUSA, A. E. J. (2006). Persistˆncia em aplicativos para dispositivos m´veis com j2me. e o Revista WebMobile, edi¸˜o 3. ca SUN (2002). What’s new in midp 2.0. Dispon´ on-line em maio de 2009 no endere¸o ıvel c http://developers.sun.com/mobility/midp/articles/midp20/. SUN (2006a). Class command. Dispon´ıvel on-line em maio de 2009 no endere¸o http://java.sun.com/javame/reference/apis/jsr118/javax/microedition/lcdui/ c Command.html. SUN (2006b). Class textbox. Dispon´ıvel on-line em maio de 2009 no endere¸o http://java.sun.com/javame/reference/apis/jsr118/javax/microedition/lcdui/ c TextBox.html. SUN (2006c). Mid profile. Dispon´ıvel on-line em maio de 2009 no endere¸o c http://java.sun.com/javame/reference/apis/jsr037/. SUN (2006d). Mid profile. Dispon´ıvel on-line em maio de 2009 no endere¸o c http://java.sun.com/javame/reference/apis/jsr118/. SUN (2006e). Summary of cldc-based profiles. Dispon´ on-line em maio de 2009 no ıvel endere¸o http://developers.sun.com/mobility/midp/ttips/cldc/. c SUN (2007). A survey of java me today. Dispon´ on-line em abril de 2009 no endere¸o ıvel c 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 endere¸o http://java.sun.com/javame/reference/docs/cldc-hi-2.0- c web/doc/architecture/html/Introduction.html#50638859 pgfId-431762. SUN (2008b). Lesson: Packaging programs in jar files. Dispon´ on-line em maio de ıvel 2009 no endere¸o http://java.sun.com/docs/books/tutorial/deployment/jar/. c SUN (2009a). Java me technology apis & docs. Dispon´ on-line em maio de 2009 no ıvel endere¸o http://java.sun.com/javame/reference/apis.jsp#api. c SUN (2009b). Javame technology - powering your devices everywhere. Dispon´ on-line ıvel em abril de 2009 no endere¸o http://java.sun.com/javame/technology/index.jsp. c SUN (2009c). Jsr 75 - pda optional packages. Dispon´ on-line em Julho de 2009 no ıvel endere¸o http://java.sun.com/javame/technology/msa/jsr75.jsp. c SUN (2009d). The lightweight user interface toolkit (lwuit): An in- troduction. Dispon´ıvel on-line em Julho de 2009 no endere¸o c http://java.sun.com/developer/technicalArticles/javame/lwuit intro/. SYMBIANBRASIL (2009). Symbian os. Dispon´ on-line em maio de 2009 no endere¸o ıvel c http://www.symbianbrasil.com/Sobre. TELES, V. M. (2004). Extreme Programming: Aprenda como encantar seus usu´rios a desenvolvendo software com agilidade e alta qualidade. Novatec, 1ed edition. TEMPLE, Andr´; MELLO, R. F. C. D. T. S. M. (2004). Programa¸˜o Web com JSP, e ca 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 lan¸a novo software java para celulares. Abril. Dispon´ on-line c ıvel em mar¸o de 2009 no endere¸o http://www.abril.com.br/noticias/tecnologia/sun-lanca- c c novo-software-java-celulares-266915.shtml.