1. Java Micro Edition (Java ME) é uma plataforma Java para dispositivos móveis com recursos limitados como celulares. 2. A plataforma é modular e escalável, organizada em camadas como a máquina virtual KVM, configurações como CLDC e perfis como MIDP. 3. MIDlets são aplicativos Java ME empacotados em arquivos JAR e JAD para execução em dispositivos móveis.

1. Java Micro Edition

2. Agenda JavaME, CLDC, MIDP Fragmentação MIDlets Interface com usuário

3. JavaME, CLDC, MIDP Java Micro Edition, introdução a plataforma Java para dispsitivos móveis

4. Plataforma Java Linguagem (incluindo compilador e ferramentas de apoio). Ambiente de execução (Java Virtual Machine). Biblioteca (Java API - Application Programming Interface).

5. Edições da Plataforma Java J2SE (Java 2 StandardEdition) –edição padrão que estabelece ambiente de execução voltado a aplicativos para computadores pessoais e estações de trabalho. Define um núcleo básico de funcionalidades, comum a todas as edições. J2EE(Java 2 Enterprise Edition) –é um superconjuntoda edição padrão, voltada para o desenvolvimento de servidores e aplicativos corporativos orientados a transações e apoiado em bases de dados, para atender clientes, fornecedores e empregados. J2ME(Java 2 Micro Edition) –estabelece um ambiente de execução para sistemas embutidos/embarcados e dispositivos portáteis, incluindo telefones celulares, PDAs e set-top boxes, que possuem recursos limitados (memória, processamento, velocidade de comunicação,...), insuficientes para comportar as plataformas J2SE ou J2EE.

6. Edições da Plataforma Java

7. Plataforma Java ME Modular e escalável, organizada em camadas Máquina virtual (KVM –KilobyteVirtual Machine) Configuração (Configuration) Perfil (Profile) e pacotes opcionais

8. Plataforma Java ME

9. KVM KilobyteVirtual Machine Versão reduzida da JVM da edição J2SE Tipicamente 40KB –80KB Para dispositivos com pouca memória (≤128KB) Processador 16-32bits

10. Configuração Define as características mínimas da plataforma estabelecendo categoria de dispositivos com recursos similares em tamanho de memória, capacidade de processamento e conectividade. A camada de configuração e a características da máquina virtual estão intimamente relacionada. Uma determinada configuração estabelece Os aspectos da linguagem Java suportados As características da máquina virtual java As bibliotecas (APIs) suportadas

11. Configurações CLDC (Connected Limited Device Configuration): Tipicamente, dispositivo com pouca memória (160KB-512KB)processador de 16-32 bits e conexão wireless. Exemplos: celular e PDA. CDC (Connected Device Configuration): Tipicamente, dispositivo com mais memória (≥2MB), processor de 64 bits ou mais e conexão fixa (tipicamente). Exemplo: set-top boxe web phone.

12. CLDC 1.0 (JSR 30) Memória mínima 160KB (sendo 32KB para heap)• Processador 16-32 bits Segurança: processo de pré-verificação Não suporta ponto-flutuante Limitações no tratamento de erros Sem finalização automática -Object.finalize() Não permite a chamada de código nativo (Java Native Interface) Não suporta carregadores de classe definidos pelo usuário Não suporta reflexão Suporta multithreading, mas não grupos de threadse threads demons Não suporta a referências fracas (weak references)

13. CLDC 1.1 (JSR 139) Memória mínima 192KB (sendo 32KB para heap) Suporta ponto-flutuante Suporte a referências fracas (weak references) Threads com nomes

14. CLDC Processo de verificação Pré-verificação Realizado na estação de desenvolvimento, após a compilação. Geração e inserção de informações no arquivos de classe, que permite o teste da integridade do arquivo de classe no momento de carga. Verificação Realizada no dispositivo. Varredura do código e a informação gerada pela pré-verificação. Verifica a aderência do código às regras da linguagem, entre outras: Variáveis locais devem ser inicializadas antes do uso; Após a criação de um objeto, o seu construtor deve ser executado, antes do uso do objeto; Todo construtor deve começar evocando o construtor da superclasse

15. Processo de verificação

16. CLDC - Bibliotecas Classes J2SE CLDC um suporta um subconjunto de classes da plataforma J2SE. As classes derivadas da plataforma J2SE são versões, em geral, com um conjunto menor de métodos do que versão original J2SE. Pacotes: java.lang java.io java.util Classes CLDC (Generic Connection Framework) Pacote javax.microediton.io

17. Perfil Suporta serviços de mais alto-nível para uma classe de dispositivos (tais como aparelhos celulares, set-top boxes, etc.), incluindo: Criação e gerenciamento de aplicativos Interface com usuário Armazenamento persistente

