J2ME-tutorial Author: Rossano Pablo Pinto Mon Apr 14 10:14:14 BRT 2003 1. Definições 1.1 Configurations É uma especificação que define o ambiente de software para uma faixa de dispositivos definidos por um conjunto de características que a especificação se baseia, geralmente características como: * Tipo e quantidade de memória disponível * Tipo de processador e velocidade * Tipo de conexão de rede disponível para o dispositivo Cada configuração consiste de uma máquina virtual Java e uma coleção de classes base que fornecem o ambiente de programação para as aplicações de software. Atualmente o J2ME define 2 configurações: * CLDC (Connected Limited Device Configuration) - Mínimo de 512 KB de memória - KVM (Kilobyte Virtual Machine) . Não possui suporte aos tipos "float" e "double" . Garbage collector otimizado para ambientes com pouca memória . Possui implementação para dispositivos Palm (midp4palm) * CDC (Connected Device Configuration) - Mínimo de 2 MB de memória - CVM (CVM - não expande-se mais o acrônimo para "Compact VM") . Só não inclui a tecnologia HotSpot e JIT . NÃO possui implementação para dispositivos Palm 1.2 Profiles Profiles permitem complementar uma configuração pela adição de classes que provêem características apropriadas para um tipo particular de dispositivo ou segmento de mercado. Atualmente, as seguintes profiles estão disponíveis: * MIDP (Mobile Information Device Profile) - Esta profile adiciona ao CLDC: . Networking . User Interface Components . Local Storage - Está completa (implementada) e disponível (pacote mid4palm.zip) * PDAP (PDA Profile) - Mais pesada e completa que MIDP - Esta profile adiciona ao CLDC: . More sophisticated User Interface Library . Java-Based API for accessing useful features of the host O.S. - Voltada realmente para PDAs como dispositivos Palm e Handspring * Foundation Profile (FP) - Estende a configuração CDC incluindo praticamente toda a core API do Java 2 SE 1.3 - Para CDC - É a base para toda profile CDC * Personal Basis - Adiciona interface básica de usuário ao FP - Para CDC - Está disponível (Precisa fazer registro no Sun Download Center) Arquivo: j2me_pb-1_0-fcs-src-b45-linux-i686-15_jul_2002.zip * Personal Profile - Adiciona interface mais complexa de usuário ao FP . AWT completa . Applets . Xlet - Para CDC - Está disponível em http://java.sun.com/products/personalprofile/j2me_pp-1_0-bin-linux-i686.zip * RMI Profile (Remote Method Invocation Profile) - Permite criar, SOMENTE, clientes RMI - Para CDC (Mas acredito que possa ser utilizada em cima de CLDC em dispositivos PDA, mas seria preciso utilizar FP também) - Está disponível (Precisa fazer registro no Sun Download Center) Arquivo: j2me_rmiop-1_0-fcs-src-b52-30_May_2002.zip * Game Profile - Auto explicativa - Para CDC - Está em processo de especificação (não sabe-se se vai ser baseada na FP ou diretamente no CDC) * JDBC(TM) Standard Extension Binary 2.0 (Java Data Base Connectivity) - Está disponível Arquivo: jdbc2_0-stdext.jar 2. Connected Limited Device Configuration A configuração mínima para o CLDC é: * 128 KB de memória ROM, flash ou outra para armazenar a KVM e as classes CLDC * 32 KB de memória volátil para runtime OBS: Lembre-se que a KVM é o nome da implementação de uma JVM CLDC da Sun Microsystems, inc. CLDC assume que o dispositivo NÃO possui (mas pode possuir): * teclado, mouse etc.. * local para armazenar dados da aplicação A máquina virtual da configuração CLDC é especificada em termos do que não precisa ter da máquina virtual J2SE. Restrições da KVM: * Suporte a ponto-flutuante - Operações do byte-code não implementadas dadd | dload | dsub | fcmpl | frem | i2d daload | dload_x | d2f | fconst_0 | freturn | i2f dastore | dmul | d2i | fconst_1 | fstore | l2d dcmpg | dneg | d2l | fdiv | fstore_x | l2f dcmpl | drem | fadd | fload | fsub | newarray (double) dconst_0 | dreturn | faload | fload_x | f2d | newarray (float) dconst_1 | dstore | fastore | fmul | f2i | ddiv | dstore_x | fcmpg | fneg | f2l | Com efeito, qualquer operação que envolva float ou double não podem ser executadas. Já que estas operações não são possíveis, até as classes Float e Double não existem em CLDC. Mas como então elas passam pela compilação? É que a Sun NÃO fornece um compilador adicional para J2ME. O próprio compilador do J2SE é utilizado para gerar as classes de uma aplicação J2ME. O problema só vai acontecer na hora do "class loading". Ah tá. * Omissões de linguagem - Reflexão. Falta o pacote java.lang.reflect - Weak References. Falta o pacote java.lang.ref - Finalização de Objeto. A classe java.lang.Object não possui o método finalize() - Threading. Não é possível criar uma "daemon thread" ou "thread groups" - Erros e Exceções. .... - Java Native Interface. .... * Carregamento de Classes ........... Segurança * Uma CLDC VM roda as aplicações em uma "sandbox" * Controle do carregamento de classes é desabilitado * Verificação de classes é executada em dois estágios: 1. ... 2. ... Pacotes do CLDC * javax.microedition.io * javax.microedition.lang * java.io * java.lang * java.util Obs.: io, lang e util não possuem todos os elementos presentes no J2SE, por exemplo, java.util.Properties não está presente. 3. MIDP (Mobile Information Device Profile) Especificações mínimas: - Display: 96x54 1 bit - Input: teclado e/ou touch screen - Memória: 32 KB volátil (Java runtime - heap); 128 KB não-volátil (componentes MIDP); 8 KB não volátil (dados persistentes de aplicação) - Rede: conexão two-way intermitente, geralmete sem fio, banda limitada Adições ao CLDC: - Gerenciamento do ciclo de vida das aplicações (pacote javax.microedition.midlet) - Eventos e Interface de Usuário (pacotes javax.microedition.lcdui) - Conectividade de Rede (interface HttpConnection e implementação mínima do protocolo HTTP) - Armazenamento de Dados no Dispositivo (pacote javax.microedition.rms - sistema de gerenciamento de base de dados baseado em registros) - Adição das classes java.lang.IllegalStateException, java.util.Timer e java.util.TimerTask MIDlets (Lembra o nome Applet né? Então deduza algumas infos): - estados possíveis: || \/ +-----> Paused ------+ | || | | \/ | pauseApp() startApp() | | ________ | +------| Active | | +----->|________| | | | destroyApp() destroyApp() | | +----- Destroyed <---+ - MIDlet suite . 2+ MIDlets empacotados no mesmo arquivo JAR. Estes MIDlets podem compartilhar os recursos empacotados no JAR . Cada MIDlet de um MSu pode ser considerado (a grosso modo) como um menu de uma aplicação de desktop, pois vai ser exibida uma tela de escolha do MIDlet para execução: +------------------------------------------------+ | ------ | | | ---> | Jogo da Cobra | | ------ | | | | ------ | | | ---> | Navegador WEB | | ------ | | | | ------ | | | ---> | Jogo da Memória | | ------ | | | +------------------------------------------------+ . JAR Manifest - contém atributos que descrevem o conteúdo do arquivo JAR e servem para o software de gerenciamento de aplicação identificar e instalar o MIDlet suite. Atributos obrigatórios (já com exemplo de arquivo): MIDlet-1: RPP-Autentica, RPP-Autentica.png, wirelessBook.LoginMidlet MIDlet-Name: RPP-Autentica MIDlet-Vendor: Sun Microsystems MIDlet-Version: 1.0 MicroEdition-Configuration: CLDC-1.0 MicroEdition-Profile: MIDP-2.0 . JAD (Java Application Descriptor) Utilizado pelo Java Application Manager para verificar se o arquivo JAR pode ser instalado no dispositivo alvo. Exemplo com os campos obrigatórios: MIDlet-1: RPP-Autentica, RPP-Autentica.png, wirelessBook.LoginMidlet MIDlet-Jar-Size: 2037 MIDlet-Jar-URL: RPP-Autentica.jar MIDlet-Name: RPP-Autentica MIDlet-Vendor: Sun Microsystems MIDlet-Version: 1.0 MicroEdition-Configuration: CLDC-1.0 MicroEdition-Profile: MIDP-2.0 - Esqueleto de um MIDlet import javax.microedition.midlet.*; public class MyMIDlet extends MIDlet { public MyMIDlet() { // Eu sou o construtor da classe, observe que não possuo um // tipo de retorno (nem mesmo void) } public void startApp() { // Sou responsável em inicializar a aplicação. Eu faço o MIDlet // mover-se do estado PAUSED para ACTIVE. Tipicamente eu inicializo // os objetos que serão utilizados ao longo do ciclo de vida do // MIDlet e seto o display corrente. MAS OBSERVE QUE POSSO SER // CHAMADO MAIS DE UMA VEZ (TALVEZ OS OBJETOS QUE DEVEM SER // INICIALIZADOS APENAS UMA VEZ DEVAM SER COLOCADOS NO CONSTRUTOR) } public void pauseApp() { // Eu sou chamado quando o MIDlet está indo do estado ACTIVE para // o estado PAUSED. Isso "pausará" toda thread ativa e // opcionalmente setará o display que deverá ser exibido na // próxima vez que o MIDlet tornar-se ativo. } public void destroyApp(boolean unconditional) { // Sou chamado para mudar o estado do MIDlet de PAUSED para // DESTROYED. Geralmente devo liberar todo recurso alocado. } } - The Application Manager (AMS) . É um software pré-instalado em um dispositivo MIDP que funciona como um ambiente operacional. O AMS deve ser capaz de: .. Obter um MIDlet suite (MSu) de algum lugar, possivelmente através de uma conexão serial, infra-vermelha, bluetooth, etc.. .. Instalar um MSu no dispositivo .. Exercer gerenciamento de versão nos MSu instalados .. Executar um MIDlet de um MSu e prover o ambiente operacional para a KVM e as classes de sistema, MIDP ou CLDC .. Remover um MSu . O AMS que é responsável em chamar os métodos construtor, startApp(), pauseApp() e destroyApp(). . É possível que o próprio MIDlet mude seu estado. Para isso os métodos a seguir devem ser utilizados: .. public void notifyPause() - muda estado para PAUSED .. public void resumeRequest() - expressa interesse em ser colocado no estado ACTIVE. O AMS utiliza essa informação para saber qual MIDlet deve ter seu método startApp() executado .. public void notifyDestroyed() - Suicídio