• Save
Introdução a JavaME
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
4,194
On Slideshare
4,164
From Embeds
30
Number of Embeds
3

Actions

Shares
Downloads
1
Comments
0
Likes
7

Embeds 30

http://cursomobile.blogspot.com.br 26
http://www.linkedin.com 3
http://www.slideshare.net 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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
  • 24.  
  • 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