18. Perfis para dispositivos móveis MIDP: Mobile Information Device Profile MIDP 1.0 (JSR 37): suportado por dispositivos mais antigos MIDP 2.0/2.1(JSR 118): Amplamente suportado pelos dispositivos atuais MIDP 3.0 (JSR 271) Ainda em especifiação, “Proposed final draft: 28 May, 2009”

19. Mobile Information Device Profile (MIDP) MIDP 1.0 (JSR 37) requisitos mínimos Memória 128KB de memória não-volátil para a implementação MIDP 32KB de memória volátil para alocação dinâmica (heap) 8KB de memória não-volátil para armazenamento persistente Display Tamanho tela: 96x54 pixels Cor: 1 bit (display depth), Monocromático Aspect ratio: 1:1 Entrada Teclado de telefone (one-handed keypad) e/ou Teclado QWERTY (two-handed keyboard) e/ou Tela sensível ao toque (touch screen) Conectividade 2-vias, wireless, possivelmente intermitente, e com faixa limitada

20. MIDP 1.0, bibliotecas Pacotes javax.microediton.midlet (aplicativos para MID) javax.microedition.lcdui (interface com o usuário) javax.microedition.rms (memória persistente)

21. Perfil mais recente MIDP 2.0 (JSR 118) –requisitos mínimos Memória 256KB de memória não-volátil para a implementação MIDP (além do requisitado pelo CLDC) 128KB de memória volátil para alocação dinâmica (heap) 8KB de memória não-volátil para armazenamento persistente Display Tamanho tela: 96x54 pixels Cor: 1 bit (display depth) –monocromático Aspect ratio: 1:1 Entrada Teclado de telefone (one-handed keypad) e/ou Teclado QWERTY (two-handed keyboard) e/ou Tela sensível ao toque (touch screen) Conectividade 2-vias, wireless, possivelmente intermitente e com faixa limitada Áudio Suportar em hardware ou software WAV e MIDI

22. MIDP 2.0, bibliotecas Pacotes javax.microediton.midlet(aplicativos para MID) javax.microedition.lcdui(interface com o usuário) javax.microedition.lcdui.game (suporte a jogos) javax.microedition.rms(memória persistente) javax.microedition.media (controle e processamento de áudio) javax.microedition.media.control (controle e processamento de áudio)

23. Pacotes opcionais WMA (JSR120) MMAPI (JSR135) Web Services(JSR172) Security and Trust (JSR177) Location (JSR179) SIP (JSR180) Mobile 3D (JSR184) JTWI (JSR185) WMA 2.0 (JSR205) Content Handler (JSR211) SVG (JSR226) Payment API (JSR229) AMS (JSR234) Internacionalization (JSR238) Open GL(JSR239) MSA(JSR248) Mobile Sensor (JSR256) File PIM(JSR75) Bluetooth(JSR82) Mascot Capsule V3 Nokia UI API 1.1, VSCL2.0 Conjunto de APIs que estendem as funcionalidades básicas definidas no perfil Exemplo, Sony Ericsson W905

25. 2. Fragmentação

26. Fragmentação A plataforma Java ME foi concebida com o objetivo de propiciar portabilidade de aplicações entre dispositivos “ Write once, run every where” Entretanto as limitações do MIDP levaram fabricantes a definir APIs para funcionalidades específicas de seus dispositivos Algumas delas sendo padronizadas na forma de pacotes opctionais A diversidade de implementações levou a fragmentação da plataforma JavaME Diferentes dispositivos suportando diferentes APIs Diferentes tipos de interfaces com usuário Grande variação de recursos como memória A maioria das APIs têm implementação nativa Isso inviabiliza a “instalação” de APIs em dispositivos

27. Fragmentação Como solucionar o problema? A comunidade Java tem criado especificações “umbrella” que definem um denominador comum para a plataforma JavaME JSR 185 –Java Tecnology for the Wireless Industry JSR 248 –Mobile Service Architecture JSR 249 –Mobile Service Architecture Advanced “ Public Review, 23 Feb 2009”

28. JTWI, MSA1 e MSA2

29. Fragmentação A fragmentação da plataforma JavaME cria um problema de portabilidade de aplicações Entre diferentes fabricantes ou mesmo na família de dispositivos de um único fabricante A plataforma JavaME tem recebido outras críticas Lentidão da JCP na definição de novas especificações A demora pelo MIDP3 tem sofrido fortes críticas Mecanismos de segurança baseado em assinuatura protegem operadoras, mas limitam desenvolvedores

30. Fragmentação Plataformas de aplicações mais recentes tem surgido com a promessa de solucionar esses problemas e ameaçar o JavaME Flash Lite da Adobe (Action Script) Android do Google/OHA (HTC, Motorola, Sony Ericsson, Samsung...) OSGI Mobile da Sprint webOS da Palm (HTLM, CSS e JavaScript)

31. 3. MIDlets

32. MIDlets O termo MIDlet utilizado para designar o aplicativo implementado para ser executado em dispositivos MIDP. MIDlet é derivado da classe abstrata javax.microedition.midlet.MIDlet. Um conjunto de MIDlets podem ser agrupados em uma MIDlet suite. Todos os MIDlets de uma suite são carregados, instalados e desinstalados como uma entidade única.

