A plataforma Java vem se desenvolvendo continuamente, oferecendo suporte a uma crescente variedade de tipos de aplicativos. Como conseqüência, houve um grande aumento do seu tamanho, o que passou a conflitar com o objetivo do WORA (write once, run anywhere), uma vez que nem todo dispositivo oferecia suporte a processos que demandavam uma grande quantidade de memória.
Como uma primeira tentativa de contornar o problema, a Sun introduziu, em 1997, uma variedade de plataformas Java, cada uma voltada a um segmento do mercado, sendo que a principal diferença entre elas era o subconjunto da API do Java a que ofereciam suporte.
Conforme a tecnologia foi se desenvolvendo, sentiu-se a necessidade de se unificar as plataformas orientadas a dispositivo e, no evento JavaOne de 1999, a Sun apresentou o Java 2 Micro Edition, que é uma arquitetura que permite o uso da tecnologia Java em dispositivos com diversas características e funcionalidades.
Configurações
Uma configuração define uma API e uma máquina virtual otimizada para servir dispositivos que possuem determinadas características e recursos.
Duas configurações foram definidas: a CDC (Connected Device Configuration), voltada a dispositivos que ofereçam, no mínimo, 512K ROM e 256K RAM, além de suporte à implementação completa da JVM; e a CLDC (Connected, Limited Device Configuration), voltada a dispositivos com recursos mais limitados (mas que possuam conexões de rede), sendo que devem possuir, pelo menos, 128K a 512K de memória total disponível. Essa última categoria inclui os telefones celulares e PDAs, sendo a configuração utilizada em nosso projeto.
Profiles
Os profiles (perfis) definem bibliotecas de classes e APIs adicionais necessárias para permitir o desenvolvimento de aplicações específicas a um domínio, em uma configuração. Por exemplo, o MIDP (Mobile Information Device Profile) requere, pelo menos, a CLDC e permite o desenvolvimento de aplicações que oferecem acesso a informações via redes sem fio (wireless).
Os Profiles mais utilizados para desenvolvimento de aplicativos para PDAs e telefones celulares são:
- MIDP 1.0, que exige 128KB de memória não volátil, reservando 32KB para heap, 8 KB para persistência de dados, tela de 96x54 pixels, entrada de dados, conexões de rede (intermitentes) e segurança (conceito de sandbox das applets);
- MIDP 2.0, com segurança baseada em permissões do J2SE e adição de APIs para jogos, mídia e conexão segura.
KVM
A KVM ('K' Virtual Machine) é uma máquina virtual que oferece suporte ao J2ME em micro-controladores de 16 ou 32 bits. Voltada à CLDC, a KVM possui apenas 40K de código e precisa de poucos kilobytes para a sua execução.
Vantagens:
A KVM é realmente pequena e é possível personalizá-la. Diversas funcionalidades de máquinas virtuais e da linguagem que não eram necessárias para a maior parte das aplicações (como vetores multi dimensionais, pontos flutuantes, threads, manipulação de eventos, JNI, class loaders, entre outros) tornaram-se opcionais, sendo que a escolha de uma configuração em particular define o que deve ou não ser incluído na implementação da KVM.
Desvantagens:
Paradoxalmente, a maior desvantagem da KVM está relacionada à sua maior vantagem. Para manter o seu pequeno tamanho, a Sun comprometeu a linguagem e a máquina virtual, fazendo com que a programação em J2ME seja muito diferente da programação para Standard ou Enterprise Edition.
Além disso, a KVM não implementa a especificação da JVM (Java Virtual Machine) e, sim, parte dela. Isso significa que a característica WORA não ocorre em todas as aplicações J2ME, podendo não ser portáveis para todos os dispositivos. Em geral, as aplicações J2ME são portáveis entre os dispositivos que utilizam o mesmo profile.
MIDlet e seu Ciclo de Vida:
As MIDlets são aplicações desenvolvidas sobre a plataforma J2ME. Cada dispositivo possui um AMS (Aplication Manager System) que é responsável por controlar os aplicativos que serão instalado e, também, por administrar como serão armazenados e como será o seu comportamento durante a execução.
A MIDlet possui três estados:
- Started - aquisição de recursos e inicialização da execução (startApp);
- Paused - liberação de recursos em um modo de espera (pauseApp); e
- Destroyed - liberação completa de recursos (destroyApp)
Interface Gráfica
As APIs para desenvolvimento de interfaces gráficas em J2ME diferem muito das APIs do AWT (Abstract Window Toolkit) e Swing, utilizados para desenvolvimento de aplicativos para Desktops. A razão para tal diferença é o fato de que os recursos disponíveis em dispositivos móveis não são os mesmos recursos que existem nos Desktops, a começar pelo tamanho da tela e a ausência de mouses ou teclados, chegando a diferenças no tamanho da memória disponível para os aplicativos.
No J2ME, o CLDC não oferece nenhum recurso para o desenvolvimento de interfaces gráficas. As classes da GUI do J2ME são definidas pela JCP (Java Community Process) [jcp] e estão inclusas nos profiles, como o MIDP.
A estrutura para o desenvolvimento de interfaces gráficas é mostrada na figura abaixo:
Existem dois tipos de APIs para o desenvolvimento de interfaces gráficas: a High Level API e a Low Level API. A primeira consiste em classes, como Alert, List e Form, que são componentes com um nível de personalização e liberdade de criação baixo. Essa limitação existe para possibilitar a portabilidade das aplicações entre dispositivos diferentes, sendo que quando se utiliza a high-level API, a implementação se encarrega de fazer as adaptações necessárias para o hardware e o estilo da interface de usuário nativa do dispositivo.
Persistência
O RMS (Record Management System) [Muc02] é um ambiente de armazenamento persistente dentro do MIDP. O RMS é baseado em armazenamento de fluxos de dados.
Vamos entender um pouco de fluxo de dados [webmobile05]. Os fluxos permitem estabelecer canais de comunicação entre aplicativos e arquivos ou um dispositivo específico. Leitura de arquivos, enviar dados para o monitor, ler o teclado só conseguimos graças aos fluxos de dados que nos permite fazer essa comunicação. O
System.in e o System.out do Java são exemplos de fluxos de dados.
Assim, as tarefas de leitura e escrita de registros realizadas pelo RMS, podem ser vistas como atividades de fluxos que manipulam apenas bytes. Para permitir a persistência de diversos tipos de dados, utilizaremos classes de controle de fluxo.
Para escrever dados, dois fluxos são abertos. Um para manipular tipos de dados Java e outra para gerar um array de bytes, a partir do primeiro fluxo, para enviar para o repositório. Um esquema de leitura e escrita de registros com os fluxos pode ser vista na figura abaixo.
[voltar]