Baixe J2ME – Plataforma Java para dispositivos móveis e outras Notas de estudo em PDF para Informática, somente na Docsity!
J2ME – Plataforma Java para dispositivos móveis
Leonardo da Silva Sousa [email protected] Universidade Federal de Mato Grosso Centro Universitário do Araguaia - Instituto de Ciências Exatas e da Terra Rodovia BR-070, Km 5. Barra do Garças - Mato Grosso.
Resumo:
O mercado de dispositivos móveis cresce em uma escala enorme. A consultoria de mercado da ABI Research diz que 2010 será um grande ano para as aplicações móveis e estima que os downloads nas lojas deste tipo de software duplicarão este ano, embora esse ritmo de crescimento deva abrandar a partir de 2013[1]. De acordo com a consultoria, o download de aplicações móveis irá crescer aproximadamente de 145 por cento este ano, alcançando os 5,9 mil milhões de dólares, contra os 2,9 mil milhões registrados em 2009. Com base neste crescente mercado, temos a demando por aplicações que possam ser executadas em dispositivos portáteis, com a possibilidade de comunicação com outras aplicações, utilizando uma rede wireless, essa necessidade motivou o estudo da arquitetura J2ME – JAVA 2 MICRO EDITION.
A arquitetura para dispositivos móveis necessita de um tratamento diferenciado das demais tecnologias, pois estes dispositivos têm uma quantidade limitada de memória, menor poder de processamento, pequenas telas e baixa velocidade de conexão. E como a diversidade de dispositivos é quase ilimitada, a necessidade de ter aplicações portáveis entre os dispositivos, fácil adaptação à crescente inovação e a segurança, por isso a tecnologia Java foi escolhida.
Abstract: The mobile device market grows at an enormous scale. The consulting
market ABI Research says that 2010 will be a great year for mobile applications and estimates that downloads in stores this type of software will double this year, although this rate of growth slows in 2013. According to the consultancy, the download of mobile applications will grow from about 145 percent this year, reaching 5.9 billion dollars against 2.9 billion recorded in 2009. Based on this growing market, we have to requests for applications that can be implemented in portable devices, with the possibility of communicating with other applications using a wireless network, this need has motivated the study of architecture J2ME - Java 2 Micro Edition.
The architecture for mobile devices needs a different treatment from other technologies, because these devices have a limited amount of memory, less processing power, small screens and low speed connection. And as the diversity of devices is
almost unlimited, the need for portable applications between devices, easy adaptation to increasing innovation and security, so the Java technology was chosen.
Palavras-chaves: APIs, CDC, CLDC, Configuração, J2ME, MIDlet, MIDP, Perfil.
1. INTRODUÇÃO
Aplicações voltadas para computadores móveis, como PDA’s, telefones celulares em geral, sistemas embutidos, possuem cada vez maior demanda. Os dispositivos móveis são conhecidos pelo fato de possuírem recursos limitados, apesar de existir uma variedade enorme de dispositivo, a maioria partilham as seguintes características:
Pequenos em tamanho: geralmente os dispositivos possuem tamanhos reduzidos, já que os usuários finais prezam pela mobilidade e conveniência. Por isso as aplicações para estes dispositivos (interfaces gráficas) devem se adequar às pequenas telas a fim de possibilitar o uso, sem ser incômodo ao usuário. Memória limitada: apesar da tecnologia para os dispositivos móveis estarem em grande avanço, uma boa parte desses dispositivos possuem memória limitada, tanto primária (RAM), quando secundária (disco). Essa limitação é um dos fatores que devem ser considerados quando se desenvolve uma aplicação. Poder de processamento limitado: assim como a memória, o poder de processamento desses dispositivos é limitado, por isso o desenvolvimento de aplicação para esse aparelhos seguem uma abordagem diferente daquelas para sistemas desktop. Baixo consumo de energia: a energia que possibilita que esses dispositivos estejam em funcionamento, é a principal preocupação do usuário, pois esses dispositivos precisam poupar o consume de energia, já que possuem um limitado sistema de abastecimento via bateria. Conectividade limitada: muitos desses dispositivos (a maior parte atualmente) possuem conectividade à internet. Alguns possuem baixa largura de banda, alguns nem possuem, enquanto outros usam conexão de rede sem fio.
Além dessas características também temos a robustez, confiabilidade desses dispositivos e a rapidez de inicialização. Todas essas características são fatores que fazem que o desenvolvimento de aplicativos para os dispositivos móveis deva utilizar abordagem que proporcione o melhor aproveitamento de seus recursos.
Com a variedade de dispositivos, veio a necessidade de ter uma linguagem capaz de ser portável entre esses dispositivos. A fim de resolver, ou pelo menos amenizar os problemas caudados pela grande quantidade de fabricantes de dispositivos móveis, diferentes tecnologias e proporcionar aos projetistas um modelo de desenvolvimento padrão, foi criado o J2ME – um ambiente de execução Java que requer menos de um décimo de recursos necessários do sistema Java tradicional [2].
Para garantir a portabilidade e resolver os problemas para qual o J2ME foi desenvolvido, temos que o ambiente do Java Micro Edition oferece diversas opções de máquina virtual, cada uma otimizada para os diferentes tipos de tecnologias que usam o J2ME como ambiente de aplicação. Para suportar essa “personalização” de recursos, o núcleo do J2ME foi dividido em três conceitos:
Configuração : a configuração corresponde ao ambiente de execução básico para o J2ME. A configuração define uma plataforma mínima de execução, ou até mesmo um grupo de dispositivos que possuem semelhanças em relação à memória e poder de processamento. Perfil : o perfil representa aparelhos que possuem funcionalidades semelhantes entre si, ou seja, enquanto uma configuração visa aparelhos que possuem recursos de hardware semelhantes entre si, um perfil é definido para dispositivos que executam tarefas semelhantes. Um perfil adiciona bibliotecas padrões para dispositivos que estejam na mesma família de funcionalidade, como os dispositivos tem várias funcionalidades, é possível que o aparelho tenha vários perfis. Pacotes opcionais : são pacotes de bibliotecas que fornecem classes adicionais aos dispositivos. Em geral esses pacotes diferem de aparelho para aparelho, pois características presentes em alguns dispositivos, não necessariamente são comuns a outros dispositivos. Exemplo de pacotes opcionais são as APIs de Bluetooth.
3. Configuração
A configuração define o básico que qualquer desenvolvedor de uma aplicação para dispositivo móveis possa esperar [3]. Logo a configuração determina um conjunto mínimo da tecnologia Java, a fim de garantir a interoperaridade e portabilidade entre vários recursos dos aparelhos.
Uma configuração define:
O subconjunto das funcionalidades da linguagem de programação Java; A funcionalidade da Máquina Virtual Java (JVM); Bibliotecas do núcleo da plataforma; Características de segurança e comunicação em rede (caso exista acesso à rede).
É possível que o ambiente J2ME seja instalado sobre mais de uma configuração. Essa camada é praticamente irrelevante ao usuário final, porém para o desenvolvedor de perfil é totalmente importante, pois a configuração especifica linguagem, a máquina virtual e o conjunto de APIs que serão implementados sobre uma família de dispositivos.
A configuração foi definida em dois padrões de configuração J2ME: o CLDC (Connected, Limited Device Configuration) e o CDC (Connected Device Configuration) [4].
3.1. CLDC – Connected Limited Device Configuration
A Configuração de Dispositivos de Conexão Limitada (CLDC – Connected Limited Device Configuration) é direcionada a dispositivos considerados de uso pessoal, móvel, operando por baterias, como celulares, organizadores pessoais e outros aparelhos semelhantes, ou seja, a CLDC é focada em dispositivos com restrições de recursos.
Em geral os dispositivos devem possuir de 160 KB a 512 KB de memória não-volátil para a maquina virtual e bibliotecas, e pelo menos 122 KB de memória RAM para a execução da máquina virtual. O processador pode ser de 16 ou 32 bits. A conexão com a rede é limitado.
3.1.1. CLDC – Características removidas
A principal diferença presente na especificação CLDC, é que a KVM não tem suporte a ponto flutuante. Esse suporte foi retirado pelo fato de a maioria dos dispositivos não possuírem suporte em hardware para ponto flutuante e o custo para o suporte em software seria muito elevado [5].
A KVM deve suportar tratamento de exceções. Porém o conjunto de exceções presente é reduzido, logo a capacidade de tratamento de erros é reduzida. Isso se deve por detalhes na recuperação de erros serem muito específicos do dispositivo e o número de classes de erro da especificação completa da linguagem ser muito grande para os dispositivos CLDC [5].
Em relação às características herdadas do ambiente JSE, muitas características foram removidas, as seguintes foram as principais:
Finalização de classe (Object.finalize()); Exceções assíncronas (são as exceções que podem ser lançadas em praticamente qualquer lugar [6]); Algumas classes de erro; Carregadores de classe definidas pelo o usuário; Reflexão (ou introspecção é a capacidade de um programa de investigar fatos sobre si próprios. Por exemplo, um objeto pode "perguntar" a outro quais os métodos que ele possui [7]); Java Native Interface (padrão de programação que permite que a máquina virtual da linguagem Java acesse bibliotecas construídas com o código nativo de um sistema [8]);
Apesar de essa configuração suportar o uso de todas as funcionalidades e bibliotecas da máquina virtual do J2SE; foi reformulada uma nova máquina virtual, denominada CVM (Compact Virtual Machine) [10]. A máquina virtual CVM tem como propósito oferecer as seguintes funcionalidades [10]:
Portabilidade; Execução de classes Java fora da memória Rom; Rápida sincronização; Suporte a interfaces e rotinas de processamento do sistema operacional em tempo real (Real-time operation systems – RTO); Suporte nativo a threads (mapear threads Java diretamente para threads nativos do sistema operacional); Suporte as seguintes características de J2SE: segurança, JNI (Java Native Interface), RMI – RemoteMethodInvocation (classes de acesso remoto), JVMDI (Java Virtual Machine Debugging Interface), weakreferences (não protege o objeto referente do coletor de lixo automático) [11].
3.2.1. CDC – Bibliotecas
Semelhante a CLCD, a CDC não define classe de interface com o usuário, essa especificação fica por conta das bibliotecas de interface com o usuário presente nos perfis desta configuração. A configuração junto com o perfil cria o ambiente J2ME. O desenvolvedor é proibido de acessar estes serviços e configurações.
As classes de interface gráfica do ambiente J2SE, como Abstract Window Toolkit (AWT) e Swing são excluídas da configuração CDC, então se uma aplicação precisa de interface gráfica será necessário adicionar um perfil, que é construído sobre a configuração.
As classes incluídas na CDC vêm dos seguintes pacoes: java.io java.lang java.lang.ref java.lang.math java.net java.security
java.security.cert java.text java.util java.util.jar java.util.zip
CDC também inclui o Framework de Conexão Genérica. Ela requer tipos de conexão adicionais, como suporte para arquivos e datagrama.
4. Perfil
O Perfil é a estrutura necessária para desenvolver aplicações para dispositivos da mesma família, isto é, é a estrutura que adicionara APIs e especificações necessárias para desenvolver aplicações para dispositivos com as mesmas funcionalidades. Enquanto uma configuração define uma base de bibliotecas, perfis definem as bibliotecas que são importantes para construir aplicações efetivas. Estas bibliotecas incluem a interface com o usuário, comunicação em rede e classes de armazenamento.
O perfil está em uma camada acima da configuração. Vários perfis estão sendo desenvolvidos sobre a Java Community Process (JCP), que são agrupados conforme a configuração para a qual será desenvolvido.
Os perfis MIDP (Mobile Information Device Profile) e IMP (Information Module Profile) são especificados para a configuração CLDC e os perfis FP (Foundation Profile), o PP (PersonalProfile) e o PBP (Personal Basis Profile) para a configuração CDC.
O perfil MIDP é o mais utilizado atualmente, pois ele atende os dispositivos que são mais populares hoje em dia, como celulares e PDAs.
O perfil IMP foi desenvolvido para aplicações de dispositivos que utilizam rede, mas não possuem um rico display gráfico, ou com recursos muito limitados (configuração CLDC), como os aparelhos de emergência, medidores de estacionamento, módulos wireless de sistemas de alarme residenciais, dispositivos medidores de indústrias e assim por diante. O IMP é um subconjunto do perfil MIDP versão 1.0 [12].
O Foundation Profile tem dois propósitos. O primeiro seria definir um perfil para dispositivos que possuem suporte a operações de rede, mas não utilizam interface gráfica. E o segundo propósito seria para servir como base de outros perfis com mais funcionalidades, desse modo seria um perfil auxiliar a outro perfil, principalmente no suporte a operações de rede. Este perfil pode ser usado em impressoras de rede, roteadores e gateways [13].
O Personal Profile é utilizado em dispositivos com total suporte a bibliotecas de interface gráfica ou applets, como os PDAs de alto nível, comunicadores e console de jogos. Este perfil utiliza a biblioteca completa de AWT (Java Abstract Window Toolkit) e possui um grande suporte ao desenvolvimento de aplicações baseadas em applets que são os mesmos que rodam em aplicações Desktop convencionais [14].
O Personal Basis Profile é utilizado em dispositivos com recursos reduzidos que necessitam de um framework de interface gráfica mais leve, sem todas as funcionalidades do AWT. Ele possui suporte ao modelo de programação baseado em Xlet (Um Xlet é muito semelhante a um applet Java e é projetado para suportar aplicações para TV Digital como parte da especificação Sun Java TV ), e pode ser
Desde a implementação MIDP, já houve evoluções de tecnologia, para acompanhara a evolução, o MIDP evolui através de versões, as versões até agora são:
MIDP 1.0: Lançado em 2000, o MIDP 1.0 está praticamente em desuso, já que apenas celulares antigos e na maioria monocromáticos ainda suportam. MIDP 2. 0: Lançado em 2002, o MIDP 2.0 aprimorou as capacidades do MIDP 1.0. Adicionou várias características às APIs originais, acrescentando novas APIs de rede, serialização, Bluetooth, APIs para o tratamento de jogos 2D e 3D, conexão segura... MIDP 3. 0: A nova versão, que continua incluindo os pequenos dispositivos móveis, entre as novas funcionalidades temos posibilidade de rodar múltiplas MIDlets ao mesmo tempo, colocar MIDlets em background, permitir intercomunicação entre MIDlets diferentes, novas opções para o tratamento de menus, uma nova API capaz de rodar gráficos 3D melhores, entre outras [^17 ].
Além de adicionar fatores de desenvolvimento, o MIDP define um modelo para a execução e comunicação de aplicações, chamado MIDlet. O MIDlet é a unidade básica de execução do MIDP. O MIDlet interage diretamente com o software de gerenciamento de aplicação (AMS - Application Management Software ) do dispositivo, usando os métodos de criar, iniciar, pausar e destruir o MIDlet.
O MIDlet é uma classe que estende a interface java.microedition.midlet.MIDlet , e implementa alguns métodos – startApp (iniciar), pauseApp (pausar) e destroyApp – que definem o ciclo de vida da aplicação [18].
4.1.2. MIDlet – ciclo de vida
Os MIDlets possuem um ciclo de vida bem definido, podendo estar em um dos três estados, que seguem regras claras de transição a fim de garantir a independência da aplicação e do dispositivo. A vida de um MIDlet começa quando ele é instanciado pelo AMS. Ele inicialmente entra no estado pausado após ser criado com comando new. O AMS chama o construtor público sem argumento do MIDlet. Se uma exceção ocorrer no construtor, o MIDlet é colocado no estado destruído e é descartado imediatamente. Os três estados no qual o MIDlet pode estar são:
Pausado: quando o MIDlet já foi construído, mas ainda não entrou no método startApp() , ou caso tenha sido chamado o método pauseApp() ou notifyPaused(). O método de pausar o MIDlet pode ser chamado automaticamente pelo AMS, por exemplo, quando o dispositivo recebe uma chamada telefônica. Quando pausado o MIDlet deve consumir o mínimo de recursos possível.
Ativo: um MIDlet está no estado ativo quando o método startApp() é chamado. Quando o MIDlet está no estado ativo, ele pode alocar todos os recursos necessários para sua execução. Destruído: um MIDlet é destruído quando ele retorna do método destroyApp () ou notifyDestroyed(). Uma vez que o MIDlet é destruído, ele não pode mais entrar em outro estado. O estado destruído substitui a chamada padrão para System.exit() nas aplicações convencionais. Caso seja chamado o método System.exit() em um MIDlet será gerada uma exceção do tipo java.lang.SecurityException.
Diferentemente de um programa Java típico onde o método main() é executado automaticamente somente uma única vez na vida de um programa, o método startApp() pode ser chamado mais de uma vez durante o ciclo de vida do MIDlet. Então, não se deve colocar códigos de inicialização única no método startApp(). Para isso, deve ser criado um construtor para o MIDlet e as inicializações devem ser feitas nele.
5. Pacotes opcionais
Apesar da configuração e do perfil abranger uma dimensão de diferentes tipos de aplicações, ainda existem certas funcionalidades que não são abordadas pela combinação de ambas, tais bibliotecas que não pertencem a simples categorias ou família de dispositivos, foram organizadas em pacotes, chamados de pacotes opcionais.
Espera-se que os pacotes opcionais sirvam como um guia da evolução dos perfis, visto que bibliotecas são desenvolvidas conforme novas tecnologias vão surgindo. A tendência é que tão logo estas bibliotecas fiquem maduras, com o surgimento de novas versões, elas sejam incorporadas aos perfis.
Um pacote opcional é sempre usado em conjunto com uma configuração ou um perfil. Ele estende o ambiente de execução para apoiar as capacidades do dispositivo, que não são suficientemente universais para serem definidas como parte de um perfil ou que precisem ser compartilhados por perfis diferentes [19].
Considere a Wireless Messaging API (WMA), um conjunto de classes para o envio e recebimento de Short Message Service (SMS). Como o WMA é um pacote opcional, ele pode ser incluído em qualquer dispositivo J2ME com capacidades SMS, e não apenas em um MIDP, por exemplo. Se WMA fizesse parte de um perfil específico, como o MIDP, seu uso seria limitado a esse perfil [19].
É o distribuidor de um ambiente de execução Java (Java Runtime Environment) – e em muitos casos, o fabricante do dispositivo - que controla os pacotes opcionais que
ambiente J2ME) e, além disso, cada dispositivo portátil só suporta uma plataforma particular. Portanto, para maximizar o alcance e as receitas para as suas aplicações, um desenvolvedor precisa decidir cuidadosamente quais plataformas irá considerar. Desde os primeiros computadores portáteis da década de 1980, a popularidade destas plataformas tem aumentado consideravelmente. Podemos citar as seguintes linguagens para desenvolvimento de aplicações móveis além de Java: C (usado em BREW), Objective C, C++, Pascal, Ruby. Entre os concorrentes do J2ME temos o Adobe Flash Lite. Flash Lite é uma plataforma que pode ser usada no lugar do J2ME ou junto com ela. As vantagens da Flash Lite são: O rápido desenvolvimento; Um melhor suporte de portabilidade; Facilidade em converter aplicações desktop em aplicações móveis, e vice-versa. Entres desvantagens podemos citar: fraco desempenho gráfico e pobre manipulação de som [y]. Outro concorrente ao J2ME é o SuperWaba. O SuperWaba também é uma linguagem de programação utilizada para desenvolvimento de aplicações para aparelhos móveis como telefones celulares e aparelhos que comportam sistemas como PalmOS, Windows, Windows Mobile, Windows CE e Symbian OS. O SuperWaba se baseia e estende o Waba. A linguagem do SuperWaba é um versão reduzida da definida em Java. Existe semelhança com o Java, também é usada uma máquina virtual cuja implementação é específica de cada aparelho onde é instalada. Diferentemente do Java, SuperWaba não suporta o modelo de sincronização e, como tal, não pode ser considerada verdadeiramente tecnologia Java. SuperWaba cumpre um papel semelhante à tecnologia J2ME. A diferença fundamental é sua maior integração nativa com os aparelhos moveis e um modelo de API mais pragmático que a API J2ME. Somente podemos compará-lo com o J2ME em termos de sintaxe da linguagem utilizada, pois enquanto o J2ME usa a linguagem Java, o SuperWaba possui uma linguagem de sintaxe similar ao Java, porém não podemos comparar os dois em termos de recursos e portabilidade, pois o SuperWaba roda em dispositivos em que o J2ME não possui máquina virtual, sem considerar que o SuperWaba possui muito mais recursos que o J2ME. Dentre as diversas características, podemos notar o suporte para SQL, leitor de código de barras, protocolo GPS, protocolo HTTP, tratamento de imagens JPEG, PNG, GIF e PNG, e suporte para compressão de dados [21].
7.1. JAVAFX Mobile
JavaFX Mobile é uma plataforma para dispositivos móveis baseado em JavaFX. O JavaFX Mobile permite levar mais recursos ao Java em dispositivos móveis, facilitando a troca de informações e portabilidade de aplicações diversas. A principal característica que o JavaFX agrega ao ambiente J2ME é alto poder de trabalho com multimídia [22].
O JavaFX Mobile é capaz de rodar em vários sistemas operacionais móveis, incluindo a Android, Windows Mobile e sistemas operacionais proprietários em tempo real [23].
8. CONSIDERAÇÕES FINAIS
O ambiente de desenvolvimento J2ME consolidou a tecnologia Java como sendo a principal aposta do mercado. O J2ME mostra que é a tecnologia mais atraente para o desenvolvimento de aplicativos para dispositivos móveis. E isso não é apenas pelas características padrões do ambiente Java: portabilidade, segurança, linguagem poderosa e aplicável, mas também pelo fato do ambiente J2ME ser a escolha de linguagem que mais se ajusta às necessidades dos dispositivos: memória, armazenamento e processamento limitado e grande variedade de dispositivos.
A característica que consolida o J2ME como a plataforma adequada para o uso em dispositivos móveis é dada pelo desenvolvimento estruturado desta linguagem, que oferece suporte a vários dispositivos, bibliotecas padrões e APIs personalizadas, levado ao máximo aproveitamento dos recursos dos dispositivos.
[15] - ORACLE Sun Developer Network. (s.d.). Java ME - Personal Basis Profile. Acesso em 08 de Junho de 2010, disponível em http://java.sun.com/products/personalbasis/index.jsp
[16] - ORACLE Sun Developer Network. (s.d.). Java ME - Mobile Information Device Profile (MIDP). Acesso em 15 de Junho de 2010, disponível em http://java.sun.com/products/midp/
[17] - MIDP 3.0 (Mobile Information Device Profile). (s.d.). Acesso em 17 de Junho de 2010, disponível em Pesquisa de compiladores, linguagens, ambientes, protocolos, etc...: http://pesquompile.wikidot.com/midp
[18] - Wikipedia - The Free Encyclopedia. (s.d.). MIDlet. Acesso em 21 de Junho de 2010, disponível em http://en.wikipedia.org/wiki/MIDlet
[19] - ORACLE Sun Developer Network. (s.d.). Article J2ME Optional Packages. Acesso em 22 de Junho de 2010, disponível em http://developers.sun.com/mobility/midp/articles/optional/
[20] - Wikipedia - The Free Encyclopedia. (s.d.). Adobe Flash Lite. Acesso em 26 de Junho de 2010, disponível em http://en.wikipedia.org/wiki/Adobe_Flash_Lite
[21] - Wikipedia - The Free Encyclopedia. (s.d.). SuperWaba. Acesso em 27 de Junho de 2010, disponível em http://pt.wikipedia.org/wiki/SuperWaba
[22] - Wikipedia - The Free Encyclopedia. (s.d.). JavaFX. Acesso em 27 de Junho de 2010, disponível em http://pt.wikipedia.org/wiki/JavaFX
[23] - Wikipedia - The Free Encyclopedia. (s.d.). JavaFX Mobile. Acesso em 28 de Junho de 2010, disponível em http://en.wikipedia.org/wiki/JavaFX_Mobile