33. Empacotamento Um MIDlet é empacotado para distribuição (download) em dois arquivos Arquivo JAR (JavaARchive) Código das classes (bytecode) compactado para execução Recursos (arquivos de áudio, imagem, vídeo, xml, etc...) Manifesto discriminando conteúdo do JAR Arquivo JAD (Java Application Descriptor) Indormações descritivas do MIDlet (não contém código nem arquivos de recursos) Informações obrigatórias incluem tamanho em bytes do JAR e sua URL

34. Exemplo de Manifesto Manifest-Version: 1.0 MicroEdition-Configuration: CLDC-1.1 MIDlet-Name: TestMIDlet MIDlet-Vendor: Midlet Suite Vendor MIDlet-1: TestMIDlet, ,com.venturus.TestMIDlet MIDlet-Version: 1.0.0 MicroEdition-Profile: MIDP-2.0

35. Exemplo de JAD MIDlet-1:TestMIDlet,,com.venturus.TestMIDlet MIDlet-Jar-Size: 852 MIDlet-Jar-URL:TestMIDlet.jar MIDlet-Name:TestMIDlet MIDlet-Vendor:Midlet Suite Vendor MIDlet-Version: 1.0.0 MicroEdition-Configuration: CLDC-1.1 MicroEdition-Profile: MIDP-2.0

36. MIDlet, ciclo de vida Assim como um Applet, um MIDlet é um aplicativo gerenciado Applet é gerenciado pelo navegador (“browser”). MIDlet é gerenciado por programa de gerenciamento implementado no dispositivo (AMS –Application Management Software). O gerenciamento do ciclo de vida do MIDlet é exercido através da execução dos seguintes métodos do MIDlet startApp() pauseApp() destroyApp()

37. Estrutura de um MIDlet

38. MIDlet, ciclo de vida O ciclo de vida de umMIDlet é composto de 3 estados Parado (paused) O MIDlet foi carregado e o construtor foi executado. Ativo (active) O MIDlet está ativo, em execução. Destruído (destroyed) O MIDlet terminou e aguarda o descarte pelo garbage coletor

39. MIDlet, ciclo de vida

40. Estado ativo Em algum instante após a construção, com o MIDlet no estado parado, o dispositivo (AMS) executa o método startApp(). Após o retorno deste método, o MIDlet encontra-se no estado ativo. Tipicamente, startApp() efetua as inicializaçõesn ecessárias, cria e apresenta a interface com o usuário. Se durante a execução de startApp() não for possível realizar alguma inicialização, o disparo da exceção MIDletStateChangeException destrói o MIDlet, com a respectiva execução pelo AMS do método destroyApp().

41. MIDlet, solicitação de mudança de estado

42. 4. Interface com usuário

43. Interface com usuário Pacote LCDUI Suporte de alto-nível Maior abstração para desenvolvedor Componentes gráficos predefinidos Automaticamente adaptáveis a diferentes dispositivos com diferentes tamanho de telas Desenvolvedor tem pouco controle sobre “look and feel” Cor, formato, tamanho dos componentes não podem ser customizados Não permite acesso direto a eventos das teclas Suporte de baixo-nível Menor nível de abstração para desenvolvedor Posicionamento preciso dos elementos gráficos Permite acesso a eventos das teclas Pode comprometer portabilidade

44. Hierarquia de classes LCDUI

45. Screen Componentes Alert List TextBox Form

46. Displayable public abstract class Displayable extends Object Objeto que pode ser colocado no display. Um objeto displayable pode ter um título, um ticker, comandos e um listener a ele associados.

47. Classe Item Items são elementos que podem ser adicionados a um Form

48. Display public class Display extends Object Gerenciador da tela e dos dispositivos de entrada. Existe apenas um display para cada MIDlet Método para ter acesso ao display Static Display getDisplay(MIDlet midlet) Método para requisitar que objeto Displayable seja apresentado na tela void setCurrent(Displayable nextDisplayable)

49. Comandos public class Command extends Object Construtor Command(String label, int commandType, int priority) CommandType BACK, CANCEL, EXIT, HELP, ITEM, OK, SCREEN, STOP. Indicar o propósito do comando. Dispositivo faz mapeamento para softkey que julgar apropriada. Priority Dispositivo, caso necessário, privilegia acesso ao comando. Comando é tratado por CommandListener

50. CommandListener public interface CommandListener Usada por aplicações para receber eventos de comandos A aplicação deverá criar uma classe que implemente a interface Uma instância do objeto da classe deve ser passado para o método addCommand do objeto Displayable em questão Como um método de sistema, sua execução deve retornar assim que possível Considerar a criação de uma Thread para o tratamento do evento Método a ser implementado commandAction (Command c, Displayable d)

51. Exercício 1

52. Questions