O documento discute a plataforma Java Micro Edition (JME), resumindo: 1) O crescimento da telefonia móvel no Brasil e as configurações e perfis da plataforma JME para dispositivos móveis de baixa capacidade; 2) Os requisitos de hardware e software para rodar aplicações JME; 3) O sistema de gerenciamento de aplicações e alguns frameworks populares para desenvolvimento de aplicações JME.

1. Java Micro Edition João G. Birk

4. O que é a plataforma JME ? JME é uma plataforma para pequenos dispositivos que são eventualmente planejados para substituir os vários produtos baseados em JDK 1.3, com uma solução mais unificada baseada em Java. Diferentemente das aplicações feitas com JSE e JEE, aplicações para microeletrônicos incluem uma coleção de dispositivos com capacidades muito diferentes, não sendo possível criar um único software para funcionar nos vários dispositivos. Em vez de ser uma única entidade, JME é uma coleção de especificações que definem um conjunto de plataformas, cada uma das quais são satisfatórias para um subconjunto do total da coleção dos dispositivos.

5. Configurations (CLDC, CDC) Uma configuração é uma especificação que define o ambiente de software para um conjunto de dispositivos, definido por um conjunto de características que a especificação está relacionada, normalmente tais características são: - Os tipos e o total de memória disponível; - O tipo de processador e velocidade; - O tipo de conexão de rede disponível ao dispositivo; - Segurança, internacionalização.

6. Configurations (CLDC, CDC) É exigido dos vendedores, que implementem a especificação completa dos requisitos, de forma que os desenvolvedores possam confiar em um ambiente de programação consistente e, então, criar aplicações que são tão independentes do dispositivo quanto possível. JME define duas configurações atualmente, CLDC e CDC.

8. Configurations (CLDC, CDC)

9. Configurations (CLDC, CDC) O que CLDC Não Possui: Reflexão: O pacote java.lang.reflect e todas as características de java.lang.Class que são conectadas com reflexão não estão disponíveis. Esta restrição é aplicada para economizar memória. Objeto finalization: O Objeto finalization causa grande complexidade na VM para relativamente pouco benefício. Então, finalization não é implementado, e a classe CLDC do pacote java.lang.Object não tem um método finalize(). Fatores de Threading: CLDC provê threads, porém não permite a criação de uma thread daemon (uma thread que é automaticamente encerrada quando toda thread não daemon na VM termina), ou grupos de threads.

10. Configurations (CLDC, CDC) Erros e Exceções: JSE tem um grande número de classes que representam condições de erros e de exceções. A grande maioria delas não está incluída na plataforma CLDC. Interface Nativa Java: CLDC não provê a JNI (Java Native Interface) de JSE que permite chamar código nativo de classes Java. A JNI foi omitida devido ao fato que é muito custosa em termos de memória, e para proteger dispositivos de CLDC contra problemas de segurança causada por código malicioso de aplicações.

11. Configurations (CLDC, CDC) Classes Herdadas de JSE Classes de sistema: java.lang.Class java.lang.Object java.lang.Runnable java.lang.Runtime java.lang.String java.lang.StringBuffer java.lang.System java.lang.Thread java.lang.Throwable java.lang.ref.Reference java.lang.ref.WeakReference Classes de Tipos de Dados: java.lang.Boolean java.lang.Byte java.lang.Character java.lang.Double java.lang.Float java.lang.Integer java.lang.Long java.lang.Short

12. Configurations (CLDC, CDC) Classes Herdadas de JSE Classes de Coleções: java.util.Enumeration java.util.Hashtable java.util.Stack java.util.Vector Classes de Entrada/Saída: java.io.ByteArrayInputStream java.io.ByteArrayOutputStream java.io.DataInput java.io.DataInputStream java.io.DataOutput java.io.DataOutputStream java.io.InputStream java.io.InputStreamReader java.io.OutputStream java.io.OutputStreamWriter java.io.PrintStream java.io.Reader java.io.Writer

13. Configurations (CLDC, CDC) Classes Herdadas de JSE Classes Calendar e Time: java.util.Calendar java.util.Date java.util.TimeZone Classes Utilitárias: java.lang.Math java.lang.Random Classes de Tratamento de Erros: java.lang.Error java.langa.NoClassDefFoundError java.lang.OutOfMemmoryError java.lang.VirtualMachineError

14. Configurations (CLDC, CDC) Classes Herdadas de JSE Classes de Tratamento de Exceções: java.io.EOFException java.io.InterruptedIOException java.io.IOException java.io.UnsupportedEncodingException java.io.UTFDataFormatException java.lang.ArithmeticException java.lang.ArrayIndexOutOfBoundsException java.lang.ArrayStoreException java.lang.ClassCastException java.lang.ClassNotFoundException java.lang.Exception java.lang.IllegalAccessException java.lang.IllegalArgumentException java.lang.IllegalMonitorStateException java.lang.IllegalThreadStateException java.lang.IndexOutOfBoundsException java.lang.InstantiationException java.lang.InterruptedException java.lang.NegativeArraySizeException java.lang.NullPointerException java.lang.NumberFormatException java.lang.RuntimeException java.lang.SecurityException java.lang.StringIndexOutOfBoundsException java.util.EmptyStackException java.util.NoSuchElementException

15. Profiles (MIDP) Um perfil complementa uma configuração trazendo classes adicionais que provêem características distintas em um tipo particular de dispositivo ou equipamento de mercado. Ambas as configurações JME têm um ou mais perfis associados, alguns dos quais podem descrever outros perfis. A figura abaixo mostra os perfis existentes atualmente. Estes processos são descritos na listagem a seguir.

