Minicurso

           Desenvolvimento para Dispositivos Móveis utilizando JavaME

                                   Por E...
Minicurso

          Desenvolvimento para Dispositivos Móveis utilizando JavaME

                               Por Erisva...
Figura 1 [SUN, 2008]




                                   Ferramentas

Para executar as aplicações desenvolvidas em J2ME...
Figura 2




                                     O MIDlet

Uma aplicação JavaME é chamada de MIDlet, de forma análoga aos...
Figura 3 [FONSECA, 2005]




                               Classes do JavaME

A Figura 4, também desenvolvida por Fonseca...
Figura 4 [FONSECA, 2005]



A Figura 5, por sua vez, mostra a hierarquia de classes expandida, incluindo as
classes deriva...
Classe Screen e suas derivadas

Como dito anteriormente, a classe Screen possui diversos componentes destinados a
criação ...
Classe Canvas

Canvas é a derivada de Displayable (vide Figura 6) que permite ao programador uma
manipulação da tela em ma...
Persistência de dados no JavaME

A persistência de dados no JavaME se dá através do RMS (Record Management
Store), um esqu...
elas, destacam-se: WMA 2.0 (Wireless Messaging API), disponibilizada com a JSR
205 e que permite o envio e recebimento de ...
Upcoming SlideShare
Loading in...5
×

Apostila JavaME

