- 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