- Polis Educacional

Transcrição

- Polis Educacional
Mário Luiz C. da Silva
RA 0310008
Ciências da Computação
MERCADO DE APLICAÇÕES
J2ME EM
DISPOSITIVOS CELULARES MÓVEIS
Jaguariúna
Novembro de 2005
2
Mário Luiz C. da Silva
RA 0310008
MERCADO DE APLICAÇÕES
J2ME EM
DISPOSITIVOS CELULARES MÓVEIS
Monografia apresentado à disciplina Trabalho
de Graduação III, do curso de Ciência da
Computação da Faculdade de Jaguariúna, sob
orientação do Prof. Ms. Peter Jandl Jr, como
requisito parcial para conclusão do curso de
graduação.
Jaguariúna
Novembro de 2005
3
Silva, Mário Luiz Carvalho da.
Mercado de aplicações J2ME em dispositivos celulares móveis.
Monografia defendida na FAJ, Jaguariúna em 20 de Novembro de 2005 e avaliada
pela banca examinadora constituída pelos professores :
Prof. Valdomiro Plácido dos Santos
FAJ
Prof. João Hermes Clerici
FAJ
Prof. Ms. Peter Jandl Junior
FAJ - Orientador
4
Dedicatória:
Para minha família: minha esposa e filhos.
Para eles que sempre acreditaram que seria possível e que continuaram me
incentivando mesmo nas horas mais difíceis. A minha esposa pela compreensão,
amizade, amor e cumplicidade por todos estes anos juntos.
Aos meus filhos que em sua alegria de criança me fizeram enxergar que as
melhores coisas de vida podem estar bem pertinho de nós.
5
Agradecimentos
Gostaria de agradecer aos meus amigos Dante Testa e Samuel Marcilio pela
amizade que muito me ajudaram ao longo destes quatro anos de convívio.
Agradeço também ao professor e orientador Peter Jandl Jr pela paciência e carinho
que sempre estiveram presentes em nossos contatos.
Quero agradecer a Deus pela oportunidade de ter tido um homem brilhante em
minha vida que tive a honra de chamar de pai. Foi embasado nos ensinamentos e
referências dados por meu pai que orientei minha. Por sua integridade, fé e amor
infinito,quero agradecer por tudo que me deu.
6
“Pedi, e dar-se-vos-á; buscai, e achareis; batei e abrir-se-vos-á. Porque, todo o que
pede, recebe; e, o que busca, acha.”
(Matheus, VII: 7 – 11)
7
Silva, Mário Luiz Carvalho da.
Mercado de aplicações J2ME em
dispositivos celulares móveis. 2005
Monografia – Bacharelado em Ciências da Computação. Curso de
Ciências da Computação da Faculdade de Jaguariúna – FAJ.
Resumo
Tem-se visto nos últimos anos uma grande quantidade de serviços via internet sendo
disponibilizados
em
equipamentos
portáteis.
Os
telefones
celulares
avançam
vertiginosamente tanto em quantidade quanto em tecnologia. O JAVA J2ME, uma
plataforma aberta da SUN, é uma das ferramentas que permitem aos desenvolvedores e
provedores de serviço migrar para esta nova realidade. A finalidade deste trabalho é
fornecer informações básicas que nos permitam entender de forma abrangente este
mercado em expansão, suas principais características e oportunidades. Para tanto,
norteamos o trabalho estudando quais as possibilidades de aplicação com dispositivos
celulares móveis utilizando a linguagem J2ME, o mercado atual e a introdução básica do
processo de produção comercial de aplicativos. Mostram-se produtos comerciais existentes
atualmente no mercado e suas principais características. Realizou-se um estudo geral da
plataforma SUN J2ME, suas especificações e requisitos e também informações gerais para
entender os requisitos comerciais de desenvolvimento de aplicações e avaliar os possíveis
requerimentos de mercado. A conclusão deste trabalho mostra basicamente um mercado
em expansão com forte demanda de mão-de-obra especializada. Conclui-se que com o
rápido crescimento da capacidade de processamento dos terminais celulares e a
convergência de tecnologias, mostra tendência favorável aos aplicativos em J2ME para
dispositivos móveis nos próximos anos.
PALAVRAS-CHAVE: DISPOSITIVOS CELULARES MÓVEIS, J2ME
8
Índice
Resumo ................................................................................................................................. 7
Lista de Siglas ..................................................................................................................... 10
Lista de Figuras ................................................................................................................... 11
1.0
INTRODUÇÃO ......................................................................................................... 12
2.0
A PLATAFORMA SUN J2ME E SEUS REQUISITOS .............................................. 14
2.1
A arquitetura J2ME............................................................................................... 15
2.2
Configuração do Dispositivo Conectado Limitado – CLDC ................................... 16
2.3
Perfil de Informações do Dispositivo Móvel – MIDP.............................................. 18
2.4
Perfil MIDP 1.0 e MIDP 2.0................................................................................... 19
2.5
Arquivos JAR e JAD ............................................................................................. 21
2.6
A máquina virtual Java ......................................................................................... 22
2.7
Recursos mínimos para desenvolvimento em J2ME ............................................ 23
2.8
Especificações (API’s) : JSR e JCP...................................................................... 24
2.8.1
CLDC JSR 30 (1.0) e JSR 139 (1.1)................................................................... 24
2.8.2
MIDP: JSR 37 (1.0) e JSR 118 (2.0)................................................................... 25
2.8.3
IMP (Information Module Profile): JSR 195........................................................... 25
2.8.4
JTWI (Java Technology for the Wireless Industry) : JSR 185 .............................. 25
2.8.5
WMA (Wireless Messaging API - SMS):JSR 120 e JSR 205 ................................ 26
2.8.6
MMAPI (Mobile Media API): JSR 135................................................................... 26
2.8.7
WSA (J2ME Web Services APIs): JSR 172.......................................................... 26
2.9
MIDlet................................................................................................................... 28
2.9.1
Ciclo de vida de um MIDlet................................................................................... 28
2.9.2
Criação de MIDlet................................................................................................. 29
2.9.3
Recursos para desenvolvimento de um MIDlet..................................................... 31
2.9.4
Kits de desenvolvimento fornecidos por fabricantes ............................................. 33
2.9.5
Transferência de um MIDlet para um dispositivo móvel........................................ 34
2.9.6
Exemplos de MIDlets............................................................................................ 35
3.0
SELEÇÃO DE UM DISPOSITIVO MÓVEL ............................................................... 37
3.1
A tecnologia CDMA .................................................................................................. 37
3.2
A tecnologia GSM .................................................................................................... 38
3.3
Fabricantes de dispositivos móveis : telefones celulares.......................................... 39
4.0
MERCADO ATUAL E TENDÊNCIAS ....................................................................... 41
4.1
Mercado mundial.................................................................................................. 41
4.2
Mercado brasileiro................................................................................................ 44
4.3
Breve comparação entre J2ME e BREW.............................................................. 49
4.3.1
Breve descrição do BREW ................................................................................... 49
9
4.3.2
Desvantagens do J2ME ....................................................................................... 50
4.3.3
J2ME versus BREW ............................................................................................. 51
5.0
CONCLUSÕES ........................................................................................................ 55
6.0
REFERÊNCIAS BIBLIOGRÁFICAS ......................................................................... 57
7.0
ASSINATURAS........................................................................................................ 62
10
Lista de Siglas
API
BREW
CDMA
CLDC
GSM
IDE
J2ME
JAD
JAR
JCP
JVM
KVM
MIDlet
MIDP
SMS
WTK
Programa de Interface do Aplicativo (Application Program Interface)
Binary RunTime Environment Wirelles - Ambiente Binário para dispositivos
sem fio
Acesso Múltiplo com divisão de Código (Code Division Multiple Access)
Configuração do Dispositivo Conectado Limitado (Connected, Limited Device
Configuration)
Global System for Mobile (sem tradução para o Português)
Interface de Desenvolvimeto Integrado (Integrated Development Environment)
Java 2 Micro Edition
Java Application Descriptor (sem tradução direta para o Português) . Definido
como uma aplicação ou conjunto de programas Java que podem ser
recuperados (retrieval system).
Arquivo Java (Java Archive)
Java Community Process (sem tradução para o Português)
Máquina Virtual JAVA ( Java Virtual Machine)
Máquina virtual K (K Virtual Machine)
Mobile Information Device with Java code – Programa em Java para ser
executado em um dispositivo móvel.
Perfil de Informações do Dispositivo Móvel (Mobile Information Device
Profile)
Serviço de Mensagens de texto (Short Message Service)
Wirelles Tool Kit (sem tradução para o Português)
11
Lista de Figuras
Figura 01 – Arquitetura JAVA – foco em J2ME (SUN, 2005 A) ............................................ 14
Figura 02 – Camadas MIDP (SUN, 2005 A)......................................................................... 20
Figura 03 – Ciclo de vida de um MIDlet (SUN, 2005 D) ....................................................... 28
Figura 04 – Passos para a criação de um MIDlet (SUN, 2005 E)......................................... 29
Figura 05 – Portal GETJAR: fonte de MIDlets (GETJAR, 2005 A) ....................................... 35
Figura 06 – Portal GETJAR : selecionando o MIDlet Mobile Mail (GETJAR, 2005 A) .......... 35
Figura 07 – Portal GETJAR: facilidade de download do MIDlet (GETJAR, 2005 A) ............. 36
Figura 08 – Comparação de modelos de dispositivos móveis (GSM, 2005 B) ..................... 40
Figura 09 – Site de venda de jogos em J2ME da empresa GlobalFun (GlobalFun, 2005 A) 41
Figura 10 – Site de anúncio de filme King Kong (Apple, 2005 A) ......................................... 42
Figura 11 – Site de anúncio de filme King Kong (Apple, 2005 A) ......................................... 42
Figura 12 – Site de venda de jogos baseados no filme King Kong (GlobalFun, 2005 A) ...... 43
Figura 13 – Site de empresa Gameloft (Gameloft, 2005 A)................................................. 43
Figura 14 – Distribuição do mercado Brasil – número de assinantes (Teleco, 2005 A) ........ 44
Figura 15 – Cobertura das operadoras de telefonia celular no Brasil (Teleco, 2005 A) ........ 45
Figura 16 – Site de venda de jogos em J2ME da operadora Oi (Oi, 2005 A) ...................... 46
Figura 17 – Site de conteúdo para celular da Samsung . (Samsung, 2005 A)...................... 47
Figura 18 – Site de venda de jogos em BREW da operadora VIVO (Vivo, 2005 A) ........... 47
Figura 19 – Site da empresa COMPERA – Campinas – SP (Compera, 2005 A).................. 48
Figura 20 – Quadro de processadores QUALCOMM por tecnologia (plusd_IT, 2005 A)...... 52
Figura 21 – Projeção de dispositivos móveis com Java até 2007 (Zelos Group, 2005 A)..... 53
Figura 22 – Tabela de comparação entre algumas das características do J2ME e BREW .. 54
12
1.0
INTRODUÇÃO
O mercado de telefonia celular está em um processo de expansão explosivo. Existe
uma demanda não atendida de informações úteis que possam orientar investimentos na
área e fomentar o crescimento e desenvolvimento comercial de forma sustentada. Neste
contexto, observa-se uma grande carência de estudos e projetos de desenvolvimento de
aplicativos voltados para este mercado.
Pode-se citar como exemplo o fato de que ao longo dos últimos cinco anos,
passamos (no Brasil) do uso de uma tecnologia analógica de transmissão de voz (sistema
E-AMPS - Extended Advanced Mobile Phone System ) até o mais sofisticado sistema
digital da atualidade (CDMA 1X- RTT - Code Division Multiple Access ). Neste mesmo
período, os telefones celulares saíram de modelos pesados (acima de 300 gramas), com
displays de sete segmentos (matriz de LEDs) e memória limitadíssima (8K bytes) para as
atuais unidades digitais com display de até 256.000 cores, anti-reflexivo, com peso nunca
superior a 150 gramas e com capacidade de memória na casa dos 10M bytes. (Teleco, 2005
A)
Esta capacidade de evolução facilita de forma fantástica a convergência de
tecnologias, tendo como base para o usuário comum um simples telefone de bolso. Pode-se
ilustrar este ponto usando mais uma vez a comparação com o que existe hoje em uso e o
que havia a apenas cinco anos no passado: com os telefones de tecnologia analógica, a
transmissão de dados era primitiva, extremamente cara e não confiável. Os aplicativos eram
proprietários das empresas fabricantes e não havia um padrão bem definido para o
mercado. Com os atuais telefones celulares, podemos chegar a taxas de transferência de
dados na casa dos 70Kbps, de forma confiável e segura, tendo como gerenciadores deste
processo programas desenvolvidos em plataformas abertas.
Outro ponto importante que deve-se citar são as unidades recém chegadas ao
mercado brasileiro (últimos 10 meses) que apresentam funcionalidades de PDA (assistente
pessoal). Estas unidades foram concebidas para realizar a conexão com programas
considerados “pesados” para um celular (tais como gerenciadores de arquivos e programas
de e-mail) e tem um apelo que as torna cada vez mais atraentes: mobilidade. Também estes
dispositivos utilizam programas desenvolvidos em plataformas abertas. Podemos citar o
SUN J2ME e o Qualcomm BREW.
Do ponto de vista do desenvolvedor, J2ME apresenta uma série de vantagens
quando comparado ao BREW, tais como: código aberto da plataforma J2ME, possibilitando
a qualquer programador ter acesso a documentos e programas ligados ao desenvolvimento
13
em Java J2ME. O BREW, plataforma que é propriedade da empresa Qualcomm, exige
licença para uso e aprovação específica da Qualcomm. Programas desenvolvidos em J2ME
podem ser aplicados praticamente a todos os telefones celulares móveis do mercado.
Programas em BREW rodam de forma mais adequada em telefones celulares CDMA
com chip set (componentes que processam a informação / códigos) Qualcomm ou baseados
nestes. Estes fatores limitam bastante o desenvolvimento de aplicativos nesta plataforma.
Outro ponto importante é que as unidades de tecnologia GSM dominam o mercado mundial
de telefones celulares, tendo passado da casa de 1 bilhão de terminais. Já as unidades de
tecnologia CDMA encontram-se ainda em expansão e detém um mercado de
aproximadamente 250 milhões de usuários. (CDG, 2005 A)
A diversidade de produtos atualmente no mercado (telefones celulares) e a rápida
convergência
de
tecnologias,
mostra
que o
desafio
de
desenvolver
aplicativos
comercialmente viáveis não é simples.
Tendo em vista o crescimento constante do mercado de telefonia celular em todo o
mundo, muitas das operadoras existentes realizaram acordos internacionais de atendimento
a seus clientes, permitindo que seus clientes possam viajar por onde quiserem e serem
localizados por seus celulares como se estivessem localmente disponíveis.
É previsto que este mercado, exatamente devido a esta tendência de convergência
tecnológica, continue crescendo e tornando-se ainda mais competitivo nos próximos anos.
De forma geral, existe uma corrida de conhecimento nesta área, com quantidade crescente
de material disponível para pesquisa e enormes possibilidades de uso.
Mais do que isso, o entendimento das potencialidades dos mercados brasileiro e
mundial torna-se de vital importância para o adequado alinhamento no desenvolvimento de
aplicativos comercialmente viáveis para dispositivos móveis.
Existe uma grande perspectiva de uso em larga escala de dispositivos móveis
utilizando a plataforma SUN J2ME (Muchow, 2002). O custo do desenvolvimento e a
flexibilidade desta plataforma, faz com que projetos de desenvolvimento de aplicativos e
jogos sejam extremamente atraentes aos olhos de operadoras de telefonia celular e
mercados emergentes ao redor desta indústria.
Tendo este enorme potencial para as unidades de tecnologia GSM, vemos que o
desenvolvimento de aplicativos e jogos deve tomar um aspecto profissional para ganhar
mercado e garantir um vínculo com os distribuidores ou compradores diretos (Wells, 2004).
14
2.0
A PLATAFORMA SUN J2ME E SEUS REQUISITOS
A plataforma J2ME foi criada especialmente para desenvolvimento de aplicações
Java em dispositivos limitados. Entende-se como dispositivo limitado qualquer equipamento
com restrições técnicas a tal nível que seria impossível implementar diretamente qualquer
aplicativo em linguagem JAVA. Podemos citar como exemplo de dispositivos limitados os
equipamentos de recepção de TV a cabo, pequenos equipamentos de segurança, pagers,
PDA’s e telefones celulares. Vamos manter o foco deste trabalho exclusivamente nos
telefones celulares. Existem características que definem tecnicamente um dispositivo
limitado tais como tamanho de display, quantidade de memória, capacidade de
processamento, etc. Na figura 1 pode-se ver as diversas possibilidades de uso do Java. O
foco deste trabalho encontra-se exclusivamente a segunda coluna: Java voltado para
telefones celulares (mobile phones). (SUN, 2005 A)
Figura 01 – Arquitetura JAVA – foco em J2ME (SUN, 2005 A)
15
2.1
A arquitetura J2ME
Quando o J2ME foi comercialmente anunciado em 1999 na JavaOne Conference da
SUN (SUN, 2005 H), os telefones celulares eram dispositivos extremamente limitados, com
telas (display) muito reduzidos e memória disponível irrelevante. Passados seis anos, a
evolução dos terminais celulares tornou possível o desenvolvimento de uma vasta gama de
aplicativos em J2ME, agora rodando em hardware com tela colorida, muita capacidade de
memória e poder de processamento consideravelmente superior.
A plataforma J2ME permite aos dispositivos móveis ter acesso a toda a tecnologia
Java e seus benefícios, incluindo uma flexível interface com o usuário, dispositivos de
segurança e protocolos de comunicação em rede.
O J2ME é dividido basicamente em três partes: configurações, perfis e API.
(Wells, 2004).
A arquitetura J2ME define configurações, perfis e pacotes adicionais como
elementos para desenvolvimento em ambiente Java para atender aos requerimentos de
mercado e aos requerimentos dos dispositivos móveis. (SUN, 2005 A).
Uma configuração é composta de uma máquina virtual Java e uma quantidade
mínima de bibliotecas de classes Java. Este conjunto proporciona o funcionamento básico
para um grupo particular de dispositivos que partilham de características similares (memória,
processamento de dados, etc).
Os perfis (ou profiles) são mais específicos que as configurações, ou seja, os perfis
tratam de uma série limitada de equipamentos com mesmo comportamento e especificação.
Existem dois tipos de configurações: o CLDC (Connected, Limited Device
Configuration), que rege as configurações para aparelhos como celulares e o CDC
(Connected Device Configuration) que trata das configurações para aparelhos um pouco
maiores e nem sempre móveis.
Temos como exemplo equipamentos de recepção de TV, Neste trabalho estaremos
tratando exclusivamente da configuração CLDC. Os perfis são tratados como MIDP: Perfil
de Informações do Dispositivo Móvel (Mobile Information Device Profile). (Wells, 2004)
16
2.2
Configuração do Dispositivo Conectado Limitado – CLDC
Uma configuração define uma plataforma JAVA para uma ampla variedade de
dispositivos. Esta configuração está ligada a máquina virtual Java disponível. Logo, uma
configuração define os recursos da linguagem Java e as bibliotecas básicas Java da JVM
para essa configuração. O CLDC define um conjunto de classes Java.
O CLDC 1.0 é um padrão definido e mantido pelas mais renomadas e influentes
industrias de terminais móveis, tais como: Motorola, Nokia, Samsung, etc (SUN, 2005 A).
O CLDC define os recursos da plataforma Java para uso em dispositivos que tenham
características similares. Como os dispositivos móveis são limitados, o CLDC minimiza a
plataforma
Java
J2SE
removendo
os
seguintes
componentes:
Java
language,
requerimentos de hardware e bibliotecas Java.
O CLDC é usado como referência por fabricantes para implementar o ambiente Java
em seus dispositivos celulares móveis. Baseados neste processo, outras empresas podem
desenvolver programas que rodam em dispositivos móveis com total compatibilidade, uma
vez que foram referenciados no mesmo padrão. (Wells, 2004)
O CLDC afeta de forma direta muitos dos aspectos de desenvolvimento de
aplicativos J2ME. Podemos citar alguns:
•
Características do dispositivo
•
Modelo de Segurança
•
Gerenciamento de aplicativos
•
Diferenças de linguagem
•
Diferenças da máquina virtual Java
•
Biblioteca de classes
O primeiro aspecto do CLDC é a definição das características que o dispositivo
móvel a ser suportado deve possuir. Podemos citar: memória (capacidade), tipo de
processador,
conectividade
e
consumo
(alimentação).
Este
conjunto
define
as
características do dispositivo . (Wells, 2004)
Quando o J2ME foi concebido, ficou claro que as características de segurança
pertencentes ao J2SE eram extremamente grandes para serem suportadas pelo CLDC.
Portanto um modelo revisado e com um número muito menor de recursos foi desenvolvido
para ser usado no CLDC. Existem basicamente duas partes que cobrem o modelo de
segurança do CLDC: segurança da máquina virtual (KVM) e segurança da aplicação. O
primeiro tem como função básica proteger o dispositivo de qualquer código executável que
possa causar danos. O segundo basicamente valida que os bytecodes são resultado
legítimo do processo de compilação Java. (Wells, 2004)
17
Quando falamos de gerenciamento de aplicativos em dispositivos móveis, existe uma
enorme diferença se comparado ao gerenciamento em um computador convencional.
Frequentemente não existe o conceito de “file system” e é comum o dispositivo não
armazenar classes permanentemente, pois as mesmas são deletadas após o término da
execução do aplicativo. Devido as características limitadas do dispositivo, os recursos
destinados aos aplicativos são pequenos e devem ser otimizados. Para gerenciar estes
aplicativos o dispositivo deve prover um ciclo de busca do aplicativo, execução e logo após
deletá-lo.Normalmente é usado apenas um simples menu como ferramenta para gerenciar a
execução dos aplicativos. (Wells, 2004)
Quando tratamos de diferenças de linguagem, existem basicamente três pontos
importantes no CLDC: ponto flutuante, finalização e erros de pacote. Para J2ME não estão
disponíveis os recursos de suporte a ponto flutuante. Deve-se a isto o fato de não existir
suporte de hardware para execução desta tarefa. Levando em consideração que para
emular o suporte a ponto flutuante via software exigiria demasiado consumo do
processador, outras técnicas (classes) foram implementadas no CLDC para suprir este
ponto. Ainda tratando do reduzido poder de processamento dos dispositivos móveis, o
método de finalização não existe no CLDC. Isto significa aumento de performance e redução
de requerimentos especiais para a chamada do método de finalização. (Wells, 2004)
Também devido aos recursos limitados, O CLDC não inclui nenhuma classe para
tratamento de erros de pacote.
A implementação de referência do CLDC incorpora uma máquina virtual revisada
chamada de KVM. Como podemos imaginar, esta versão reduzida de uma máquina virtual
Java possui algumas limitações. Seguem algumas das bibliotecas de classe não coberta
pela KVM:
•
Referências Fracas
•
Reflexão
•
Thread de grupo
•
JNI – Java Native Interface
O CLDC definiu uma extensa biblioteca de classes para o J2ME. Para acomodar estas
classes nas condições do dispositivo limitado, foram criados duas categorias de bibliotecas
no CLDC: classes como sub-classes do J2SE e classes específicas do CLDC. Estas classes
são diferenciadas pelo prefixo. Assim, sub-classes do J2SE mantém os nomes das classes
de origem (exemplo: java.lang.String) enquanto que classes específicas do CLDC tem o
sufixo mudado para (javax.*.). (Wells, 2004)
18
2.3
Perfil de Informações do Dispositivo Móvel – MIDP
Os dispositivos limitados podem ser classificados em alguns tipos diferentes. Porém,
quando começamos a verificar os dispositivos quanto aos seus recursos, encontramos uma
vasta e variada disponibilidade de tipos. Para tornar a programação mais flexível, a SUN
adotou o conceito de perfil: Perfil de Informações do Dispositivo Móvel. Um perfil pode ser
entendido como uma complementação da configuração. O MIDP fornece as bibliotecas para
que um desenvolvedor possa criar aplicativos para um dispositivo limitado. Portanto, o MIDP
atua como complemento do CLDC, sendo o MIDP específico para o perfil do dispositivo
móvel.
No caso dos telefones celulares, o MIDP irá atuar fortemente no display (uso do
display), cores, interface do usuário (UI – User Interface), persistência de dados e também
interfaces de relacionamento com conexão de rede sem fio e acesso a WAP – Wirelles
Application Protocol.
As especificações MIDP formam a base de funcionamento dos perfis dos dispositivos
móveis. Podemos dividir em dois grupos distintos os ambientes alvo do MIDP:
•
Hardware: trata do hardware tal como display, teclado, memória, etc. Logo, é através do
MIDP que é especificado o hardware mínimo para funcionamento.
•
Software: assim como no ambiente de hardware, existe uma conjunto de software
mínimo para para que o dispositivo mantenha seu perfeito funcionamento. Podemos citar
o acesso (endereçamento) de memória, comunicação a API, conjunto de controles do
display, controle e leitura dos mecanismos de I/O e operação básica do Kernel.
O MIDP permite o uso dos dispositivos móveis para conexão em rede e posterior uso
de download de aplicações MIDP. Basta selecionar o aplicativo de uma lista disponível em
um servidor (na maior parte das vezes, um servidor da operadora).
A interface gráfica é otimizada pelo MIDP para máximo aproveitamento do hardware
do dispositivo móvel (display). Seguindo nesta linha, o MIDP proporciona uma navegação
intuitiva através do teclado, botões extras , tecla multiderecional ou até mesmo display
sensível ao toque (touch screen). O MIDP fica instalado no dispositivo móvel e pode
funcionar tanto conectado a rede (via operadora) quanto remotamente (stand alone). O
MIDP possui uma interface API de alto nível que permite o desenvolvimento de interfaces
gráficas de fácil uso e entendimento para o usuário. É possível incluir funcionalidade na
interface gráfica tais como telas pré-definidas, listas, janelas de diálogo, etc. O MIDP possui
também suporte para jogos (games) e aplicações multimídia, incluindo som e imagem.
(SUN, 2005 B).
19
2.4
Perfil MIDP 1.0 e MIDP 2.0
Existem atualmente duas versões de MIDP: 1.0 e a nova 2.0. Basicamente, a versão
2.0 fornece suporte e melhorias para o desenvolvimento de jogos, além de agregar novas
bibliotecas de classes. (SUN, 2005 B).
Estaremos tratando especificamente da versão 2.0, uma vez que esta engloba além
das funcionalidades da versão 1.0 as novas bibliotecas de classe para jogos e aplicações
multimídia. Dentre as principais vantagens que a versão 2.0 contempla, podemos citar:
(Muchow, 2002):
•
Suporte a acesso direto HTTPS
•
Dados enviados via rede da operadora podem “ativar” MIDlets
•
Reconhecimento de tons polifônicos (MIDI) e no formato WAV
•
Novos controles para incremento da interface com o usuário
•
Jogos: suporte a gráfico em camadas, CANVAS, imagens transparentes, etc
•
Biblioteca de classes exclusivas para jogos
A versão 2.0 não elimina a versão anterior. Muitos dispositivos móveis no mercado não
são compatíveis com a versão 2.0 e portanto permanecem com a versão anterior em uso.
Portanto, a versão 2.0 não pode ser entendida como uma atualização da anterior.
Exemplos de métodos disponíveis no MIDP2.0: (Muchow, 2002)
•
Método vibrate() que comanda o vibracall dos telefones celulares
•
Método flashBachLight() que comando o bachlight (luz de fundo do display e teclado)
•
Suporte a imagens transparentes
Somente como exemplo, citamos aqui alguns dos packages disponíveis no MIDP
2.0:
· javax.microedition.lcdui.game
· javax.microedition.media
· javax.microedition.media.control
· javax.microedition.midlet
20
Opcionalmente, fabricantes podem fornecer API's JAVA para acesso a partes
específicas de cada aparelho.
Figura 02 – Camadas MIDP (SUN, 2005 A)
21
2.5
Arquivos JAR e JAD
Normalmente um aplicativo é constituído de vários pacotes de programas, ou seja,
diversos arquivos. Além das classes Java poderão existir outros tipos de arquivos, tais como
figuras e arquivos de áudio e vídeo. Um arquivo JAR empacota todo este conteúdo
(SUN, 2005 C).
Um arquivo JAD fornece informações para o gerenciador de aplicativos sobre o
conteúdo de um arquivo JAR. Com estas informações será possível ao gerenciador tomar
decisões tais como qual MIDlet deve ser executado.
Nem sempre um arquivo JAD deve obrigatoriamente existir em um conjunto de
MIDlets. Os arquivos JAD tem como objetivo fornecer informações ao gerenciador de
aplicativos. Estas informações dizem respeito ao conteúdo do arquivos JAR. Assim, é
através da leitura do arquivo JAD que o gerenciador pode tomar decisões que evitem
problemas e falhas. Um bom exemplo diz respeito ao tamanho dos arquivos. Caso o
tamanho do arquivo seja grande demais para rodar em um dispositivo, é através do arquivo
JAD que o gerenciador pode evitar o erro e recusar o carregamento do MIDlet
(Wells, 2004).
22
2.6
A máquina virtual Java
Para que seja possível executar qualquer aplicativo JAVA é necessário uma JVM:
Máquina Virtual Java. No caso dos dispositivos limitados existe a necessidade de uma
máquina JAVA especial: a KVM. A KVM foi desenvolvida pela SUN para uso nos
dispositivos limitados, levando em consideração suas características especiais. A KVM
atende aos requisitos da CLDC para o caso dos telefones celulares (Muchow, 2002).
Seguem algumas das limitações da KVM:
•
Não possui métodos nativos;
•
O verificador de bytecode é limitado;
•
Não suporta ponto flutuante, ou seja, não suporta float ou double;
23
2.7
Recursos mínimos para desenvolvimento em J2ME
Para que seja possível executar programas em J2ME, existem requisitos mínimos de
hardware e software. São eles:
Hardware: podemos considerar que existem no mercado muitos tipos de celulares com as
mais diversas configurações de hardware. Contudo, existem requisitos mínimos tais como:
- Memória disponível para execução da KVM e classes da CLDC : mínimo de 128 kilobytes.
Esta memória deve ser do tipo não volátil, ou seja, aquelas que mantêm o conteúdo
armazenado mesmo se o telefone for desligado.
- Memória disponível para execução do aplicativo: mínimo de 32 kilobytes.
Esta memória pode ser volátil. Chamamos esta memória de heap.
Software: o sistema operacional local deve ser capaz de executar a KVM, selecionar e ativar
os aplicativos assim como ter a capacidade de remover aplicativos quando requisitado
(Muchow,2002).
24
2.8
Especificações (API’s) : JSR e JCP
API significa Application Programming Interface ou Programa de Interface do
Aplicativo. Trata-se da interface que um sistema computatorizado ou uma aplicação
fornecem a fim de permitir que as requisições de serviço sejam feitas dela por outros
programas de computador, permitindo que os dados sejam trocados entre eles. Muitos tipos
de sistemas computadorizados e aplicações implementam API's, tais como sistemas
gráficos, bases de dados, redes, serviços de internete e mesmo alguns jogos para
computador.
Estaremos tratando exclusivamente das API’s voltadas para J2ME. A J2ME API é
formada por uma coleção de classes Java que cobrem uma vasta faixa de funcionalidades
tais como gerenciamento de dados, IO, segurança, etc. Existem muitas classes disponíveis
para J2ME..
As especificações mais importantes são definidas como JSR : Java Specification
Request ou Requisições de Especificação Java.
Estas especificações são definidas pelo JCP – Java Community Process . A JCP é o
caminho formal que permite a diversas empresas, grupos, estudantes , desenvolvedores e
etc a estarem envolvidos na definição de futuras versões e funcionalidades da plataforma
J2ME. A JCP usa as JSR’s como documentos formais que descrevem as especificações
propostas e as mais diversas tecnologias a serem agregadas a plataforma Java.
Uma JSR é uma referência de implementação que fornece execução livre de
tecnologia em forma de código fonte e compatibilidade de tecnologia para verificar a
especificação da API. (JCP, 2005 A).
Seguem algumas das especificações mais importantes definida na JSR.
2.8.1 CLDC JSR 30 (1.0) e JSR 139 (1.1)
A configuração de dispositivo limitada conectada (CLDC) define a base das
interfaces dos aplicativos e de uma máquina virtual para dispositivos limitados como
telefones celulares. Quando acoplada com um perfil tal como o perfil móvel do dispositivo
de informação (MIDP), fornece uma sólida plataforma Java para desenvolvimento de
aplicações para funcionamento em dispositivos limitados. Empresas como Bull, Ericsson,
Mitsubishi, Motorola, Nokia NTT DoCoMO e Siemens reconhecem e coloboram com esta
JSR. (JCP, 2005, B).
25
2.8.2 MIDP: JSR 37 (1.0) e JSR 118 (2.0)
O MIDP é o elemento chave para o J2ME. Quando somado ao CLDC, o MIDP
proporciona o desenvolvimento de aplicativos padrão em Java J2ME. As especificações do
MIDP foram definidas pela JCP que é formada por um grupo de mais de 50 empresas
incluindo líderes de mercado na fabricação de celulares.
Este perfil (MIDP) permitirá o desenvolvimento de aplicações para dispositivos
celulares móveis. Além de estarem conectado a uma rede de comunicação sem fio, estes
dispositivos têm recursos limitados de display, bateria, memória e poder de processamento.
Este perfil, conjuntamente com o JSR 30, permitirá o desenvolvimento de aplicações nestes
dispositivos satisfazendo a demanda do mercado consumidor para o acesso wireless de
forma simples e fácil através do teclado do dispositivo móvel. Informação, serviços e
entretenimento (como por exemplo: esporte, informação financeira, e-commerce, jogos, etc).
Sempre que possível este perfil utilizará toda a funcionalidade fornecida pelo JSR 30. APIs
que deverão ser criadas devem incluir para cada produto: kit para desenvolvimento usando
displays limitados (tamanho e capacidade), métodos de entrada do usuário tais como o
teclado, armazenamento persistente de dados para aplicações, messaging (por exemplo,
SMS, E-mail, etc). (JCP, 2005 C)
2.8.3 IMP (Information Module Profile): JSR 195
Somada ao CLDC, o IMP proporciona desenvolvimento e suporte a aplicações Java
que possuem recursos limitados de capacidade gráfica. A especificação do IMP é baseada
no MIDP. O perfil IMP é uma parte do MIDP 1.0, onde a API relativa a funcionalidade do
display fica restrita ou inativa. (JCP, 2005 D)
2.8.4 JTWI (Java Technology for the Wireless Industry) : JSR 185
O JTWI define a plataforma padrão para a próxima geração de telefones celulares.
Esta JSR representa uma coleção de documentos os quais devem ser periodicamente
revisados e mantidos, contendo RI (referência de implementação) e TCK (kit de teste de
compatibilidade). Podemos citar como exemplo
o JWAS – Java Wireless Architecture
Specification: visão geral de arquitetura que descreve os componentes essenciais de
dispositivos sem fio. Este documento descreve combinações de tecnologias usando J2ME.
Ele é um guia para uso mais adequado das várias tecnologias Java que deveriam ser
usadas em ambientes de dispositivos sem fio. Outro documento que pode ser citado é o
26
JWAR – Java Wireless Architeture Roadmap. Este documento o roadmap corrente (tal qual
um catálogo) de tecnologias. Ele é uma versão particular do JWAS como a especificação
corrente que define a direção tecnológica e os planos a serem seguidos em uma próxima
revisão. (JCP, 2005 E)
2.8.5 WMA (Wireless Messaging API - SMS):JSR 120 e JSR 205
O WMA é um pacote opcional para J2ME que proporciona acesso a plataformas
independentes de recursos tais como plataformas de SMS – Serviços de Mensagens de
texto. O propósito desta JSR é definir um conjunto de APIs que proporcionem acesso
padronizado aos recursos de comunicação sem fio (wireless). Isto irá permitir a
desenvolvedores criarem conexões inteligentes de aplicativos Java. O WMA foi desenhado
para suportar configurações J2ME e seus perfis de funcionalidade única.
A intenção deste JSR é oferecer um conjunto de componentes que possam ser
reusados com qualquer combinação de perfis J2ME.
As seguintes tecnologias são endereçadas neste documento: SMS (Short message
Service) que inclui a API para envio e recebimento de mensagens de texto, USSD
(Unstructured Supplementary Service Data), CBS (Cell Broadcast Service).
(JCP, 2005 F)
2.8.6 MMAPI (Mobile Media API): JSR 135
O MMAPI proporciona uso e suporte de áudio, vídeo e recursos temporizados de
multimídia. Esta API multimídia especifica uma interface de alto nível para áudio e
capacidade multimídia para dispositivos rodando (executando) J2ME. A intenção é permitir
funcionalidades muito versáteis de multimídia para aplicações J2ME. A especificação
encaminha a escalabilidade da API multimídia para vários dispositivos. (JCP, 2005 G)
2.8.7 WSA (J2ME Web Services APIs): JSR 172
O WSA proporciona a utilização da plataforma de web services também para J2ME.
Existe um grande interesse e uma enorme atividade na comunidade Java para uso de
serviços padrão da web e também interesse em infra-estrutura que suporte modelos de
programação para as próximas gerações de negócios e serviços. Existe um considerável
interesse na comunidade de desenvolvedores em proporcionar negócios e serviços a
27
clientes J2ME. Esta JSR foi desenhada para suportar pacotes de J2ME para:
processamento XML básico, permitir reuso e conceitos de serviços web quando
clientes J2ME forem direcionados para negócios e serviços web, providenciar APIs
para desenvolvimento de aplicações J2ME a clientes de negócios e serviços web,
permitir interação entre clientes J2ME e serviços web, (JCP, 2005 H)
Outras API’s importantes (JCP, 2005 A):
•
Bluetooth API : JSR 82 (Motorola, Java Partner )
•
Location API for J2ME; JSR 179
•
Mobile 3D Graphics; JSR-184
•
CHAPI (J2ME Content Handler API ) : JSR 211
28
2.9
MIDlet
Um MIDlet é um programa em J2ME criado para rodar em dispositivos que possuam
uma máquina virtual (KVM). Podem ser aplicativos tais como jogos, agendas, etc. Estes
aplicativos podem rodar em qualquer dispositivo que use J2ME. (SUN, 2005 D)
Estaremos tratando de MIDlets para telephones celulares. Para que funcionem,
deveremos ter obrigatoriamente os seguintes requerimentos:
•
A classe principal deve ser uma classe de javax.microedition.midlet.MIDlet
•
O MIDlet deve possuir um arquivo JAR (.jar)
•
O arquivo JAR precisa ser pré-verificado (verificação dos bytecodes pela KVM antes de
rodar qualquer arquivo de classe. Esta verificação valida a estrutura das classes)
2.9.1 Ciclo de vida de um MIDlet
O Aplication Manager (AM) de cada dispositivo é quem vai controlar os aplicativos
a serem instalados, onde e como serão armazenados e como serão executados. As
classes de cada aplicativo estão em um arquivo JAR, o qual vem acompanhado de um
descritor JAD, que terá todas as informações necessárias.
Assim que a MIDlet é invocada, o AM chama o método startApp(), o qual coloca a
MIDlet no estado Active. Enquanto ela estiver executando o AM pode pausar ela
invocando o método pauseApp() no caso de uma chamada sendo recebida, ou SMS
chegando. A aplicação pode pausar a si mesma, bastando invocar notifyPaused().
Assim como a AM pode pausar a aplicação e esta a si mesma.
DestroyApp() que é invocado pela AM para fechar a aplicação ou até mesmo pode ser
fechada através da própria aplicação invocando o notifyDestroyed().
Figura 03 – Ciclo de vida de um MIDlet (SUN, 2005 D)
29
2.9.2 Criação de MIDlet
Existem basicamente sete passos para a criação de um MIDlet: projetar (design),
codificar (code), compilar (compile), pré-verificação (preverify), empacotamento (package),
teste (test) e distribuição (deploy). (SUN, 2005 D)
De forma geral, nem todos os passos são exclusividade de um MIDlet. Projetar,
codificar e compilar são passos comuns de qualquer aplicação.
O uso do JDK facilita bastante o processo pois permite que vários destes passos
estejam “embutidos” no processamento do kit.
Figura 04 – Passos para a criação de um MIDlet (SUN, 2005 E)
Passo 1: Design
MIDlets são diferentes de outra aplicações pois são criadas para dispositivos
especiais. Em muitos casos não se faz necessário a interação com o usuário. Por exemplo,
uma MIDlet que exibe data e hora correntes não precisa nenhuma interação com o usuário
após ter sido executada. Em casos como o deste exemplo podemos simplesmente criar a
aplicação mas é recomendável que em casos onde sejam necessárias várias telas (display)
que um trabalho mais elaborado com desenhos e especificações de tamanho sejam levados
em consideração.
Passo 2: Code
Cada MIDlet deve chamar o pacote javax.microedition.midlet , assim também como
deve crier um applet com a classe java.applet.Applet class.
Um exemplo de classe (DateTimeApp class) encontra-se no ANEXO 1.
Passo 3: Compile
Com o simples código do anexo 1 podemos realizar o próximo passo: compiler.
Compilar MIDlets não é diferente do processo usado em código Java convencional. Será
30
necessário usar o compilador
javac , contudo existe a necessidade de um classpath
específico para MIDlets. Será necessário apontar para as classes CLDC e MIDP.
Passo 4: Preverify
Antes de validar o MIDlet é necessário realizar a pré-verificação. A verificação dos
byte codes é um passo executado pela KVM antes de rodar qualquer arquivo de classe.
Esta etapa é necessária para validar a estrutura das classes.
Passo 5: Package
Empacotar o MIDlet significa deixá-lo pronto para testar. São necessaries alguns
passos extras para isto. O primeiro deles é criar o arquivo de manifesto. Este arquivo
descreve o conteúdo do arquivo JAR.
Exemplo:
MIDlet-Name: DateTimeApp
MIDlet-Version: 1.0.0
MIDlet-Vendor: Vikram Goyal
Usando o JDK é possível criar este arquivo facilmente. O próximo passo é a criação do
arquivo JAR. Podemos então criar o arquivo JAD.
Exemplo:
MIDlet-1: DateTimeApp, , com.j2me.part1.DateTimeApp
MIDlet-Name: DateTimeApp
MIDlet-Version: 1.0.0
MIDlet-Vendor: Vikram Goyal
MIDlet-Jar-URL: DateTimeApp.jar
MIDlet-Jar-Size:
MicroEdition-Profile: MIDP-2.0
MicroEdition-Configuration: CLDC-1.1
Passo 6: Test
Antes de distribuir o MIDlet, chegou a hora do teste. Para isso é necessário o uso de
um emulador de dispositivo que irá similar um telephone cellular. Mais uma vez recorremos
ao JDK para este trabalho.
Passo 7: Deploy
Está pronto. A partir deste passo o MIDlet pode ser inserido em um telefone celular
compatível.
31
2.9.3 Recursos para desenvolvimento de um MIDlet
O desenvolvimento de uma aplicação passa, como vimos, por basicamente sete
passos. Existem alguns recursos fundamentais a serem verificados antes de iniciar os
trabalhos em J2ME (Wells, 2004). O primeiro deles diz respeito aos programas necessários.
Basicamente, são eles:
•
J2SDK – Java Development Tool Kit – J2SE SDK
•
MIDP – Mobile Information Device Profile
•
CLDC – Connected, Limited Device Configuration
Uma das vantagens do uso de Java é o fato de ser possível escrever as linhas de
código diretamente em um simples editor de texto. Para o J2ME teremos igual facilidade.
Porém, existem hoje disponíveis ótimas ferramentas de desenvolvimento que passaremos a
citar agora.
Wirelles Tool Kit
Esta ferramenta desenvolvida pela SUN é um ótimo recurso para desenvolver e até
mesmo gerenciar projetos usando J2ME (SUN, 2005 F).
Apesar de ser possível a criação de aplicações usando J2ME sem nenhum IDE
(usando apenas um simples editor de texto), o uso de uma ferramenta como a Wireless Tool
Kit facilita em muitos aspectos a criação de um aplicativo.
É importante frisar que o WTK não é um IDE, pois não permite a edição do código
fonte dos aplicativos. Logo, é necessário ter o código pronto para que possa ser usado no
WTK.
Contudo, o WTK é uma excelente ferramenta para desenvolvimento em J2ME pois
possui uma série de ferramentas para gerenciar MIDlets.
Algumas de suas ferramentas são: (SUN, 2005 F)
•
Um emulador onde podem ser vistos e testados os aplicativos desenvolvidos;
•
Um application profiler, que facilita a análise do tempo de execução de um método e
seu uso;
•
Uma ferramenta para monitoramento de memória;
•
Uma ferramenta para auxiliar na medição de velocidade de execução;
Um ponto bastante interressante no WTK é a possibilidade de, ao criar um projeto,
definir API’s adicionais, o MIDP e o CLDC a serem usados.
O WTK está disponível gratuitamente no site da SUN.
SunONE Studio
32
O SunONE Studio é um ambiente completo de desenvolvimento (Wells, 2004). Esta
ferramenta possui editor de código fonte, compilador e gerador de pacotes de aplicativos.
Em sua versão Standard Edition acrescenta suporte para JSP, XML, RMI e JDBC. Existe a
possibilidade de integrar o WTK com o pacote do SunONE, mas esta é uma opção que
decidimos não tomar devido a complexidade de uso do SunONE e ao alto consumo de
processamento de máquina exigido. Este ferramenta é gratuita e fica disponível para
download, em sua edição 4. (SUN, 2005, G)
JBuilder
A BORLAND é a criadora do JBuilder. Este IDE é um dos mais populares do
mercado (Wells, 2004).Atualmente existe uma ferramenta (extensão) adicional do JBuilder
chamada
MobileSet.
Esta
extensão
foi
criada
especificamente
para
facilitar
o
desenvolvimento de aplicativos em J2ME.
Esta ferramenta da BORLAND não é gratuita, mas uma versão de teste (trial) pode
ser encontrada no site da empresa. (BORLAND,2005 A)
Eclipse
Outra ferramenta gratuita é o IDE Eclipse. Eclipse is software open source voltada
para desenvolvimento de projetos e criação de software. Este IDE possui um grande número
de ferramentas e pode suportar, além de JAVA, C e C++. A versão mais atual pode ser
encontrada para download site da fundação Eclipse .(Eclipse, 2005 A)
IDEA
Esta ferramenta extremamente poderosa não possui versão gratuita e a versão para
trial vem com uma série de limitações. A maior vantagem deste IDE é a grande quantidade
de plugins que permitem ao IDEA uma grande versatilidade. (IDEA, 2005 A)
CodeWarrior
Este IDE proporciona aos usuários o benefício de funcionalidade independente do
fabricante do processador do dispositivo móvel. É possível usar os mesmos códigos para
plataformas como Freescale (Motorola), Texas, Intel, etc. O CodeWarrior compilador e
debugger foi eleito o número 1 do mercado nos Estados Unidos como melhor ferramenta de
desenvolvimento para dispositivos móveis comerciais (Gartner Dataquest report). Outro
ponto interessante neste IDE é que existe a possibilidade de manter o uso de outras
33
ferramentas de desenvolvimento e mesmo assim utilizar este IDE como centralizador de um
projeto. (CodeWarrior, 2005 A)
2.9.4 Kits de desenvolvimento fornecidos por fabricantes
Os maiores fabricantes mundiais de dispositivos móveis disponibilizam através de
seus portais na internet seus próprios kits de desenvolvimento. Segue uma breve descrição
de alguns dos principais fabricantes que possuem áreas de manufatura de dispositivos
móveis no Brasil.
•
Motorola: este fabricante disponibiliza uma vasta biblioteca de documentos sobre seus
principais
produtos,
assim
como
um
pacote
completo
de
ferramentas
para
desenvolvimento em J2ME. Dentre estas ferramentas, estão os SDK’s, ferramentas de
mensagens, criação de figuras em bit-map, sons e temas (fundos de tela e “skins” para o
menu do dispositivo móvel. Este fabricante também possui um programa de empréstimo
de dispositivos móveis para desenvolvedores cadastrados.
(Motorola, 2005
A)
•
Nokia: o Nokia Developer´s Suíte 3.0 for J2ME é um pacote de ferramentas completo
para desenvolvimento em J2ME nos dispositivos móveis do fabricante Nokia. Este
pacote oferece ferramentas para desenvolvimento de classes e pacotes de aplicações,
verificação de funcionamento e processo de transferência a um dispositivo móvel. Este
pacote também permite
gerenciar, configurar e demonstrar uma aplicação em
funcionamento usando simuladores dos principais modelos Nokia disponíveis. Este
fabricante também distribui gratuitamente informações e SDK para a plataforma Symbian
e BREW. (Nokia 2005, A)
•
Sony-Ericsson: no portal deste fabricante documentação, suporte técnico, fórum e o SDK
para os dispositivos móveis mais recentes. É possível encontrar também uma agenda de
eventos relacionados aos dispositivos móveis, principalmente os de J2ME. Outro ponto
interessante deste portal são alguns estudos de caso disponibilizados para os usuários
registrados no site.
•
Samsung:
este fabricante
disponibiliza um pacote completo de ferramentas para
desenvolvimento em J2ME, usando SDK’s diferentes para cada modelos (plug in do
mesmo SDK). Além de especificações sobre seus produtos, documentos sobre
funcionamento e descrição detalhada o fabricante disponibiliza classes especiais para
testes de áudio e display. (Samsung, 2005 B)
34
Todos os fabricantes fornecem também em seus portais uma seção de FAQ
(perguntas mais freqüêntes) e alguns mantem um Fórum para compartilhar informações
e manter um canal direto entre os desenvolvedores e os especialistas do próprio
fabricante.
A maioria dos portais possui material exclusivo para aqueles que estivem
cadastrados no portal, com acesso restrito e uso de senha e login.
Como comentário final deste item, é bastante comum a estes SDK’s possuírem
algum tipo de “plug in” para os IDE’s mais usados do mercado tais como ECLIPSE e
CodeWarrior.
2.9.5 Transferência de um MIDlet para um dispositivo móvel
Existem basicamente dois caminhos: via conexão com a operadora e via direta no
dispositivo móvel.
Via direta no dispositivo móvel
A maioria dos dispositivos móveis possui esta facilidade. Em dispositivos mais novos
é possível realizar esta operação via Bluetooth. Esta tecnologia permite conexão dispositivo
para dispositivo, sem intervenção de uma infra-estrutura (cobertura de sinal de uma
operadora). É também possível ser feito via conexão de cabo. Para isto, deve ser respeitado
o padrão adotado por cada fabricante. Podem variar os programas que realizam este
processo, o padrão dos cabos e conectores, etc.
Este processo é normalmente acessível somente a desenvolvedores.
Via conexão com a operadora
Este caminho é sem dúvida o mais interessante. Por esta via é possível criar a
possibilidade de acesso ilimitado ao MIDlet. Muitas operadoras utilizam sites na internet
para tornar acessível a aquisição de um MIDlet. Obviamente, devido ao perfil de cada
dispositivo móvel (MIDP) o MIDlet é disponibilizado por modelo e por fabricante. Algumas
operadoras negociam acesso com empresas especializadas em distribuição de conteúdo.
Normalmente um link para o site destas empresas é disponibilizado no site da operadora.
35
2.9.6 Exemplos de MIDlets
Existem atualmente diversos fornecedores de MIDlets no mercado. Grande parte
deles disponíveis para venda de aplicativos ou para contatos via portais na internet.
Segue um exemplo escolhido dentre vários. Este portal apresenta alguns diferenciais
em relação a outros também disponíveis via internet. Devido a sua organização,
apresentação, formato dos menus e confiabilidade (os arquivos realmente estão onde são
indicados), o GETJAR é um bom exemplo de portal para MIDlets. Pode-se ver na figura 5 a
página inicial do portal.
Figura 05 – Portal GETJAR: fonte de MIDlets (GETJAR, 2005 A)
Selecionamos aleatoriamente o fabricante Motorola e o modelo E398. Dentre os
diversos MIDlets disponíveis selecionei o primeiro encontrado: Mobile Mail. Pode-se ver na
figura 06 que uma breve descrição de funcionamento fica disponível para consulta.
Figura 06 – Portal GETJAR : selecionando o MIDlet Mobile Mail (GETJAR, 2005 A)
36
Existem duas formas de download do MIDlet : uma via download dos arquivos JAD e
JAR disponíveis e outra via portal web para dispositivos móveis. Através do dispositivo
móvel, o usuário pode acessar diretamente o portal GETJAR e entrar com o código “3630”
para download automático do aplicativo direto no dispositivo móvel. Pode-se ver na figura 07
os dois caminhos para download do MIDlet (usando os arquivos JAR e JAD ou através do
código direto no dispositivo móvel).
Figura 07 – Portal GETJAR: facilidade de download do MIDlet (GETJAR, 2005 A)
Atualmente existem neste portal MIDlets gratuitos e versões pagas. A disponibilidade
para download direto no dispositivo móvel depende da operadora local e normalmente
funcionam somente nos países de origem (neste caso, somente para países da Europa).
.
37
3.0
SELEÇÃO DE UM DISPOSITIVO MÓVEL
Antes de falarmos de terminais, é importante falar sobre as tecnologias disponíveis
no mercado que permitem a conexão ( o link ) entre um telefone celular e outro. Com
exceção do uso da tecnologia BlueTooth hoje presente em alguns telefones e acessórios,
toda a comunicação entre dois terminais celulares depende obrigatoriamente de uma
estrutura de rede celular como suporte.
3.1
A tecnologia CDMA
CDMA – Code Division Multiple Access ou Acesso Múltiplo por Divisão de Código é
um método de transmissão digital baseada em spread spectrum., que significa
“espalhamento espectral”. Em outras palavras, o CDMA utiliza sinal digital em alta
freqüência e com grande número de símbolos (códigos) o que causa um espalhamento
deste sinal no espectro de freqüências e consequentemente uma grande largura de banda.
É utilizado em sistemas celulares de segunda e terceira geração com o padrão
internacional IS-95. No CDMA cada ligação recebe um código que a estação móvel utiliza
para identificar qual dos sinais no espectro lhe dizem respeito. Assim, a tecnologia CDMA
utiliza sinal totalmente digital baseado em códigos. (CDG, 2005 A).
Existem atualmente mais de 300 operadoras no mundo que utilizam a tecnologia
CDMA. Estas operadoras estão espalhadas em 160 paises e contam com mais de 260
milhões de usuários. (CDG, 2005 A).
O CDMA utiliza o BREW como código padrão para desenvolvimento de aplicativos
para terminais celulares. O BREW foi desenvolvido pela empresa QUALCOMM, que é a
criadora da tecnologia CDMA comercial que conhecemos. Como a QUALCOMM é também
fabricante de dispositivos semicondutores, grande parte dos terminais celulares de
tecnologia CDMA hoje em uso no mundo usam chips da QUALCOMM ou chips equivalentes
fabricados com autorização da QUALCOMM (QUALCOMM, 2005 A).
38
3.2
A tecnologia GSM
GSM - Global System for Mobile Communication - tecnologia originalmente
conhecida como Groupe Special Mobile, é um padrão digital de segunda geração do celular
desenvolvido na Europa e adotado na maior parte do mundo (GSM, 2005 A).
Desenvolvido inicialmente para a faixa de 900 MHz, o GSM teve posteriormente uma
versão adaptada para as faixas de 1800 e 1900 MHz. Isto significa que os terminais
celulares GSM podem funcionar em qualquer lugar do mundo onde exista sinal de
tecnologia GSM.
O consórcio mundial GSM escolheu a plataforma Java da Sun para desenvolvimento
de aplicativos móveis (J2ME).
A tecnologia GSM é líder mundial em cobertura e volume de usuários. São mais de 700
operadoras, presentes em 210 países e com um número de usuários superior a 1,5 bilhões
de pessoas. (GSM, 2005 A)
39
3.3
Fabricantes de dispositivos móveis : telefones celulares
O mercado atual de telefonia celular é formado basicamente de três tipos de
terminais : os de baixo custo, os de médio custo e os de alto custo. Os valores podem variar
(em dolar) normalmente nos seguintes limites: baixo custo até U$74.00, médio custo entre
U$75.00 e U$300.00, alto custo a partir de U$301.00 em geral. (GSM Arena, 2005 A).
Os celulares pré-pagos representam 80% da base total instalada. Celulares prépagos são aqueles que não possuem assinatura básica, ou seja, os clientes adquirem
créditos para uso do celular e recarregam todas as vezes que os créditos acabam. O custo
por minuto desta modalidade de funcionamento normalmente tem tarifa mais cara que os
terminais pós-pagos. Estes são os telefones com assinatura básica e conta mensal.
Representam 20% da base instalada, mas somam mais de 50% de toda a receita das
operadoras. (Teleco, 2005 A)
Na ANATEL existem atualmente mais de 30 fabricantes cadastrados. Destes apenas
15 mantém produtos em portfolio no mercado. Seguem como exemplo alguns dos principais:
Nokia, Motorola, Samsung, LG, Sony Ericsson, Alcatel, Panasonic, Sagem, Sendo, BenQ,
Kyocera, etc. (ANATEL, 2005 A)
Mostramos a seguir alguns exemplos de dispositivos celulares de algumas marcas
líderes de mercado. (GSM Arena, 2005 A)
Vemos que quando identificamos os dispositivos de médio e alto custo encontramos
muitos recursos disponíveis ao dispositivo móvel. Na tabela que segue chamamos de
capacidade o número de funções distintas oferecidas para cada modelo. Estes recursos
estão diretamente relacionados a programas (aplicativos) disponíveis no dispositivo móvel.
Logo a fatia do mercado de médio e alto custo são muito interessantes para o estudo que
estamos realizando.
Normalmente os fabricantes distribuem os modelos de baixo custo para as
operadoras de celular com programas já carregados e inacessíveis aos usuários para
remoção ou alteração. Conforme o valor do modelo altera para patamares maiores, os
recursos para que o usuário possa escolher os programas que deseja aumentam
consideravelmente a ponto de serem um diferencial. Tem-se notado que as operadoras
buscam customizar os modelos incluindo cores distintas, logos, desenhos e aplicativos
exclusivos. Portanto é comum hoje encontrar telefones de baixo custo que saem de fábrica
com jogos pré-programados. No entanto, modelos de médio e alto custo permitem ao
usuário escolher, após a aquisição do modelo, realizar o download de novos jogos e
aplicativos.
40
Figura 08 – Comparação de modelos de dispositivos móveis (GSM, 2005 B)
41
4.0
MERCADO ATUAL E TENDÊNCIAS
Nos últimos meses a mídia divulgou uma série de fusões e acordos comerciais entre
as industrias de fabricantes de celulares e desenvolvedores de software.
As propostas tem sido ousadas e uma delas chama a atenção: definir um protocolo único e
padrão para todo o mercado de celulares.
Analistas de mercado tem anunciado o rápido crescimento pelos chamados “acessos
de banda estreita” usando basicamente celulares, PDA’s e smartphones. Levando em
consideração que existe uma forte convergência de tecnologias, o mercado aponta para
uma junção destes aparelhos em um único dispositivo móvel. (GizMODO, 2005 A)
4.1
Mercado mundial
Fora do Brasil, principalmente na Europa, as operadoras assinam contratos com
provedores de conteúdo para atender seus clientes. A grande maioria utiliza os serviços de
pedido via internet e download do aplicativo para o dispositivo móvel via ar (sinal da própria
operadora). O pagamento do serviço é feito via conta telefônica ou desconto de créditos.
Apesar de ser comum tanto para os serviços das operadoras CDMA quando as
GSM, os serviços de download das operadoras precisam dispor de uma estrutura completa
para agregar valor e agradar ao usuário. Tem-se como exemplo site de jogos europeu
Global Fun, que segue na figura 6. Esta empresa fornece os programas e os serviços de
compra on-line diretamente de seus servidores. A operadora entra basicamente com o sinal
rádio e a estrutura de sua rede.
Figura 09 – Site de venda de jogos em J2ME da empresa GlobalFun (GlobalFun, 2005 A)
42
Um ótimo exemplo de tendência diz respeito ao lançamento cinematográfico da
UNIVERSAL para dezembro de 2005 : King Kong. Os produtores do filme e os estúdios
agregados desenvolveram farto material de propaganda para diversas mídias, incluindo os
dispositivos móveis. A figura 07 nos mostra o site oficial do filme. Na figura 08 identificamos
no site um link que remete a outro endereço na internet, onde encontramos o site oficial do
jogo desenvolvido exclusivamente para o lançamento do filme.
Figura 10 – Site de anúncio de filme King Kong (Apple, 2005 A)
Figura 11 – Site de anúncio de filme King Kong (Apple, 2005 A)
43
Figura 12 – Site de venda de jogos baseados no filme King Kong (GlobalFun, 2005 A)
A empresa GAMELOFT é a responsável pelo desenvolvimento do jogo, totalmente
construído em J2ME. Pode-se ver na figura 09 o site oficial dos jogos baseados no filme,
dentre os quais está o jogo exclusivamente para dispositivos móveis.
A distribuição do jogo é feita via operadora de telefonia celular. No site da Gameloft
(figura 10) é possível encontrar uma lista com os modelos de celulares compatíveis com o
jogo.
Figura 13 – Site de empresa Gameloft (Gameloft, 2005 A)
44
4.2
Mercado brasileiro
O Brasil possui hoje mais de 80 milhões de usuários de terminais celulares.
Autorizadas pela ANATEL – Agência Nacional de Telecomunicações, órgão oficial do
Governo brasileiro que regulamenta o uso de tecnologia de comunicações e uso das faixas
de freqüência, o Brasil conta hoje com sete operadoras ativas.
Destas, temos 1 CDMA (VIVO) e 07 GSM (TIM, Oi, CLARO, BR Telecom, Telemig +
Amazônia Celular, CTBC e Sercomtel).
A tecnologia GSM representa mais de 47% do total de terminais celulares ativados, com
mais de 38 milhões de usuários. (Teleco, 2005 A)
Ainda existem cerca de 17 milhões de usuários que estão migrando de tecnologia.
Estes usuários usam hoje terminais TDMA (Acesso Múltiplo por Divisão de Tempo),
tecnologia considerada ultrapassada. O TDMA é um tipo de GSM menos avançado e com
recursos limitados. Por estes motivos, não estaremos levando em consideração esta
tecnologia neste trabalho. (Teleco, 2005 A)
Seguem informações sobre a distribuição atual de usuários no mercado brasileiro.
A tecnologia GSM tem crescido 5 vezes mais (em números de usuários) quando comparada
a tecnologia CDMA.
Figura 14 – Distribuição do mercado Brasil – número de assinantes (Teleco, 2005 A)
45
Figura 15 – Cobertura das operadoras de telefonia celular no Brasil (Teleco, 2005 A)
46
Devido aos fatores expostos, a escolha por modelos de tecnologia GSM indica ser a
mais adequada para o mercado atual. Veremos a seguir os fabricantes de dispositivos
móveis e alguns exemplos.
A plataforma SUN J2ME pode facilitar o rápido crescimento dos dispositivos
celulares como portais de acesso a aplicações mais complexas e úteis. Tanto
desenvolvedores quanto provedores de conteúdo podem tirar enorme vantagem deste
mercado em crescimento.
Podemos destacar como grandes benefícios do J2ME:
•
grande quantidade de fabricantes e enorme variedade de modelos;
•
facilidade de transferência de um dispositivo para outros (portabilidade);
•
conexão segura via internet;
•
aplicações compactas que não usam rede de banda larga para seu funcionamento;
•
funcionamento dos aplicativos “off-line” (não conectados a um provedor);
Atualmente todas as operadoras GSM no Brasil estão investindo em conteúdo e
serviços para dispositivos móveis. Entre os principais ítens estão os jogos, campainhas e
fundos de tela. Para os telefones de alto custo existem outros tipos de aplicativos, mas este
são raros no Brasil.
Figura 16 – Site de venda de jogos em J2ME da operadora Oi (Oi, 2005 A)
No Brasil alguns fabricantes de dispositivos móveis sairam na frente e colocaram
disponíveis aos usuários das operadoras um site dedicado aos modelos comercializados no
mercado. Estes sites trazem conteúdo rico em informações, material para download (muitos
gratuitos) e um registro de fidelidade para manter os clientes informados das novidades e
dos lançamentos.
47
Figura 17 – Site de conteúdo para celular da Samsung . (Samsung, 2005 A)
Única operadora de tecnologia CDMA no Brasil, a VIVO também possui um site
dedicado aos seus usuários. Nele é possível obter muitas informações sobre os modelos e
os aplicativos disponíveis. Normalmente estes aplicativos podem ser baixados diretamente
do menu dos telefones CDMA.
Figura 18 – Site de venda de jogos em BREW da operadora VIVO (Vivo, 2005 A)
48
Também no Brasil podemos encontrar empresas que estão desenvolvendo conteúdo
exclusivamente para dispositivos móveis. Podemos citar como exemplo a empresa de
desenvolvimento de software Compera, baseada na cidade de Campinas. Pode-se ver na
figura 16 a página inicial da empresa que enfatiza “tecnologia em mobilidade”, indicando que
está voltada ao desenvolvimento de aplicativos para dispositivos móveis.
Assim como no exemplo da empresa Gameloft, também a Compera não comercializa
diretamente seus produtos. A empresa desenvolve aplicativos customizados para seus
clientes.
Figura 19 – Site da empresa COMPERA – Campinas – SP (Compera, 2005 A)
49
4.3
Breve comparação entre J2ME e BREW
Apesar das vantagens mencionadas anteriormente sobre o J2ME, é interessante
considerar que existe um competidor no mercado de aplicativos para dispositivos móveis: o
BREW.
4.3.1 Breve descrição do BREW
A plataforma BREW, desenvolvida pela QUALCOMM, é reconhecida mundialmente
como referência no desenvolvimento de aplicativos.
Uma das maiores vantagens do BREW diz respeito ao processo e à organização
com que os desenvolvedores tem acesso aos clientes. Segue a declaração de um diretor da
US Cellular, operadora CDMA nos Estados Unidos: (US Cellular, 2005 A)
“ Não vemos BREW e Java sendo comparados como maças-com-maças. BREW
inclui coisas como modelos de negócios para que possamos ter um relacionamento entre os
provedores de conteúdo e a QUALCOMM, e existe uma estrutura para margem de
rendimento e faturamento. Isto não é automático com J2ME.” – John Cregier, Diretor de
Estratégia de dados e Serviços da US Cellular. (BREW, 2005 A)
A plataforma BREW foi criada pela QUALCOMM para desenvolvimento de
aplicações voltadas para dispositivos celulares móveis.
É uma plataforma que pode
suportar não somente CDMA, como também outras tecnologias celulares tais como UMTS e
até mesmo GSM. Entretanto, quando BREW surgiu foi apresentado primeiramente como
uma plataforma unicamente desenvolvida para unidades de tecnologia CDMA.
O nome BREW vem de Binary Runtime Environment for Wirelles ou seja, Ambiente
RunTime Binário para dispositivos sem fio. Basicamente é um programa (software) , que
permite através de download executar pequenos programas (aplicativos). Podemos citar
aplicativos tais como jogos, geradores de texto para mensagens, etc.
Uma das principais vantagens da plataforma BREW está no fato de que os
desenvolvedores de aplicativos podem facilmente mover suas aplicações para qualquer
produto que use circuito (chipset) QUALCOMM. O BREW funciona entre a aplicação e o
sistema operacional do dispositivo móvel., permitindo aos desenvolvedores criar aplicações
sem precisar codificar um sistema de interface ou entender de aplicações específicas para
dispositivos sem fio. (BREW, 2005 A)
50
4.3.2 Desvantagens do J2ME
A plataforma J2ME possui uma série de vantagens, porém como em todas as
plataformas criadas para desenvolvimento, também possui suas desvantagens.
Para as operadoras, Java- J2ME significa segurança devido ao seu processo único de criar
bytecodes. Isto significa que os aplicativos destinados aos usuários finais não correrão o
risco de serem alterados para o formato de vírus e portanto causar problemas de uso.
Assim, aplicações em J2ME significam mais uma fonte de receita para operadoras. Para os
desenvolvedores, ter aplicativos em J2ME no mercado significa oportunidade de negócios.
Com uma base de milhões de usuários, as probabilidades de negócios são muito otimistas.
Para o usuário final (o consumidor) J2ME é sinônimo de aplicativos passíveis de download.
Isto transforma os dispositivos móveis em um dispositivo de muitas utilidades, indo além de
apenas trafegar voz. Logo, o dispositivo móvel pode ser personalizado e passar então de
um simples dispositivo de comunicação para uma central móvel de entretenimento e
produtividade. Para os fabricantes, J2ME é uma oportunidade de agregar valor a
dispositivos móveis e alavancar as vendas.
Contudo, para fabricantes, usuários, desenvolvedores e operadoras o mundo não é
tão perfeito. No quesito segurança é necessário levar em consideração que os MIDlets
disponibilizados por operadoras e seus parceiros precisam, antes de chegar aos usuários,
fazer parte do acervo disponível nos provedores das operadoras. Logo, faz-se necessário
incluir custos para as operadoras na montagem estruturada de infra-estrutura para prover
este serviço. Um ponto muito importante que deve ser levado em consideração é o fato de
que por enquanto não existe um processo formal para garantir as operadoras o direito sobre
o material disponibilizado. Mais ainda, é de difícil implementação um processo de
“trial” para que o usuário possa testar um aplicativo (principalmente jogos) antes de compralo efetivamente. Esta dificuldade é geradora de perda de divisas para as operadoras e
distribuidores de MIDlets. Devido ao enorme número de dispositivos móveis produzidos
pelos mais diversos fabricantes, encontramos no mercado um sem número de dispositivos
móveis com características diferenciadas. Ou seja, aplicativos em J2ME desenvolvidos para
um tipo de dispositivo não necessariamente irá funcionar corretamente em outros. Assim, o
desenvolvimento dos perfis (MIDP) exige que os fabricantes adicionem bibliotecas próprias
para seus dispositivos móveis. Este processo, apesar de organizado,fragmenta o mercado e
torna inviável o desenvolvimento de aplicações avançadas, mais elaboradas e abrangentes.
Este é seguramente um enorme problema para desenvolvedores, que na seqüência afeta os
geradores de conteúdo e por fim as operadoras. Com o aumento do poder de
processamento dos novos dispositivos móveis no mercado, cresceram também em
complexidade (e tamanho de arquivo) os aplicativos compatíveis. Mesmo sendo uma versão
51
especialmente desenvolvida para dispositivos móveis, o J2ME usa como base a plataforma
Java, criada originalmente para microcomputadores (PC’s). Assim, existe a tendência
natural de consumo de código e aumento do tamanho dos arquivos. Pensando que estes
arquivos deverão ser requisitados via ar (da operadora para os dispositivos móveis), falar
em tamanho de arquivo é falar em tempo de download e custo de acesso (“air-time”). Este
ponto penaliza o usuário final.
Estes pontos somados podem ser entendidos como as maiores desvantagens do
J2ME atualmente. (MicroJava, 2005 A) (S5System, 2005 A) (The Register, 2005 A)
4.3.3 J2ME versus BREW
As opiniões sobre a comparação entre J2ME e BREW são as mais diversas
possíveis. De um lado estão os defensores do J2ME elogiando sua praticidade e
flexibilidade de desenvolvimento. De outro estão os defensores do BREW elogiando seu
baixo consumo de processamento e performance de execução.
Enquanto o BREW por um lado apresenta uma possibilidade de negócios integrada e
um mecanismo de controle configurados de acordo com o cliente,de outro lado é uma
tecnologia proprietária e centralizada. (IBM, 2005 A)
Uma das maiores desvantagens dos aplicativos para dispositivos móveis é o fato de
que os aplicativos precisam ser adaptados para cada modelo de dispositivo móvel celular.
Somente depois destas modificações o aplicativo pode finalmente funcionar.
O J2ME amarra junto a API para dispositivos celulares móveis que possuem
funcionalidade similar os chamados perfis (profiles). Porém, como o mercado de dispositivos
móveis cresce rapidamente tanto em quantidade quanto em variedade de modelos, o
suporte de perfil tem resultado em um exagerado número de perfis para atender a todos os
modelos. Isto tem encarecido os custos de desenvolvimento.
O J2ME possui uma grande comunidade de desenvolvedores e o fato de poder
receber suporte dos fabricantes sem custo atrai uma quantidade crescente de profissionais.
O BREW possui uma popularidade baixa devido basicamente a sua comunidade de
desenvolvedores ser restrita somente a filiados cadastrados.
O software para os dispositivos móveis baseados em BREW podem ser
desenvolvidos em C ou C++ que usam livremente o BREW SDK. O SDK inclui um emulador
do BREW que pode ser usado para testes durante o processo de desenvolvimento. Ao
contrário da plataforma J2ME, onde todo o desenvolvedor pode carregar e executar o
software em qualquer dispositivo móvel que suporte J2ME, no caso do BREW as aplicações
devem ter assinatura digital. Isto porque o BREW dá controle completo sobre o hardware do
52
dispositivo móvel. Portanto, somente desenvolvedores autorizados BREW possuem as
ferramentas necessárias para criação da assinatura digital.
Além disso, as aplicações
digitalmente assinadas somente podem ser executadas nos dispositivos móveis de teste
permitidos. Isto limita muito a atuação de desenvolvedores e pequenas empresas que
trabalham com desenvolvimento. Outra barreira está no próximo passo: uma vez que a
aplicação foi desenvolvida e testada em um dispositivo móvel autorizado, por um
desenvolvedor certificado BREW, a aplicação deve ser submetida a QUALCOMM para o
TRUE BREW test (verdadeiro teste BREW). (BREW, 2005 A)
Somente depois da aplicação passar em todos os testes então poderá ser oferecida
a uma operadora de serviço móvel ou a uma empresa provedora de conteúdo. A aplicação
pode então receber a assinatura digital e ser usada em dispositivos móveis que suportem
BREW.
Assim como foi descrito no item 2.8.4, também as aplicações em BREW (tais como
jogos) podem ser baixadas (download) usando um cabo USB. Isto sempre que a operadora
permitir esta operação. Como exemplo, a aplicação AppLoader da QUALCOMM é usada
para transferir arquivos para um dispositivo móvel. Todos os aplicativos em BREW rodam
exclusivamente em hardware QUALCOMM. Na figura 17 pode-se ver os chipset’s
desenvolvidos para as diversas tecnologias disponíveis no mercado.
Figura 20 – Quadro de processadores QUALCOMM por tecnologia (plusd_IT, 2005 A)
53
Outro ponto diferente entre J2ME e BREW diz respeito ao empacotamento do
aplicativo. Uma aplicação do BREW é empacotada diferentemente pois a aplicação terá
uma arquivo name.mif e um arquivo name.mod, além de outros arquivos com extensão
(.bar). A aplicação deve também conter obrigatoriamente um arquivo com a assinatura
digital específica para o dispositivo móvel. (Wikipedia, 2005 A)
A QUALCOMM tem demonstrado às operadoras que o BREW possui uma proposta
viável, que o download de aplicativos via web pode ser organizado, certificado, distribuído e
cobrado de maneira correta e lucrativa.
Contudo, a percepção geral é a de que o mercado é predominantemente de
aplicativos J2ME.
Figura 21 – Projeção de dispositivos móveis com Java até 2007 (Zelos Group, 2005 A)
Atualmente o J2ME é a plataforma de desenvolvimento para dispositivos limitados
que possui maior base instalada (número de dispositivos móveis) no mundo e atende aos
requisitos da maioria dos dispositivos móveis de todos os fabricantes globais.
Outro ponto de extrema importância é o custo do desenvolvimento. No J2ME os
desenvolvedores podem usar sem custo os recursos da comunidade J2ME, o que aumenta
consideravelmente o número de desenvolvedores no mundo. Devido a isto, existe farto
banco de informações sobre os mais variados pontos e aplicações voltadas ao J2ME.
A documentação disponibilizada pela comunidade Java permite também organizar e
uniformizar o processo de desenvolvimento de MIDlets contando com o apoio dos
fabricantes de dispositivos móveis. (Américas Network, 2005 A)
54
Na figura 17 pode-se ver um quadro comparativo entre J2ME e BREW contendo
diversos aspectos, muitos deles mencionados no texto deste trabalho.
Forte gerenciamento de memória.
Gerenciamento de memória mais eficiente
Utiliza a KVM : máquina virtual Java
Escrito em C++ e C#
Altamente portátil
Altamente portátil
Performance comprometida devido ao alto Alta
performance
na
execução
de
consumo de processamento
programas
A KVM permite código seguro (bytecodes)
Possíveis problemas com validação de
parâmetros (overflow)
Plataforma mais "madura" (criada a mais Manipula gráficos 3D com alta performance
tempo)
Aplicativos J2ME rodam somente J2ME
Aplicativos em BREW podem suportar J2ME
(em estudo)
Hardware possui mais de 10 diferentes Hardware dependente de licença e chipset
fabricantes
Plataforma
QUALCOMM
aberta
a
todos
os Plataforme somente para desenvolvedores
desenvolvedores Java
certificados BREW
1,5 bilhões de usuários (base mundial)
260 milhões de usuários (base mundial)
Baixo custo de implementação
Custo de implementação médio
Implementação livre
Implementação sob demanda
Figura 22 – Tabela de comparação entre algumas das características do J2ME e BREW
Nota-se que apesar dos prós e contras que a escolha de uma plataforma ideal deve
estar muito ligada à solução que consiga o melhor custo-benefício além de eficiência. Fazse necessário uma abrangente pesquisa de mercado para entender de que forma podem
ser exploradas as potencialidades de cada plataforma (J2ME ou BREW) de acordo com a
aplicação desejada.
55
5.0
CONCLUSÕES
Pode-se dizer que os resultados obtidos com este trabalho consolidam uma breve
introdução ao mundo do J2ME e sua versatilidade para uso em dispositivos móveis.
O grande desafio no momento é tornar todo o conteúdo disponível na internet para
acesso via wireless, usando principalmente um telefone celular. A chamada terceira geração
de terminais celulares provavelmente não será o marco histórico para esta migração. Ainda
em disputas internacionais, temos os consórcios CDMA e GSM lutando por espaço e
mercado, não tendo sido definido até o momento qual será a tecnologia única para a qual os
futuros dispositivos móveis estarão migrando. Levando em conta que a maior parte dos
dispositivos móveis atualmente em uso são de tecnologia GSM e que o consórcio CDMA
ainda não apresentou uma solução viável em custo e benefício para atrair investimentos,
temos um mercado de dispositivos móveis GSM em expansão.
Os fabricantes tem investido em capacidade dos terminais GSM, desenvolvendo
modelos cada vez mais sofisticados e com preços muito competitivos. Esta combinação
permite rápida introdução do produto e torna viável o uso de recursos antes exclusivos de
dispositivos fixos e mais robustos, tais como consoles de videogame ou computadores de
mesa.
Levando em consideração a máxima da Sun para Java “escreva uma vez,execute
em qualquer lugar”, a medida em que os terminais celulares avançam em capacidade, a
flexibilidade e preparo do Java para internet permite um casamento interessante e com forte
laços. Com Java, as operadoras poderão fornecer a seus usuários um vasto portfólio de
aplicações e serviços.
J2ME é uma das tecnologias que irá permitir as operadoras
maximizar as oportunidades de negócios e garantir o crescimento do mercado de
comunicação wireless. Os números de mercado apontam que a maioria dos usuários
possuem hoje terminais de baixo custo. Estes dispositivos ainda são muito limitados para
aplicativos realmente interessantes. Logo, o mercado de dispositivos móveis de médio e alto
custo devem ser os alvos para desenvolvimento de MIDlets.
Com uma plaraforma restrita a terminais CDMA, o BREW hoje está em desvantagem
quando comparado ao J2ME. Basicamente podemos destacar dois aspectos: o volume de
terminais em campo (exageradamente superior para a tecnologia GSM – J2ME) e a postura
rígida das operadoras CDMA em relação às restrições impostas aos dispositivos móveis
CDMA – BREW tais como bloqueio de downloads, transferência de fotos, etc.
De olho neste mercado, muitas empresas estão surgindo para atender a demanda
das operadoras e fornecer conteúdo sob medida para fabricantes. Com um mercado de
customização em alta, as operadoras mostram-se dispostas a pagar empresas de
56
desenvolvimento de conteúdo para criar design e material que futuramente irá ser inserido
em dispositivos móveis diretamente nos fabricantes de dispositivos móveis.
A maioria dos fabricantes de celulares utilizam empresas especializadas para
fornecimento de conteúdo e alguns começam a investir na contratação de pessoal para
pesquisa e desenvolvimento nesta área.
Levando em consideração a grande variedade de dispositivos móveis existentes
atualmente, o mercado para J2ME está em expansão, porém de forma segmentada.
Portanto o desenvolvimento de aplicativos deve ser estudado e realizado em parceria com
operadoras e seus parceiros, no intuito de atender a necessidade a curto prazo e preparar o
caminho para desenvolvimento futuro em outros tipos de dispositivos móveis. O custo de
desenvolvimento deve estar direcionado ao grupo de dispositivos compatíveis e direcionado
para serviços comercializados pelas operadoras como conteúdo.
Apesar de complexo, existe farto material de estudo disponível principalmente para
aqueles que possuem mínimo conhecimento no idioma Inglês. O desenvolvimento não é
simples, porém existem fontes de informação diretamente em sites de grandes empresas
que precisam de mão-de-obra especializada neste segmento.
Desta forma, o J2ME se mostra como a tecnologia mais viável e mais adequada para
o uso e aplicação em dispositivos celulares móveis no momento. Este cenário pode ser
alterado a médio ou longo prazo de acordo com o desenvolvimento de hardware por parte
dos fabricantes e geração de demanda por parte das operadoras.
57
6.0
REFERÊNCIAS BIBLIOGRÁFICAS
Martin J. WELL, “J2ME game programming”, 2nda Ed., USA, Press , 2004, 682p.
John W. MUCHOW, “CORE J2ME – tecnologia & MIDP”, 3ra Ed., USA Pearson & Makron
Books , 2002 , 480p.
DEITEL, H & DEITEL, P., “JAVA – como programar” , 5ta Ed., USA, Bookman, 2002,
1020p.
SUN, “Whitepaper CLDC” , disponível via URL em
http://java.sun.com/j2me/docs/pdf/CLDC-HI_whitepaper-February_2005.pdf , 2005 A
SUN, “White papers” , disponível via URL em
http://java.sun.com/docs/ , 2005 B
SUN, disponível via URL em
http://java.sun.com/developer/Books/javaprogramming/JAR/index.html , 2005 C
SUN, disponível via URL em
http://developers.sun.com/techtopics/mobility/midp/articles/fsm/index.html , 2005 D
SUN, disponível via URL em
http://developers.sun.com/techtopics/mobility/midp/articles/intro/index.html , 2005 E
SUN, “Documentation” disponível via URL em
http://docs.sun.com/source/816-5081/preface.html , 2005 F
SUN, disponível via URL em
http://developers.sun.com/prodtech/msgqueue/reference/techart/index.html , 2005 G
SUN, disponível via URL em
http://java.sun.com/j2me/index.jsp , 2005 H
ECLIPSE, disponível via URL em
http://www.eclipse.org , 2005 A
58
QUALCOMM, disponível via URL em
http://www.qualcomm.com , 2005 A
ANATEL , disponível via URL em
http://www.anatel.gov.br , 2005 A
Apple, “Movies”, disponível via URL em
http://www.apple.com , 2005 A
JCP, disponível via URL em
http://jcp.org , 2005 A
JCP, disponível via URL em
http://jcp.org/en/jsr/detail?id=30 , 2005 B
JCP, disponível via URL em
http://jcp.org/en/jsr/detail?id=37 ,2005 C
JCP, disponível via URL em
http://jcp.org/en/jsr/detail?id=195 ,2005 D
JCP, disponível via URL em
http://jcp.org/en/jsr/detail?id=185 ,2005 E
JCP, disponível via URL em
http://jcp.org/en/jsr/detail?id=120 ,2005 F
JCP, disponível via URL em
http://jcp.org/en/jsr/detail?id=135 , 2005 G
JCP, disponível via URL em
http://jcp.org/en/jsr/detail?id=172 , 2005 H
IDEA, disponível via URL em
http://www.intellij.org/twiki/bin/view/Main/WebHome , 2005 A
59
ACE, “ACE software” , disponível via URL em
http://www.program-ace.com/games , 2005 A
OnJAVA, “The independent source for JAVA”, disponível via URL em
http://www.onjava.com/pub/ct/33 , 2005 A
Developnet, “Mobile Solutions Provider” , disponível via URL em
http://www.developnet.co.uk/projects.htm, 2005 A
BORLAND, disponível via URL em
http://www.borland.com/us/products/jbuilder/index.html , 2005A
GSM, “GSM sites around the world”, disponível via URL em
http://www.gsm-top.com/ , 2005 A
GSM, disponível via URL em
http://www.gsmarena.com , 2005 B
BORLAND, disponível via URL em
http://www.borland.com/us/products/jbuilder/index.html , 2005 A
GlobalFun, disponível via URL em
http://www.globalfun.com/ , 2005 A
Teleco, disponível via URL em
http://teleco.com.br , 2005 A
Oi, disponível via URL em
http://ww2.oiloja.com.br/ , 2005 A
CDG, “CDMA Development Group”, disponível via URL em
http://www.cdg.org , 2005 A
SAMSUNG , disponível via URL em
http://www.samsungmobile.com , 2005 A
60
SAMSUNG developer, disponível via URL em
http://developer.samsungmobile.com , 2005 B
VIVO, disponível via URL em
http://www.vivo.com.br/vivodownloads/aplicativos.php?cat=5 , 2005 A
GizMODO, “Cellular Phones”, disponível via URL em
http://us.gizmodo.com/gadget/cellular+phones/bydate/ , 2005 A
Gameloft, disponível via URL em
http://www.gameloft.uk , 2005 A
Compera , disponível via URL em
http://www.compera.com.br/ , 2005 A
US Cellular, disponível via URL em
http://easyedge.uscc.com/easyedge/jsp/home.jsp , 2005 A
BREW, disponível via URL em
http://brew.qualcomm.com/brew/en/press_room/press_room.html , 2005 A
Wikipedia, disponível via URL em
http://wikipedia.org , 2005 A
IBM, disponível via URL em
http://www-128.ibm.com/developerworks/wireless/library , 2005 A
America’s Network , disponível via URL em
http://www.findarticles.com/p/articles/mi_m0DUJ/is_2003_Nov_1/ai_110928129 , 2005 A
Nokia, disponível via URL em
http://www.forum.nokia.com/main/0,6566,034-2,00.html , 2005 A
CodeWarrior disponível via URL em
http://www.metrowerks.com/mw/default.htm , 2005 A
61
Motorola Motocoder, disponível via URL em
http://www.motocoder.com , 2005 A
Sony Ericsson, disponível via URL em
http://developer.sonyericsson.com/site/global/home/p_home.jsp , 2005 A
MicroJava Network , disponível via URL em
http://www.microjava.com/articles/perspective , 2005 A
S5System, disponível via URL em
http://www.s5systems.com/products.htm , 2005 A
The Register, disponível via URL em
http://www.theregister.co.uk/2004/10/29/nokia_preminet_java , 2005 A
plusd_IT Media (em koreano), disponible via URL em
http://plusd.itmedia.co.jp/mobile/ , 2005 A
Zelos Group , disponível via URL em
http://www.zelosgroup.com/ , 2005 A
GETJAR, disponível via URL em
http://www.getjar.com , 2005 A
62
7.0
ASSINATURAS
________________________________
________________________________
Mario Luiz C. da Silva
Peter Jandl

Documentos relacionados