5,465

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
5,465
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
267
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Apostila JavaME

  1. 1. Minicurso Desenvolvimento para Dispositivos Móveis utilizando JavaME Por Erisvaldo Júnior Resumo: O presente minicurso tem como objetivo introduzir o desenvolvimento de aplicações para dispositivos móveis utilizando a tecnologia JavaME, através de uma abordagem prática. Em um primeiro momento, será mostrada a plataforma, sua arquitetura e como produzir aplicativos básicos, utilizando os componentes nativos do J2ME. Depois, focar-se-á na confecção de telas em baixo nível, nos desafios de portabilidade, persistência de dados e exemplos demonstrando o uso de APIs opcionais para manipulação de câmera, envio de SMS/MMS e integração com a Web através de requisições HTTP. Por fim, serão mostradas algumas aplicações comerciais desenvolvidas, consolidando o conteúdo ministrado. Erisvaldo Júnior é tecnólogo em Sistemas para Internet pelo Instituto Federal de Educação, Ciência e Tecnologia da Paraíba (IFPB), bem como graduando em Ciência da Computação pela Universidade Federal da Paraíba (UFPB). Além disso, é pesquisador no Laboratório de Tecnologias para Ensino Virtual e Estatística (LabTEVE), também situado na UFPB, fazendo parte da equipe de jogos educacionais multiplataforma. E-mail / Gtalk: erisvaldojunior@gmail.com Site: http://erisvaldojunior.com Twitter: http://twitter.com/erisvaldojunior
  2. 2. Minicurso Desenvolvimento para Dispositivos Móveis utilizando JavaME Por Erisvaldo Júnior Introdução Entre as tecnologias para desenvolvimento de aplicações para celulares, destaca-se o J2ME, também chamado de JavaME ou, ainda, JME. Trata-se de uma versão simplificada do Java, executada sobre uma máquina virtual Java reduzida, a KVM, que demanda menos recursos que a JVM (Java Virtual Machine). O J2ME possui duas configurações básicas: CDC (Connected Device Configuration) e CLDC (Connected Limited Device Configuration). O CDC se destina a dispositivos com maior capacidade de processamento, o que permite a presença de recursos não disponíveis na configuração mais básica, o CLDC. Esta, porém, é a configuração utilizada pelos celulares, pagers e alguns PDAS (Personal Digital Assistant) menos poderosos, uma vez que tais dispositivos não dispõem de alto poder de processamento. Uma vez definida a configuração, entra-se no âmbito dos perfis (profiles), responsáveis por determinar características mais específicas do dispositivo para o qual se está desenvolvendo. O perfil, em conjunto com a configuração, fornece um conjunto de APIs para o desenvolvimento focado no grupo de dispositivos desejado. Assim, no caso do desenvolvimento de aplicações para celulares, utiliza-se a configuração CLDC (versão 1.0 ou 1.1) e o perfil MIDP (Mobile Information Device Profile), na sua versão 1.0, 2.0 ou 2.1. O MIDP 1.0 é compatível com quase todos os aparelhos ativos no Brasil, mas peca em não fornecer tantos recursos quanto a versão 2.0, principalmente no que tange à existência de componentes específicos para a criação de jogos e aplicações multimídia. Estudando-se o mercado brasileiro atual, conclui-se que a melhor escolha para o desenvolvimento de aplicações com J2ME é usando a configuração CLDC 1.1 e o profile MIDP 2.0, que formam uma espécie de padrão da indústria de celulares no momento, dos mais baratos aos mais caros (alguns já suportam MIDP 2.1, mas a compatibilidade é retroativa, ou seja, um celular com suporte a MIDP 2.1 roda código MIDP 1.0 e também 2.0). A Figura 1, desenvolvida pela Sun [SUN, 2008], fornece uma visão geral da plataforma Java. Nessa figura, é possível visualizar o JavaME. No caso dos celulares, a camada-base é a KVM. A camada de configuração, CLDC, está logo acima, sob a camada de perfil, MIDP. Por fim, sobre o MIDP, ainda podem existir pacotes opcionais, como os SDKs (Software Development Kit) da Nokia, por exemplo, fornecendo maiores facilidades para os desenvolvedores.
  3. 3. Figura 1 [SUN, 2008] Ferramentas Para executar as aplicações desenvolvidas em J2ME no computador faz-se necessário o uso de um emulador. A Sun disponibiliza o WTK (Java Wireless Toolkit), um kit que facilita o desenvolvimento e os testes das aplicações J2ME no computador. O WTK conta com um emulador, documentação, exemplos diversos e ferramentas que permitem, entre outras coisas, monitorar o uso de memória da aplicação. Em conjunto com o emulador, costuma-se utilizar uma IDE (Integrated Development Environment) para facilitar o processo de desenvolvimento. A IDE que será adotada no decorrer deste minicurso é o NetBeans 6.5, que pode ser baixado gratuitamente em seu site oficial (www.netbeans.org). A principal razão para a escolha do NetBeans é a presença de ferramentas visuais que aumentam bastante a produtividade, tais como o Game Builder (muito útil para os jogos) e o Visual Mobile Designer (utilizado para a confecção de telas de aplicação bem como estabelecer o seu fluxo). Apesar dessas ferramentas não substituírem por completo a codificação, podem aumentar a produtividade consideravelmente, desde que usadas na medida certa. A Figura 2 mostra a IDE NetBeans 6.5 integrada ao emulador do WTK 2.5.2 (o NetBeans na sua versão Mobility ou na versão completa já possui o WTK). Pode-se visualizar, ainda, a existência de diversas cenas de um jogo, construídas com o Game Builder.
  4. 4. Figura 2 O MIDlet Uma aplicação JavaME é chamada de MIDlet, de forma análoga aos Applets (aplicações que são executadas no navegador) e os Xlets (aplicações de TV Digital). Os MIDlets são controlados por um gerenciador chamado de AM (Application Manager). A Figura 3, desenvolvida por Fonseca [FONSECA, 2005], demonstra o ciclo de vida de um MIDlet. Quando um MIDlet é invocado, o Application Manager faz uma chamada ao método startApp(), responsável por tornar o estado do MIDlet “ativo”, conforme pode ser visto na figura. No decorrer da execução, a aplicação pode ser pausada, seja por desejo do usuário ou por uma chamada ou mensagem recebida. Quando isso ocorre, é executado o método pauseApp() do MIDlet. A própria aplicação pode pausar a si mesma se necessário, utilizando o método notifyPaused(). Nesse momento, o estado da aplicação se torna “pausado”. Já quando a aplicação é finalizada, o método destroyApp() do MIDlet é invocado, seja por parte do AM ou da própria aplicação, utilizando o método notifyDestroyed(). Nesse caso, a aplicação entra no estado “destruído”. Percebe-se pela Figura 3, ainda, que do estado “pausado” pode-se retornar para o “ativo”, pois o método startApp() é novamente chamado após o fim da pausa. Outra possibilidade é que a aplicação pode ser finalizada, dirigindo-se diretamente do estado “pausado” para o estado “destruído”.
  5. 5. Figura 3 [FONSECA, 2005] Classes do JavaME A Figura 4, também desenvolvida por Fonseca [FONSECA, 2005], mostra a hierarquia de classes do J2ME ou, mais precisamente, do perfil MIDP. No maior nível da hierarquia, existe a classe Display, que representa a tela do aparelho. A classe Displayable, por sua vez, representa qualquer componente que possa ser exibido no Display e divide-se em dois grupos: as classes de alto nível (que herdam da classe abstrata Screen) e as classes de baixo/médio nível (representadas pela classe Canvas e, no MIDP 2.0, também por sua classe filha, a GameCanvas). A classe abstrata Screen contém quatro subclasses básicas: List, Form, Alert e TextBox. São consideradas de alto nível porque se comportam para o desenvolvedor como componentes apropriados para a criação de interfaces, no caso listas, formulários, mensagens de aviso e caixas de texto, respectivamente. Na outra vertente, a classe Canvas é a classe derivada de Displayable que representa o topo das classes de baixo/médio nível, por permitir um controle maior do dispositivo, permitindo ao programador moldar o display do aparelho livremente. Assim, é visível que a classe Canvas é de extrema importância para o desenvolvimento de interfaces ricas e, por isso, requer atenção especial. As demais classes, derivadas de Screen, apesar de serem bastante úteis para o desenvolvimento de aplicações gerais, geralmente são substituídas, em aplicações comerciais, por telas mais ricas que utilizam o poder de Canvas.
  6. 6. Figura 4 [FONSECA, 2005] A Figura 5, por sua vez, mostra a hierarquia de classes expandida, incluindo as classes derivadas de Screen e outras classes presentes apenas no MIDP 2.0 ou superior, bastante úteis para jogos e animações, como a classe Sprite. Figura 5
  7. 7. Classe Screen e suas derivadas Como dito anteriormente, a classe Screen possui diversos componentes destinados a criação de elementos úteis para a interface de uma aplicação qualquer. Esses elementos são representados por classes derivadas de Screen, como List, TextBox, Alert e Form. A classe Alert é responsável pela criação de mensagens de alerta ao usuário. Essas mensagens se caracterizam por possuírem um tempo pré-determinado de exibição. Ao término desse tempo, a mensagem desaparece. A classe Form é utilizada para a criação dos famosos “forms”, comuns em ferramentas RAD. Um Form é composto por componentes denominados Item. Pode-se entender o Form como um agrupamento lógico de itens, tais como TextField, DateField, ChoiceGroup, Gauge, ImageItem e StringItem. Assim, o Form disponibiliza métodos como insert, para adicionar um Item, delete, para remover um Item, além de outros métodos úteis, como append e set. List, por sua vez, é responsável por criar listas seletivas. Podem ser listas de múltipla escolha ou única escolha, sendo os itens selecionados pelas teclas de navegação ou teclas de atalho do aparelho. Por fim, a TextBox, como o próprio nome diz, é uma caixa de texto. Uma instância de TextBox possui um título que é mostrado na parte superior da tela, um subtítulo ou texto descritivo, o tamanho da caixa (em caracteres) e o tipo de dado do campo. A Figura 6 mostra todos esses componentes, além da classe Canvas (responsável pelas telas de baixo nível, Command (comandos que são adicionados na tela para reger a navegação do aplicativo) e a interface CommandListener, responsável por definir ações para os comandos adicionados às telas. Figura 6
  8. 8. Classe Canvas Canvas é a derivada de Displayable (vide Figura 6) que permite ao programador uma manipulação da tela em mais baixo nível. Utilizando a classe Graphics, por exemplo, podem-se desenhar primitivas (quadrados, retângulos, linhas), inserir imagens e caracteres em qualquer posição da tela. Permite, ainda, a manipulação de threads para a criação de animações e a manipulação de eventos, que podem ser acionados pelas teclas do aparelho, por exemplo. No caso das animações, é usual utilizar a estratégia de renderização dependente de tempo. Para isso, o uso das classes Timer e TimerTask é recomendado. Pacote Game do MIDP 2.0 O MIDP 2.0 presenteia os programadores de jogos com um pacote especial para jogos, o Game API. Esse pacote provê uma série de classes que possibilita o desenvolvimento de jogos ricos para os dispositivos móveis. As classes disponibilizadas pelo pacote são: GameCanvas, Layer, LayerManager, TiledLayer e Sprite. A classe GameCanvas é uma subclasse de Canvas e provê as funcionalidades básicas de tela. GameCanvas traz uma série de melhorias em relação a Canvas, como a captura dos estados das teclas especiais e uma melhor sincronização gráfica. Layer é uma classe abstrata que representa um elemento visual do jogo, como um Sprite ou um TiledLayer. Layer provê atributos básicos, como a localização, o tamanho e a visibilidade do elemento. LayerManager, como o próprio nome diz, é um gerenciador de camadas. Através dessa classe, é possível trabalhar a interface do jogo em camadas, possibilitando que se façam alterações em uma camada enquanto outra está sendo mostrada na tela. Esse recurso é extremamente interessante para a criação de jogos. TiledLayer permite ao desenvolvedor a construção de grandes áreas gráficas que são subdivididas em células, denominadas tiles. Pode-se imaginar um TiledLayer como uma tabela dividida em linhas e colunas na qual cada célula apresenta uma imagem, que pode ser facilmente manipulada. Esse recurso facilita muito a construção dos jogos tile-based, tais como puzzles¸ rpgs, etc. Por fim, a classe Sprite, que permite a divisão de arquivos de imagens em frames, além de transformações sobre essas imagens e, ainda, detecção de colisão. Sprite provê uma série de métodos que tornam a animação de personagens uma tarefa fácil e rápida. Sprite também pode ser muito útil para criação de aplicações com interfaces ricas, podendo representar botões, barras de progresso e outros componentes de interface que possuam algum tipo de animação.
  9. 9. Persistência de dados no JavaME A persistência de dados no JavaME se dá através do RMS (Record Management Store), um esquema de armazenamento bastante simples. Uma aplicação pode acessar múltiplos Record Stores e cada um pode ter uma quantidade variável de registros. Alguns aparelhos limitam o tamanho máximo de um Record Store (para a ordem de algumas dezenas ou centenas de Kbytes), aconselhando-se, assim, que os mesmos possuam tamanho reduzido. O RMS possui recursos interessantes, como navegar pelos registros através de uma enumeração que é instância da classe RecordEnumeration, além de filtrá-los da maneira que o programador preferir, implementando uma classe de filtro que herda de RecordFilter e, também, ordená-los de forma adequada, implementando uma classe comparadora que herda de RecordComparator. O armazenamento dos registros no RMS é seqüencial, bem como o seu acesso, que é relativamente lento. Se o RMS for muito grande, poderá haver atrasos significativos no acesso aos registros, principalmente quando estiverem sendo utilizados filtros e comparadores nas consultas. A Figura 7 mostra como funciona o RMS internamente. Como se pode notar, o acesso é seqüencial, pouco diferindo da leitura de um arquivo, por exemplo. Figura 7 APIs opcionais Além das classes acima citadas, disponibilizadas obrigatoriamente em uma implementação JavaME com configuração e perfil adequados, vários outros pacotes podem estar disponíveis para o programador. São as chamadas APIs opcionais, disponibilizadas através de JSRs (Java Specification Requests). Essas APIs estão disponíveis em alguns aparelhos e em outros não, dependendo exclusivamente das capacidades do mesmo e da vontade do fabricante em questão em fornecê-las. Entre
  10. 10. elas, destacam-se: WMA 2.0 (Wireless Messaging API), disponibilizada com a JSR 205 e que permite o envio e recebimento de SMS/MMS; MMAPI 1.1 (Mobile Media API), disponibilizada com a JSR 135 e que permite a manipulação da câmera do aparelho e outros recursos multimídia; Bluetooth API, disponibilizada com a JSR 82 e que permite comunicação entre aplicações através de Bluetooth; Mobile 3D Graphics API, disponibilizada através da JSR 184 e que permite a criação de jogos e aplicações tridimensionais; entre outras. Algumas dessas APIs serão mostradas no decorrer do minicurso. Conhecendo os celulares Após testar as aplicações no emulador, é necessário estudar os dispositivos para os quais se pretende portar a aplicação, suas capacidades e limitações. No caso da Nokia, o Fórum Nokia possui um acervo com todos os dispositivos da empresa e suas respectivas especificações, que pode ser acessado em http://forum.nokia.com. Cada aparelho listado possui informações de memória disponível, capacidade de processamento, dimensões de tela e, ainda, características específicas da implementação do JavaME naquele aparelho, como a configuração utilizada (CLDC 1.0 ou 1.1), o perfil (MIDP 1.0, 2.0 ou 2.1) e as APIs opcionais que ele apresenta. Além disso, é possível baixar os kits de desenvolvimento para o grupo de aparelhos no qual se está desenvolvendo. No caso da Nokia, existem emuladores para cada família de aparelhos (Series 40 ou Series 60). Esses emuladores representam com maior fidelidade a máquina Java daqueles aparelhos e, com isso, tem-se uma garantia maior que sua aplicação funcionará adequadamente nesses dispositivos. Referências [FONSECA, 2005] Fonseca, Enrico. iMasters – Ciclo de vida do MIDlet. Disponível em: http://imasters.uol.com.br/artigo/3416/java/ciclo_de_vida_do_midlet. Acessado em 13 de janeiro de 2008. [SUN, 2008] Sun Microsystems – Sun Developer Network (SDN). JavaME Technology – Powering your Devices Everywhere. Disponível em: http://java.sun.com/javame/technology/index.jsp. Acessado em 13 de janeiro de 2008.

×