16. Profiles (MIDP)

17. Profiles (MIDP) Mobile Information Device Profile (MIDP): Este perfil acrescenta placa de rede, componentes de interface de usuário, e armazenamento local para CLDC. Este perfil é principalmente projetado para os limitados displays e para facilidades de armazenamento em telefones móveis, provendo uma interface de usuário relativamente simples e comunicação de rede baseada em HTTP 1.1. Foundation Profile: O Foundation Profile estende o CDC para incluir quase tudo das bibliotecas de Java 1.3. Como sugere seu nome, pode ser usado como base para a maioria dos outros perfis de CDC.

18. Profiles (MIDP) Personal Basis Profile e Personal Profile: As bases pessoais e perfis pessoais acrescentam funcionalidades de interface de usuário básica ao Foundation Profile. Pode ser usado em dispositivos que têm uma interface de usuário não muito sofisticada, e não permite mais do que uma janela ser ativa a qualquer tempo. Plataformas que podem necessitar de uma interface de usuário mais complexa usarão o Personal Profile.

19. Requisitos de Hardware e Software As limitações de hardware e de software, que são impostas pelos dispositivos os quais o CLDC é focado, tornam impraticável o uso de uma JVM de JSE completa. Abaixo segue uma listagem dos requisitos de hardware e software para rodar uma aplicação em CLDC: - O vídeo deve suportar pelo menos 125X125 pixels; - Display com no mínimo 4096 cores (8bits); - No mínimo 256 KB de memória volátil (heap size); - JAR Size de no mínimo 64 KB; - JAD Size de no mínimo 5 KB; - No mínimo 30 KB de memória não volátil; - No mínimo 10 Threads simultâneas; - No mínimo 5 Record Stores; - No mínimo 5 Timers;

21. AMS (Application Management System) Um MIDlet é uma aplicação que é construída dentro da classe MIDlet. O application management system comunica-se com a MIDlet através de métodos nesta classe. Esta comunicação é um caminho bi-partido, por exemplo, somente a application management system pode dar um pause em um MIDlet (para permitir ao usuário responder uma chamada de ligação), um MIDlet pode efetuar um pedido para ser posto em estado de espera, ou seja, o estado pause, e futuramente retomar o processamento. O estado de um MIDlet pode estar dentro de um dos três estados possíveis: - Estado de Espera (paused): Um MIDlet é colocado no estado de pausa antes do construtor ter sido chamado para que o application management system possa executá-lo. Após ter chamado o construtor, o application

22. AMS (Application Management System) management system coloca o MIDlet em um estado ativo, o segundo estado possível de um MIDlet. Neste momento o MIDlet pode trocar inúmeras vezes do estado pause para o estado active, e vice-versa; - Ativo (active): O MIDlet está rodando; - Destruído: O MIDlet libera qualquer recurso que vinha utilizando, chama o destruidor e é desligado pelo application management system.

23. AMS (Application Management System)

24. AMS (Application Management System) Propriedades: Existe um conjunto limitado de propriedades que você pode perguntar a respeito do sistema. Abaixo segue uma lista de algumas das propriedades disponíveis, e uma única chamada de método para cada uma: Obtém o host da plataforma/dispositivo: - System.getProperty(“microedition.platform”); Obtém o caractere de codificação padrão: - System.getProperty(“microedition.encoding”);

25. AMS (Application Management System) Propriedades: Obtém a configuração de nome e versão suportada: - System.getProperty(“microedition.configuration”); Obtém os nomes de perfis suportados: - System.getProperty(“microedition.profiles”);

26. AMS (Application Management System) Uma aplicação típica executará as seguintes ações em resposta a chamadas para seus métodos MIDlet: startApp() - a aplicação está movendo-se do estado de pause ao estado ativo. A inicialização de objetos necessários enquanto a aplicação está ativa deve ser feita. A aplicação pode chamar setCurrent() para a primeira tela se isso já não foi feito. Perceba que startApp() pode ser chamado várias vezes se pauseApp() foi chamado neste meio tempo. Isto significa que aquela inicialização em tempo de execução não deve ser feita internamente neste método, mas sim dentro do construtor do MIDlet.

27. AMS (Application Management System) pauseApp() - a aplicação pode interromper suas linhas de execução (thread). Se for desejável reiniciar com outra tela, diferente da original, quando a aplicação é re-ativada, a tela nova deve ser informada utilizando o método setCurrent(). destroyApp() - a aplicação deve liberar recursos, encerrar linhas de execução, etc.

31. Frameworks: J2ME Polish

33. LWUIT (Lightweight User Interface Toolkit) Video: http://www.youtube.com/watch?v=FwaLJQpb7Hc

34. Frameworks: Floggy O Floggy (http://floggy.sourceforge.net) é um framework para persistência de dados em J2ME. O seu objetivo principal é abstrair os detalhes de implementação para se persistir informações em RecordStores reduzindo o custo de desenvolvimento e manutenção.

35. Frameworks: J2MEUnit O J2MEUnit (http://j2meunit.sourceforge.net) é um framework para criação de testes unitários para J2ME. Ele é baseado no framework JUnit.

38. Preprocessor Blocks Para evitar que tenhamos que escrever dois códigos fontes diferentes da mesma aplicação (para 2 aparelhos diferentes) podemos fazer uso dos blocos pré-processados, mantendo um único código e ainda em tempo de compilação, só o código que realmente interessa para aquela compilação será gerado o bytecode correspondente.

39. Aplicações no Mundo Real

40. Muito Obrigado! João G. Birk www.jlsoftware.com.br [email_address]