- Polis Educacional

Frederico Constantino Raperger
0310014 – 8º Sem.
ANÁLISE COMPARATIVA DAS TECNOLOGIAS DE
DESENVOLVIMENTO DE SOFTWARE PARA DISPOSITIVOS
COMPUTACIONAIS MÓVEIS
Jaguariúna
2005
Frederico Constantino Raperger
0310014 – 8º Sem.
ANÁLISE COMPARATIVA DAS TECNOLOGIAS DE
DESENVOLVIMENTO DE SOFTWARE PARA DISPOSITIVOS
COMPUTACIONAIS MÓVEIS
Monografia apresentada à disciplina Trabalho
de Conclusão de Curso, do curso de Ciência da
Computação da Faculdade de Jaguariúna, sob
orientação do Prof. Ms. Peter Jandl Jr, como
exigência parcial para conclusão do curso de
graduação.
Jaguariúna
2005
RAPERGER,
Frederico
Constantino.
Analise
Comparativa
das
Tecnologias
de
Desenvolvimento de Software para Dispositivos Computacionais Móveis. Monografia
defendia e aprovada na FAJ em 18 de Dezembro de 2005 pela banca examinadora
constituída pelos professores:
Prof. MS Peter Jandl Jr
FAJ – Orientador
Prof. Roberto Vargas Pacheco
FAJ
Prof. José Arnaldo Geraldini Nunes
FAJ
RAPERGER,
Frederico
Constantino.
Analise
Comparativa
das
Tecnologias
de
Desenvolvimento de Software para Dispositivos Computacionais Móveis. 2005.
Monografia (Bacharelado em Ciências da Computação) – Curso Ciências da Computação
da Faculdade de Jaguariúna, Jaguariúna.
RESUMO
Segundo grandes empresas da área de telefonia celular, o comércio de aparelhos
celulares com tecnologias que possibilitem a criação de novos aplicativos, como J2ME,
Symbian e BREW. Por ser um mercado novo e existir mais de uma opção, uma pergunta de
difícil resposta que se forma é sobre como escolher a tecnologia que melhor se adeqüe ao
desenvolvimento de uma aplicação para tais dispositivos.
O BREW, criado pela Qualcomm, vem com a missão de ser o mais simples possível,
permitindo que seja suportado por telefones com baixa performance. A plataforma BREW
fica diretamente sobre o software de sistema do chip, permitindo aplicativos nativos em
C/C++ rápidos e fácil integração.
O Symbian OS é sistema operacional projetado especificamente para o ambiente
móvel, preenchendo os requisitos dos aparelhos das gerações 2.5 e 3 de celulares.
Segundo pesquisas, ele ocupa dois terços do mercado de smartphones. O Symbian OS é
formado por um consórcio de empresas como Nokia, Samsung, Panasonic, Motorola entre
outras.
O J2ME é uma plataforma de desenvolvimento para aparelhos celulares desenvolvida
pela Sun Microsystem. Hoje, muitas empresas fabricantes de celulares vêem grandes
vantagens e oportunidades na tecnologia Java, tanto que praticamente todos os modelos de
celulares da Nokia fabricados hoje já dispõem desta tecnologia.
No final estas tecnologias são comparadas em termo de:
•
Recursos e limitações existentes;
•
Metodologia de implementação;
•
Performance;
•
Suporte existente e produtos disponíveis.
Palavras-chave: WIRELESS, MOBILE, J2ME, BREW, SYMBIAN
SUMÁRIO
LISTA DE FIGURAS..................................................................................................... 6
LISTA DE SIGLAS........................................................................................................ 7
1.
INTRODUÇÃO ................................................................................................... 9
2.
BREW (BINARY RUNTIME ENVIRONMENT WIRELESS)............................... 10
2.1. Arquitetura do BREW ...................................................................................... 11
2.1.1. Estrutura dos módulos e interfaces do BREW ........................................... 12
2.2. Vantagens do BREW....................................................................................... 12
2.3. Ambiente de Desenvolvimento ........................................................................ 14
2.3.1. BREW SDK ............................................................................................... 14
2.3.2. Componentes do BREW SDK.................................................................... 14
2.3.3. Editor de Código ........................................................................................ 16
2.4. Metodologia de Implementação....................................................................... 17
2.4.1. Criação de Novos Aplicativos .................................................................... 17
2.4.2. Codificação do Sistema ............................................................................. 17
2.4.3. Classes do BREW e MIFs.......................................................................... 19
2.4.4. Execução do Aplicativo no Emulador......................................................... 21
2.4.5. Transferência do Aplicativo para o Celular................................................. 21
3.
SYMBIAN ......................................................................................................... 23
3.1. Arquitetura do Symbian OS ............................................................................. 23
3.2. Recursos ......................................................................................................... 24
3.2.1. Principais Funcionalidades ........................................................................ 24
3.2.2. Framework................................................................................................. 25
3.2.3. Infraestrutura de Comunicação.................................................................. 25
3.2.4. Telefonia.................................................................................................... 26
3.3. Conhecimentos Necessários ........................................................................... 26
3.4. Ambiente de Desenvolvimento ........................................................................ 26
3.5. Metodologia de Implementação....................................................................... 27
3.5.1. Codificação do Sistema ............................................................................. 27
3.5.2. Definição de Componentes........................................................................ 28
3.5.3. Especificação do Projeto ........................................................................... 28
3.5.4. Tipos de Aplicação .................................................................................... 29
3.5.5. Compilação do Projeto............................................................................... 29
3.5.6. Instalação do Aplicativo para o Celular ...................................................... 30
4.
J2ME (JAVA 2 MICRO EDITION) ..................................................................... 32
4.1. Arquitetura do J2ME ........................................................................................ 33
4.1.1. Configurations............................................................................................ 34
4.1.2. Profiles....................................................................................................... 35
4.1.3. APIs Ocionais ............................................................................................ 35
4.2. Recursos e Limitações Existentes ................................................................... 35
4.2.1. Configurações (CLDC)............................................................................... 35
4.2.2. CLDC 1.0................................................................................................... 36
4.2.3. CLDC 1.1................................................................................................... 36
4.2.4. Perfis ......................................................................................................... 37
4.3. Conhecimentos Necessários ........................................................................... 38
4.4. Ambiente de Desenvolvimento ........................................................................ 38
4.4.1. O JDK........................................................................................................ 38
4.4.2. Ferramenta de Desenvolvimento para Celular WTK .................................. 39
4.4.3. Editor de Código ........................................................................................ 39
4.5. Metodologia de Implementação....................................................................... 40
4.5.1. Criação de um Projeto ............................................................................... 40
4.5.2. Codificação do Sistema ............................................................................. 41
4.5.3. Execução do Aplicativo no Emulador......................................................... 42
4.5.4. Transferência do Aplicativo para o Celular................................................. 44
5.
PRODUTOS DISPONÍVEIS NO MERCADO .................................................... 45
5.1. Tecnologias Disponíveis no Mercado .............................................................. 47
6.
CONCLUSÃO................................................................................................... 48
7.
REFERÊNCIAS BIBLIOGRÁFICAS.................................................................. 50
LISTA DE FIGURAS
FIGURA 1.
ARQUITETURA DO BREW .................................................................. 12
LISTAGEM 1.
CÓDIGO-FONTE .............................................................................. 19
FIGURA 2.
O MIF NO BREW SDK.......................................................................... 20
FIGURA 3.
BREW MIF EDITOR.............................................................................. 20
FIGURA 4.
BREW EMULATOR .............................................................................. 21
FIGURA 5.
CONTEÚDO DA PASTA DA APLICAÇÃO HELLO WORLD ................. 22
FIGURA 6.
ARQUITETURA DO SYMBIAN OS ....................................................... 23
TABELA 1
COMPARAÇÃO DOS IDES DISPONÍVEIS PARA SYMBIAN ............... 27
LISTAGEM 2.
CONTEÚDO DO CÓDIGO-FONTE (HELLOTEXT.CPP)................... 28
LISTAGEM 3.
CONTEÚDO DO ARQUIVO BLD.INF ............................................... 28
LISTAGEM 4.
CONTEÚDO DO ARQUIVO HELLOTEXT.MMP ............................... 29
FIGURA 7.
HIERARQUIA NA COMPILAÇÃO DAS FONTES E RECURSOS ......... 30
FIGURA 8.
PLATAFORMAS DE DESENVOLVIMENTO JAVA ............................... 33
FIGURA 9.
CICLO DE VIDA DO MIDLET ............................................................... 38
FIGURA 10.
TELA DO WTK APÓS A CRIAÇÃO DO PROJETO HELLOWORLD ... 40
FIGURA 11.
ESTRUTURA DE DIRETÓRIOS CRIADA PELO WTK ........................ 41
LISTAGEM 5.
FIGURA 12.
CONTEÚDO DO ARQUIVO FONTE .JAVA ...................................... 42
EMULADOR DEFAULT DO WTK ........................................................ 43
LISTAGEM 6.
CONTEÚDO DO ARQUIVO DESCRITIVO .JAD............................... 44
FIGURA 13.
ARQUIVOS QUE DEVEM SER COPIADOS PARA O CELULAR ........ 44
FIGURA 14.
COMPARAÇÃO DOS MODELOS DA CLARO .................................... 45
FIGURA 15.
COMPARAÇÃO DOS MODELOS DA TIM........................................... 46
FIGURA 16.
COMPARAÇÃO DOS MODELOS DA VIVO ........................................ 46
FIGURA 17.
COMPARAÇÃO DAS TECNOLOGIAS DISPONÍVEIS NO MERCADO 47
TABELA 2
COMPARAÇÃO ENTRE BREW, SYMBIAN E J2ME ............................ 49
LISTA DE SIGLAS
AEE -
Application Execution Environment
ANSI -
American National Standards institute
API -
Application Programming Interface
ARM -
Advanced RISC Machines
ASIC -
Application-specific integrated circuit
AWT -
Abstract Windowing Toolkit
BID -
BREW Class ID
BREW - Binary Runtime Environment Wireless
CDC -
Connected Device Configuration
CDMA - Code Division Multiple Access
CGF -
Connection Generic Framework
CLDC - Connected, Limited Device Configuration
CPU -
Central Processing Unit
DLL -
Dinamic Link Library
DNS -
Domain Name System
EDGE - Enhanced Data rates for GSM Evolution
EMS -
Enhanced Messaging Service
FTP -
File Transfer Protocol
GPRS - General Packet Radio Service
GPS -
Global Positioning System
GSM -
Global System for Mobile communication
GUI -
Graphical User Interface
HSCSD – High-Speed Circuit-Switched Data
HTTP - Hypertext Transfer Protocol
HTTPS - Hypertext Transfer Protocol Scheme
IDE -
Integrated Development Environment
IMAP4 - Internet Message Access Protocol
J2ME - Java 2 Micro Edition
J2SE -
Java 2 Standard Edition
JVM -
Java Virtual Machine
MHTML – MIME Hypertext Transfer Protocol
MIDP - Mobile Information Device Profile
MIF -
Module Information Files
MMS -
Multimedia Message Service
MSMTM - Mobile Station Modem
MVC -
Model View Controller
OEM -
Original Equipment Manufacturer
OTA -
Over The Air
OO -
Orientação a Objeto
PDA -
Personal Digital Assistant
POP3 - Post Office Protocol version 3
PPP -
Point-to-Point Protocol
RTT -
Round-Trip delay Time
SDK -
Software development kit
SMS -
Short Message Service
SMTP - Simple Mail Transfer Protocol
SSL -
Secure Socket Layer
TCP -
Transmission Control Protocol
TDMA - Time Division Multiple Access
UDP -
User Datagram Protocol
USB -
Universal Serial Bus
WAP -
Wireless Application Protocol
WORA - Write Once, Run Anywhere
WTK -
Wireless ToolKit
WTLS - Wireless Transport Layer Security
9
1. INTRODUÇÃO
A escolha da tecnologia que melhor se adeqüa ao desenvolvimento de uma aplicação
para dispositivos computacionais móveis, considerando as tecnologias disponíveis, é uma
questão muito complexa. O interesse do mercado pela utilização de softwares em
dispositivos computacionais móveis, tais como celulares e PDAs (Personal Digital Assistent)
vem crescendo exponencialmente nos últimos anos.
Márcio Venzi, gerente de Desenvolvimento de Negócio da Nokia (Nokia, 2004) diz que
a empresa comercializará, durante todo o ano de 2004, cerca de 100 milhões de aparelhos
celulares com suporte a tecnologia Java, sendo que em julho, o Brasil contava com 55,25
milhões de usuários de telefônica celular. Segundo o IDG Brasil (IDGNow, 2004), a
plataforma Java opera em mais de 350 milhões de aparelhos, enquanto o Symbiam OS tem
dois terços do mercado de smartphones.
Com esta análise comparativa, deseja-se obter informações sobre as tecnologias
disponíveis para o desenvolvimento de tais software. De modo a orientar coerentemente a
escolha de qual tecnologia utilizar conforme as características do problema e dos
dispositivos a serem usados.
BREW (Binary Runtime Enviroment for Wireless) foi criado pela Qualcomm para ser
uma completa plataforma de desenvolvimento e distribuição de aplicações para dispositivos
móveis. Tem como principal característica ser extremamente pequeno, o que possibilita ser
incluso em aparelhos com pouquíssimo poder de processamento. Entretando oferece uma
plataforma aberta e expansível para o desenvolvimento de aplicações. BREW foi
desenvolvida pensando nas limitações que essas máquinas possuem, por isso foi otimizada
ao máximo e pode rodar suas aplicações nativas ( em C/C++) como engines 3d, máquinas
virtuais Java com uma excelente performance.
J2me (Java 2 Micro Edition), é a versão de Java da Sun destinada a dispositivos com
recursos limitados de hardware tais como: PDAs, Telefones celulares entre outros.
Atualmente o J2ME consiste de um conjunto de "Profiles" ou perfis. Cada perfil é destinado
a uma categoria específica de devices, e consiste num conjunto mínimo de biblioteca de
classes que o determinado aparelho deve suportar.
Symbian OS é um avançado sistema operacional multitarefa licenciado pelas maiores
empresas de telefonia móvel do mundo. Foi projetado com as restrições dos aparelhos
móveis em mente e para suprir os requerimentos específicos dos modernos celulares 2G,
2.5G e 3G. Com isso o Symbian OS foi desenvolvido com: um mínimo de uso de memória,
um eficiente gerenciador de energia, suporte em tempo real para telefonia e para
transferência de dados.
10
2. BREW (BINARY RUNTIME ENVIRONMENT WIRELESS)
Os usuários de comunicação móvel atualmente querem mais recursos em seus
dispositivos móveis, que podem ser desde avançadíssimos PDAs integrados, até aparelhos
telefônicos móveis populares, de baixo custo e fáceis de usar. Embora tenha havido muito
entusiasmo em torno da possibilidade de se promover a tecnologia ASIC (ApplicationSpecific Integrated Circuit) de alta velocidade para incorporar a funcionalidade de novos
aplicativos, mesmo em dispositivos de baixo custo, o trabalho executado até aqui tem sido
bastante prejudicado por fatores de custo e tamanho relacionados à integração dos
sistemas operacionais de alta complexidade que parecem ser necessários para abrigar tais
aplicativos. Os dispositivos populares geralmente se caracterizam por soluções proprietárias
que suportam conjuntos específicos de serviços e interfaces. Embora a maioria desses
dispositivos compartilhe basicamente o mesmo ambiente, as camadas proprietárias acima
do ASIC desencorajaram o desenvolvimento de aplicativos genéricos que possam aproveitar
a oferta por parte de vários fabricantes de dispositivos.
A QUALCOMM tem aproveitado sua vasta experiência nas áreas de ASIC, dispositivos
móveis e aplicativos para microcomputadores para desenvolver o BREW. A missão do
BREW é oferecer um AEE (Application Execution Environment) eficiente, de baixo custo,
expansível e simples, concentrado especialmente no desenvolvimento de aplicativos que
possam ser portados sem dificuldades para praticamente todos os dispositivos portáteis. Ao
contrário das opções de alto desempenho oferecidas, desenvolvidas sobre sistemas
operacionais que exigem um volume substancial de memória, um processador de alta
velocidade e todo o hardware associado a tal, o BREW funciona nos tipos de dispositivos
que existem hoje em dia. Com o BREW, os desenvolvedores de aplicativos podem agregar
funcionalidade estendida até aos dispositivos de menor custo.
BREW não pode ser comparado a Java (até porque é possível criar um ambiente Java
rodando nele) nem a um sistema operacional completo como o Symbian. BREW busca ser o
mais simples possível, permitindo assim que seja suportado por telefones que não tem
capacidade de rodar um sistema operacional completo.
O sistema BREW é basicamente uma plataforma de execução de aplicativos aberta,
padronizada e extensível, que reside no dispositivo de comunicação móvel (QUALCOMM,
2004b).
A plataforma BREW fica diretamente sobre o software de sistema do chip, permitindo
aplicativos nativos em C/C++ rápidos e fáceis integração de navegadores, máquinas virtuais
baseadas em tecnologias Java e extensões como mecanismos de jogos em 3D,
analisadores de XML e passadores (“players”) de vídeo.
11
2.1. Arquitetura do BREW
O BREW oferece aos desenvolvedores de aplicativos um ambiente leve, porém rico,
que lhes permitem aproveitar os recursos atuais e futuros oferecidos pelo ASIC MSMTM
(Mobile Station Modem) da QUALCOMM. O ambiente de execução de aplicativos baseado
em objetos e totalmente extensível do BREW permite o desenvolvimento de applets e de
módulos compartilhados em C ou C++. Ao mesmo tempo, o BREW foi criado com o objetivo
de melhorar a eficiência e economizar a memória RAM dos dispositivos móveis.
O BREW suporta aplicativos (applets) e módulos compartilhados. Os applets e os
módulos são desenvolvidos como DLLs (Dinamic Link Library) independentes, sendo
carregados no Emulator em tempo de execução. Os módulos compartilhados incluem
funcionalidades como, por exemplo, APIs (Application Programming Interface) de jogos
avançadas, que podem ser usadas por diversos applets. Os applets e módulos do BREW
são desenvolvidos em um ambiente emulado, sob o Windows.
O BREW expõe um conjunto sofisticado de tecnologias de objetos, que proporcionam
aos desenvolvedores as seguintes vantagens:
•
Serviços de aplicativo que suportam um AEE simples, baseado em eventos.
•
Serviços básicos que suportam o acesso a arquivos, serviços de rede, memória e
tela.
•
Serviços avançados como, por exemplo, recursos gráficos melhorados, reprodução
de som, GPS (Global Positioning System) e serviços de voz.
•
Serviços de integração, que permitem ao desenvolvedor de aplicativos aproveitar
serviços como aqueles suportados por navegadores da Web.
A Figura 1 mostra como o BREW provê uma camada fina que suporta acesso a
software ASIC e OEM (Original Equipment Manufacturer) para dar suporte a applets e
módulos.
12
Figura 1. Arquitetura do BREW (QUALCOMM, 2002b)
2.1.1. Estrutura dos módulos e interfaces do BREW
O AEE do BREW oferece diversas categorias de serviços, inclusive diversas interfaces
com o AEE, tais como IShell, IDisplay e IMenuCtl. Cada interface encapsula um conjunto de
recursos e contém métodos que permitem que esses recursos sejam gerenciados. Os
módulos do BREW podem conter um ou mais applets ou classes. Classes são expostas
pelo módulo em tempo de execução, sendo carregadas e descarregadas conforme a
necessidade.
2.2. Vantagens do BREW
Algumas vantagens do AEE do BREW são:
•
O BREW é mais eficiente. Fica de forma leve “por cima” do software de sistema do
chip do aparelho telefônico, a plataforma BREW tem acesso a recursos em nível
de chip, o que permite que ele faça o download e a execução de aplicativos
diretamente no telefone. Alocando dinamicamente RAM para aplicativos à medida
que eles são executados e usando armazenamento e processamento locais
(cliente e cliente/servidor), a plataforma BREW otimiza a alocação de memória.
Isto permite que os recursos de gerenciamento de aplicativos do BREW tratem
13
todas as funções de execução local, bem como eventos de rede externos
(QUALCOMM, 2005).
•
O ambiente de aplicativos do BREW suporta uma arquitetura familiar dirigida por
eventos, semelhante à do Microsoft Windows, do Macintosh e do X-Windows do
UNIX.
•
Os applets do BREW podem ser adaptados para o idioma de diferentes países.
•
Todo o texto é gerenciado como Unicode e armazenado na maneira mais eficiente
suportada para o idioma selecionado. O BREW também provê suporte a formatos
de texto nativos específicos de OEMs.
•
Não é necessário se preocupar com drivers de dispositivos e estruturas de dados
de plataformas de baixo nível, pois todas as interações entre o aplicativo e a
plataforma do dispositivo ocorrem através de classes bem definidas.
•
Pode-se desenvolver módulos de maneira independente e em paralelo, reduzindo
assim o tempo de desenvolvimento e os problemas de integração.
•
Módulos podem ser integrados em nível de código-objeto, simplificando a tarefa de
se acrescentar módulos à plataforma BREW.
•
O BREW suporta o recebimento de mensagens SMS (Short Message Service)
direcionadas a aplicativos, bem como cotações de ações, e-mails resumidos e
informações atualizadas sobre o trânsito.
•
O BREW oferece classes básicas para interfaceamento com a plataforma do
dispositivo. As funções de dispositivo que os applets podem gerenciar e controlar
com essas classes incluem:
o
Serviços de shell
o
Tempo/temporizadores (obtenção de data e hora atuais; disparo e
interrupção de temporizadores e alarmes)
o
Notificações
o
Gerenciamento de memória
o
Gerenciamento de arquivos
o
Gerenciamento de bancos de dados
o
Rede e soquetes
o
HTTP (Hypertext Transfer Protocol)
o
Download e tarifação
o
Controles de interface com o usuário, incluindo os seguintes:
Diálogos
Controles de data
Controles de menu
14
Controles de texto
Controles de horário
Controles de texto estático
Controles de exibição
Imagens (exibição, transformação, animação)
Gráficos
o
Reprodução de som (reprodução de arquivos MIDI e MP3)
o
Sons (geração de sons de campainhas, alertas e reprodução de arquivos
de áudio)
o
Funções auxiliares de biblioteca padrão
Em versões futuras, as classes básicas serão estendidas de modo a oferecer serviços
como Bluetooth, GPS e telefonia.
2.3. Ambiente de Desenvolvimento
2.3.1. BREW SDK
O BREW SDK (Software Development Kit) é um conjunto de ferramentas e serviços
que permite aos desenvolvedores de aplicativos desenvolver e implantar de maneira rápida,
eficiente e econômica novos aplicativos para uma ampla variedade de dispositivos portáteis.
Este SDK pode ser baixado pelo site da qualcomm (QUALCOMM, 2004a). Ao fazer o
download das últimas versões do BREW SDK a instalação é iniciada automaticamente.
2.3.2. Componentes do BREW SDK
2.3.2.1. BREW AEE
O BREW AEE é um ambiente totalmente expansível de desenvolvimento e execução
de aplicativos baseado em objetos. Ele proporciona uma plataforma na qual pode-se
desenvolver applets e módulos compartilhados em C ou C++. Uma arquitetura familiar,
orientada por eventos (semelhante à do Microsoft Windows, Macintosh ou X-Windows)
melhora ainda mais sua facilidade de uso.
2.3.2.2. Emulator
O BREW Emulator, é a GUI (Graphical User Interface) de “frontend” que será utilizada
para carregar e testar seus applets. Diversas emulações de dispositivos pré-configuradas
15
são fornecidas. O usuário também pode criar suas próprias emulações de dispositivos
usando o Configurator.
2.3.2.3. Device Configurator
Para criar novos dispositivos ou editar configurações existentes, use o BREW Device
Configurator. Ele é útil para configurar recursos como as teclas do teclado e suas funções,
dimensões e resolução da tela e tamanho da memória.
2.3.2.4. Resource Editor
Para criar recursos para aplicativos, use o BREW Resource Editor. Pode-se usar os
mesmos arquivos de recursos no Windows e no dispositivo.
2.3.2.5. MIF Editor
O BREW MIF Editor, gera MIFs (Module Information Files), que contêm informações
específicas de applets e módulos, necessárias para carregar um applet.
2.3.2.6. DLLs do BREW
O BREW contém várias DLLs que expõem as classes básicas suportadas pelo BREW
no ambiente do Microsoft Windows. Como as DLLs usam o mesmo código desenvolvido
para o BREW, há pouca diferença entre o comportamento do aplicativo no BREW Emulator,
baseado no Windows, e em um dispositivo real.
2.3.2.7. DLLs Win-OEM
As DLLs Win-OEM provêem as camadas básicas necessárias para se emular o
comportamento de um dispositivo em uma plataforma Windows.
2.3.2.8. Arquivos de Cabeçalho do BREW
Os arquivos de cabeçalho do BREW contêm as definições de interfaces do BREW,
sendo usados para o desenvolvimento de applets. Cada interface do BREW tem um arquivo
de cabeçalho associado, e cada applet tem de conter o arquivo de cabeçalho de cada
interface utilizada por esse applet.
16
2.3.2.9. Suplementos do Visual Studio
Suplementos (“add-ins”) gratuitos do Microsoft Visual Studio automatizam algumas das
tarefas demoradas que um desenvolvedor precisa executar no Visual Studio para
desenvolver aplicativos BREW.
2.3.2.10.
Aplicativos de Exemplo
DLLs de aplicativos de exemplo e seu código-fonte, fornecidos com o SDK, incluem as
seguintes:
•
Calculadora
•
Agenda
•
Aplicativos de contagem de tempo (cronômetro, contagem regressiva, despertador)
•
Jogos
•
Bloco de notas
•
Reprodutor de arquivos MIDI-MP3
•
Aplicativos de uso (destinados a ilustrar como as interfaces do BREW podem ser
usadas)
2.3.2.11.
Documentação
Todo o conjunto de documentação do BREW pode ser acessado a partir do próprio
ambiente de desenvolvimento do BREW.
2.3.3. Editor de Código
O Microsoft Visual Studio, é um requisito de sistema que já precisa estar carregado no
Computador antes de instalar o BREW SDK. Se instalar o SDK antes de ter instalado o
Visual Studio, será necessário recarregar o SDK para que esses suplementos (“add-ins”)
tornem-se efetivamente operacionais.
O SDK inclui suplementos gratuitos que automatizam algumas das tarefas que um
desenvolvedor precisa executar no Visual Studio para desenvolver aplicativos BREW.
2.3.3.1. Assistente de Aplicativos do BREW
O assistente de aplicativos do BREW (BREW Application Wizard), subsequentemente
referido como AppWizard, pode orientar o desenvolvedor pelas tarefas muitas vezes
demoradas envolvidas na criação de um projeto de aplicativo BREW, inclusive a criação do
espaço de trabalho de projeto (project workspace) do Windows.
17
O AppWizard gera automaticamente o espaço de trabalho do projeto e todos os
arquivos que serão necessários para criar aplicativos BREW.
Além de economizar tempo e esforço, os arquivos criados pelo AppWizard são
altamente móveis. Pode-se mover o projeto de um local para outro do computador sem ter
de alterar o arquivo de projeto ou os caminhos informados nas instruções INCLUDE do
projeto.
2.3.3.2. Compilação ARM Automática
Após testar um aplicativo BREW no Emulator e estiver pronto para portá-lo para um
dispositivo real, será necessário a criação de um arquivo de geração (makefile, MAK) que
gera o aplicativo BREW para o dispositivo real, usando o compilador ARM (Advanced RISC
Machines). Geralmente, o arquivo de geração é usado a partir da linha de comando, para
realizar operações de geração e geração limpa (build clean). O suplemento de compilação
ARM automática permite realizar essas tarefas demoradas rapidamente, em questão de
segundos. Além disso, o suplemento automatiza a tarefa de localizar e corrigir erros durante
a compilação.
2.4. Metodologia de Implementação
2.4.1. Criação de Novos Aplicativos
A maneira mais simples e rápida de criar novos aplicativos é com o assistente de
aplicativos do BREW (BREW Application Wizard). O AppWizard guia através do processo de
criação de todos os componentes exigidos para o desenvolvimento bem-sucedido de um
aplicativo BREW.
2.4.2. Codificação do Sistema
Para a codificação do sistema, dentro do Visual C++, cria-se um novo arquivo “c++
source file”, onde será digitado todo o código-fonte da aplicação, a Listagem 1 possui o
código de um programa simples, apenas para exibição do tradicional “Hello World”.
/*===========================================================
INCLUDES AND VARIABLE DEFINITIONS
==========================================================*/
#include "AEEAppGen.h"
// Applet interface definitions
#include "helloworld.bid"
// applet class ID
18
/*----------------------------------------------------------Function Prototypes
----------------------------------------------------------*/
static boolean HelloWorld_HandleEvent(IApplet * pi,
AEEEvent
eCode,
uint16 wParam,
uint32 dwParam);
/*===========================================================
FUNCTION DEFINITIONS
==========================================================*/
int AEEClsCreateInstance(AEECLSID ClsId,
IShell * pIShell,
IModule * po,
void ** ppObj) {
*ppObj = NULL;
if(ClsId == AEECLSID_HELLOWORLD){
if(AEEApplet_New(sizeof(AEEApplet),
ClsId, pIShell,po,(IApplet**) ppObj,
(AEEHANDLER)HelloWorld_HandleEvent,NULL)
== TRUE)
{
return (AEE_SUCCESS);
}
}
return (EFAILED);
}
static boolean HelloWorld_HandleEvent(IApplet * pi,
AEEEvent eCode,
uint16 wParam,
uint32 dwParam) {
AECHAR szBuf[] = {'H','e','l','l','o',' ',
'W','o', 'r',
'l', 'd', '\0'};
AEEApplet * pMe = (AEEApplet*)pi;
switch (eCode)
{
case EVT_APP_START:
// Display string on screen
IDISPLAY_DrawText(pMe->m_pIDisplay,
AEE_FONT_BOLD, szBuf, -1, 0, 0,
0, IDF_ALIGN_CENTER | IDF_ALIGN_MIDDLE);
IDISPLAY_Update (pMe->m_pIDisplay);
return(TRUE);
case EVT_APP_STOP:
return TRUE;
default:
break;
19
}
return FALSE;
}
Listagem 1.
Código-fonte
Após a codificação do programa, resta fazer a compilação, que pode ser utilizada a do
próprio Visual C++. Com a compilação, será gerado a DLL do applet helloworld.
Agora, é necessário criar o arquivo MIF para que seja possível executar o aplicativo no
emulador.
2.4.3. Classes do BREW e MIFs
Cada módulo do BREW contém uma ou mais classes do BREW. Essas classes
podem ser applet ou não-applet, sendo identificadas por IDs de classe (ClassIDs). As
classes de applet podem ser executadas pelo usuário do dispositivo, ao passo que as
classes não-applet podem implementar serviços usados pelas classes de applet do módulo.
Esses serviços também são disponibilizados para classes de outros módulos.
O MIF contém IDs de classe exclusivas para cada uma das classes do módulo e
especifica quais classes são exportadas, para uso por outros módulos. Para cada classe de
applet, o MIF contém uma string de texto e um ou mais ícones gráficos que são usados para
exibir o applet no menu de applets disponíveis para execução. O MIF contém outras
informações que determinam o nível de privilégios do módulo (as funções da API do BREW
que podem ser chamadas pelas classes do módulo) e as notificações que o módulo pode
receber de outras classes do BREW.
Em um dispositivo habilitado para o BREW, os MIFs são armazenados em uma pasta
que contém um diretório para cada módulo. O nome do diretório do módulo corresponde ao
prefixo do nome do MIF. Por exemplo, os arquivos de um módulo cujo MIF se chame
app.mif seriam armazenados em um diretório de nome app. Quando o applet é executado
no Emulator, cada módulo pode ter diversos MIFs, um para cada profundidade de cores do
dispositivo sendo emulada. Como os MIFs contêm elementos gráficos, é possível selecionar
imagens feitas sob medida para as capacidades da tela de cada tipo de dispositivo e
armazená-las em MIFs separados. O Emulator permite que o diretório de MIFs seja
selecionado de forma independente em relação ao diretório que contém os módulos
executáveis, o que facilita emular a execução de um applet em diversos dispositivos.
20
Figura 2. O MIF no BREW SDK
A Figura 2 mostra o relacionamento entre o MIF Editor e as outras ferramentas do
BREW SDK. Ela ilustra como um módulo do BREW, de nome app, é emulado em um
dispositivo definido pelo arquivo de configuração dev.qsc.
Para criar um MIF para o módulo BREW, é necessário em primeiro lugar obter um
arquivo BID (BREW Class ID) para cada classe e applet que o módulo contém. Pode-se
obter IDs de classes no site da Web do BREW.
Cada arquivo BID contém uma ID de classe de 32 bits única e atribui a ela um nome
(por exemplo, AEECLSID_APP). As IDs de classe são armazenadas no MIF e os arquivos
BID são incluídos no arquivo-fonte do módulo (por exemplo, app.c). Isto permite que o
módulo crie uma instância de qualquer uma de suas classes, dada uma ID de classe
fornecida pelo AEE do BREW (Figura 3).
É possível criar múltiplos MIFs, com imagens para telas de dispositivos diferentes. O
código-fonte do módulo é compilado e ligado para produzir o executável do módulo, isto é,
app.dll para o Emulator e app.mod para o dispositivo de destino.
Figura 3. BREW MIF Editor
21
2.4.4. Execução do Aplicativo no Emulador
Quando o Emulator é executado, ele abre a imagem do dispositivo definido no arquivo
de configurações do dispositivo (.qsc). O Emulator pesquisa o diretório de MIFs especificado
e mostra uma lista de todos os applets com MIFs desse diretório. Os MIFs contêm ícones
para cada applet.
Quando seleciona-se um applet da lista, o Emulator carrega o DLL do applet e o
executa, mostrando sua tela inicial na tela do dispositivo (Figura 4). É possível clicar nas
teclas do dispositivo para fornecer entrada ao applet e observar seu comportamento,
inclusive sua saída na tela do dispositivo.
Figura 4. BREW Emulator
2.4.5. Transferência do Aplicativo para o Celular
Quando o aplicativo estiver pronto para ser portado para um dispositivo real, é
necessário criar um arquivo de geração (makefile) que gera o aplicativo BREW para o
dispositivo real, usando o compilador ARM. Geralmente, o arquivo de geração é usado a
partir da linha de comando, para realizar operações de geração e geração limpa (build
clean). O suplemento de compilação ARM automática permite realizar essas tarefas
demoradas rapidamente, em questão de segundos.
Para criar um arquivo de geração (makefile) para o aplicativo
22
1. Carregar o aplicativo no espaço de trabalho do Visual Studio.
2. Clicar no botão Generate ARM Makefile da barra de ferramentas para criar o
arquivo de geração.
Abre-se uma caixa de mensagem, que informa que o arquivo de geração foi criado.
Para compilar um aplicativo usando o arquivo de geração
Selecionar Tools > ARM make.
A janela de saída é aberta e mostra os arquivos criados pela compilação.
Figura 5. Conteúdo da pasta da aplicação Hello World
A Figura 5, demonstra os arquivos que são criados após todo o processo de geração
da aplicação.
23
3. SYMBIAN
O Symbian OS é um sistema operacional projetado especificamente para o ambiente
móvel, preenchendo os requisitos dos aparelhos das gerações 2.5 e 3 de celulares. Ele é
composto por uma kernel multi-tarefa, suporte integrado à telefonia, protocolos de
comunicação, gerenciamento de dados, suporte a gráficos avançados, interface com o
usuário de baixo nível e uma variedade de algoritmos para aplicações. Esse sistema
operacional é muito utilizado em aparelhos mais poderosos, os chamados smartphones e
communicators (IIDA, 2005).
Para o desenvolvedor o Symbian OS fornece um completo e aberto framework de
desenvolvimento, utilizando a linguagem C++, que possibilita o desenvolvimento de
aplicativos utilizando-se de recursos do aparelho como câmera, telefonia, etc.
O Symbian OS, é formado por um consórcio de empresas, desenvolvida a partir da
Psion Software, a princípio pelas empresas Nokia, Motorola, Psion, Ericsson, Panasonic e
Siemens.
3.1. Arquitetura do Symbian OS
A Figura 6, demonstra como é formada a arquitetura do Symbian.
Figura 6. Arquitetura do Symbian OS (BORGES, 2005)
Base (núcleo do sistema operacional)
•
User library, File server, Kernel, Device driver
24
Telefonia
•
GSM, GPRS (General Packet Radio Service), HSCSD (High-Speed CircuitSwitched Data), EDGE (Enhanced Data rates for GSM Evolution) e CDMA (Code
Division Multiple Access)
Segurança
•
Criptografia, gerenciador de certificado, instalação de software
Comunicação
•
TCP (Transmission Control Protocol), dual Ipv4 e v4, UDP(User Datagram
Protocol), HTTP, FTP(File Transfer Protocol), WAP
Multimídia
•
Imagens, sons e graficos (3D e 2D)
Personal Área Network
•
Bluetooth, infravermelho, USB (Universal Serial Bus)
Application Framework
•
Framework de interface gráfica com o usuário e utilitários de textos e gráficos
Mensagem
•
SMS, EMS (Enhanced Messaging Service), MMS (Multimedia Message Service),
email e fax
Application engines
•
Contatos, agenda, office, syncML, gerenciamento de dados e browsing
3.2. Recursos
3.2.1. Principais Funcionalidades
O Symbian OS é a base da próxima geração de celulares. Ele possui um conjunto de
APIs e tecnologia que são compartilhados por todos os telefones que possuem o Symbian
OS. As principais funcionalidades do Symbian OS, são:
•
Rico conjunto de “application engines”: Contatos, calendário, mensagem,
navegação entre outros utilitários;
•
Navegação Web;
•
Mensagem: Mensagem multimídia, mensagem com figuras, mensagem de texto,
email usando POP3 (Post Office Protocol version 3), IMAP4 (Internet Message
Access Protocol), SMTP (Simple Mail Transfer Protocol), MHTML(MIME Hypertext
Transfer Protocol) e fax;
25
•
Multimídia: Fontes, imagens, gravação e reprodução de áudio (suporte para todos
os formatos padrões de som e imagem);
•
Protocolos de Comunicação: TCP, IPv4, IPv6, WAP incluindo infravermelho,
Bluetooth e USB;
•
Suporte a localidade internacional: caracteres unicode nativo, framework de
entrada de texto flexível;
•
Sincronização de dados: pelo ar (OTA – over the air) suporta sincronização usando
SyncML DataSync. O PC connectivity toolkit, suporta link serial, infravermelho,
Bluetooth e USB;
•
Segurança: HTTPS (Hypertext Transfer Protocol Scheme), WTLS(Wireless
Transport Layer Security) e SSL(Secure Socket Layer);
3.2.2. Framework
Este framework possibilita o desenvolvimento de aplicações genéricas, que funcionem
em diferentes tipos de telefones, independente das diferentes implementações da interface
com o usuário utilizada pelos fabricantes licenciados. Suas principais características são:
•
Executar aplicações com processos separados (multi-tarefas);
•
Associar um documento de uma aplicação com o ícone da aplicação;
•
Reconhecimento de tipos de arquivos (MIME-TYPE);
•
Plug-in que podem ser adicionados ou removidos pelo usuário;
•
Provê um mecanismo genérico de tratamento de erro;
•
Agendamento de tarefa.
3.2.3. Infraestrutura de Comunicação
•
TCP;
•
UDP;
•
PPP (Point to Point Protocol);
•
DNS (Domain Name System);
•
FTP;
•
HTTP 1.1;
•
Bluetooth;
•
Infravermelho;
•
USB.
26
3.2.4. Telefonia
O Symbian suporta alguns tipos de rede de telefonia incluindo GSM, GPRS, EDGE,
CDMA (IS-95) e 3GPP2 cdma2000 1x.
A API responsável pelo tratamento destas redes de telefonia provê algumas
funcionalidades comuns para todas as redes, como por exemplo:
•
Informações do Celular e da Rede: recuperar a força do sinal e o nível de carga da
bateria, acesso ao nome e outras informa da rede detectada pelo telefone;
Existem também, várias funcionalidades que estão disponíveis para cada tipo de rede
em particular.
3.3. Conhecimentos Necessários
Para se desenvolver aplicativos para celular utilizando a tecnologia Symbian, é
necessário possuir alguns conhecimentos prévios, conforme segue:
•
Conhecer e possuir experiência com C++;
o
OO (Orientação a Objeto)
o
Templates
o
Namespaces
o
Macros (ANSI C)
o
Sobrecarga de operadores (new)
•
Multithreading/ClientServer programming
•
Design Patterns, principalmente o MVC (Model View Controller) e o Adapter (GoF)
•
Memory Management e Optimization Techniques
3.4. Ambiente de Desenvolvimento
Geralmente os próprios fabricantes fornecem kits de desenvolvimento.
A
utilização
de
um
IDE
(Integrated
Development
Environment)
facilita
o
desenvolvimento principalmente em fase de debug. Os principais IDEs que se integram aos
kits de desenvolvimento do Serie 60 juntamente com suas vantagens e desvantagens estão
detalhadas na tabela 1.
IDE
Microsoft Visual C++ 6
Vantagens
Rápida; compilação e debug
eficiente; algumas
ferramentas para symbian os
disponíveis
Rápida; moderna e boa IDE
Microsoft Visual Studio
.net
Metrowerks Code Warrior Symbian OS está
Desvantagens
Antiga; sem suporte real para
o desenvolvimento de código
Symbian OS
Sem suporte direto pelo
Symbian OS SDK;
Não muito barata; IDE
27
Borland C++ BuilderX
Móbile Edition
Eclipse
Tabela 1
parcialmente integrado
Suporte visual para desenho
dos menus e dialogos;
Associa algumas
funcionalidados do Symbian
OS; atualmente é free
IDE muito boa; free
complicada
Lenta; desajeitada
Sem suporte a debug; não é
completamente integrada ao
Symbian OS
Comparação dos IDEs disponíveis para Symbian
Além da IDE, é necessário a instalação do SDK, no fórum nokia (NOKIA, 2004a) pode
ser feito o download do Series 60 SDK 1.2 for Symbian OS, juntamente com este SDK, são
instalados:
•
Java 2 Runtime Enviroment (JRE)
•
Ambiente Perl (Perl Environment)
3.5. Metodologia de Implementação
Um projeto de desenvolvimento em Symbian é composto por vários arquivos, além
dos arquivos com o código fonte. Os principais arquivos são bld.inf e .mmp.
Resumidamente, eles são usados para direcionar a compilação, de forma similar ao
makefile encontrado nos sistemas operacionais UNIX. Existem outros arquivos que são
muito importantes para o desenvolvimento de interfaces gráficas.
3.5.1. Codificação do Sistema
Para a codificação do sistema, dentro do Visual C++, cria-se um novo arquivo “c++
source file”, onde será digitado todo o código-fonte da aplicação, a Listagem 2 possui o
código de um programa simples, apenas para exibição do tradicional “Hello World”.
//hellotext.cpp
#include <e32base.h>
#include <e32cons.h>
LOCAL_D CconsoleBase* gConsole
//Função Main – Arqui se encontra a lógica do programa.
void MainL()
{
gConsole->Printf(_LIT(“Hello World\n”));
}
//Controle do Console
void ConsoleMainL()
{
//cria um console
28
gConsole = Console::New(_LIT(“Hello Text”),
Tsize(KconsFullScreen, KconsFullScreen));
CleanupStack::PushL(gConsole);
//Chama a função Main
MainL();
//Pausa a aplicação
User::After(5000000);
//Tira o console da Cleanup Stack e destrói
CleanupStack::PopAndDestroy(gConsole);
}
//Controle da Cleanup stack
GLDEF_C Tint E32Main()
{
__UHEAP_MARK;
CtrapCleanup* cleanupStack = CtrapCleanup::New();
TRAPD(error, ConsoleMainL());
__ASSERT_ALWAYS(¡error, User::Panic(_L(“SCMP”), error));
delete cleanupStack;
__UHEAP_MARKEND;
return 0;
}
Listagem 2.
Conteúdo do código-fonte (hellotext.cpp)
3.5.2. Definição de Componentes
O bld.inf é um descritor de componentes (Listagem 3). Basicamente, ele indica para o
ambiente de desenvolvimento como criar o script de compilação (por exemplo, quais
especificações de projeto devem ser usadas para criar os arquivos na construção da
aplicação desejada).
//BLD.inf
PROJ_MMPFILES
Hellotext.mmp
Listagem 3.
Conteúdo do arquivo bld.inf
3.5.3. Especificação do Projeto
O arquivo de especificações de projeto (.mmp) define as propriedades dos
componentes de projeto de uma forma independente de plataforma e compilador (Listagem
4). Junto com o bld.inf, é usado pelo ambiente de desenvolvimento para criar o script de
compilação da sua aplicação.
//hellotext.mmp
29
TARGET HelloText.exe
TARGETTYPE exe
UID 0
// O codigo fonte
SOURCEPATH .
SOURCE helloptext.cpp
USERINCLUDE .
SYSTEMINCLUDE /epoc32/include
// As bibliotecas
LIBRARY euser.lib
Listagem 4.
Conteúdo do arquivo hellotext.mmp
3.5.4. Tipos de Aplicação
O Symbian OS define algumas formas diferentes de compilação dos códigos-fontes.
Estes são ligeiramente diferentes dos encontrados no C++ para aplicações desktop. Os
mais usados são:
•
EXE (.exe): um programa com um único ponto de entrada E32Main(). A interface
com o usuário é limitada a uma janela de console (algo similar ao DOS). Um
detalhe deste tipo de aplicação é que não aparece no menu do celular, sendo
necessária outra aplicação para inicia-la.
•
Dinamic Link Library (.dll): uma biblioteca de códigos com vários pontos de
entrada. DLL’s são carregadas por outros programas.
•
Application (.app): programas com uma interface gráfica com o usuário. Esta
aplicação instala um ícone no menu do celular, podendo ser iniciada diretamente.
Este tipo aplicação é definido no arquivo de Especificação do projeto no item
TARGETTYPE.
3.5.5. Compilação do Projeto
Para compilar e gerar um executável serão necessários os três arquivos mostrados
anteriormente, situados no mesmo diretório (Figura 7).
Todos os comandos mostrados abaixo devem ser executados numa janela do DOS.
1. Gerar o arquivo abld.bat: Este arquivo contém as diretrizes para a
compilação.
Bldmake bldfiles
2. Construir o executável: Este comando gerará o arquivo Hellotext.exe
dentro
da
pasta
do
symbian,
para
utilização
pelo
emulador
(c:\symbian\series60_1_2_b/ epoc32/release/winsb/udeb/hellotext.exe).
Abld build winsb udeb
30
3. Gerar arquivo de instalação: Este comando gera cria o arquivo hellotext.sis
no mesmo diretório do código-fonte e que pode ser transferido para o celular
e instalado.
Makesis hellotext.pkg
Figura 7. Hierarquia na compilação das fontes e recursos
3.5.6. Instalação do Aplicativo para o Celular
Para instalar o aplicativo no celular é necessário primeiro gerar um executável
compatível com o dispositivo real. Para isso, siga os seguintes passos:
1. Gerar o arquivo abld.bat: Este arquivo contém as diretrizes para a
compilação.
Bldmake bldfiles
2. Construir o executável: Este comando gerará o arquivo Hellotext.exe dentro
da pasta do Symbian OS, para futura cópia no dispositivo real
Abld build armib urel
3. Gerar arquivo de instalação: Este comando gera cria o arquivo hellotext.sis
no mesmo diretório do código-fonte e que pode ser transferido para o celular
e instalado.
31
Makesis hellotext.pkg
32
4. J2ME (JAVA 2 MICRO EDITION)
A miniaturização dos dispositivos eletrônicos, o aumento do poder de processamento
destes dispositivos aliado a necessidade do ser humano permanecer informado a qualquer
hora e em qualquer lugar foi um dos motivos da grande popularização dos aparelhos
celulares, hoje são mais de um bilhão de telefones celulares no mundo e esse número
cresce a cada dia. Os aparelhos celulares mais modernos podem rodar aplicativos até então
existente apenas em computadores e com certeza os usuários vão querer estes aplicativos,
a questão é: quem irá desenvolvê-los? Vista esta grande oportunidade, gigantes da
informática estão investindo cada vez mais nesta área, um exemplo é a Sun Microsystem
que desenvolveu uma versão de sua plataforma de desenvolvimento, Java, exclusivamente
para dispositivos móveis como celular, o nome dado foi J2ME. O Java se destaca de outras
linguagens de programação, pois dispõe de recursos de Orientação a Objetos, permitindo
desenvolver códigos portáveis, reusáveis e robusto. A plataforma de desenvolvimento Java
possibilita desenvolver aplicativos para qualquer dispositivo, desde SmartCard’s, passando
por celulares e computadores até grande servidores, desde que o mesmo disponha uma
máquina virtual Java (JVM), este recurso possibilita que o mesmo programa rode em várias
plataformas, garantindo com isso o que o Java considera sua principal vantagem, a WORA
(Write Once, Run Anywhere) (SUN, 2002).
Também não existem limitações em relação à operadora de telefonia celular ou à
tecnologia adotada por ela. Existem telefones celulares com máquina virtual Java para
quaisquer das tecnologias mais utilizadas atualmente (GSM/GPRS, CDMA/1.xRTT, TDMA
etc). Para que o aplicativo possa ser executado no celular, não é necessária qualquer
licença especial da operadora ou sequer a sua ciência.
Hoje muitas empresas fabricantes de celulares vêem grandes vantagens e
oportunidades na tecnologia Java, tanto que praticamente todos os modelos de celulares da
Nokia fabricado hoje já dispõe da Maquina Virtual Java, para que possam ser instalados
aplicativos desenvolvidos nesta plataforma.
33
4.1. Arquitetura do J2ME
Figura 8. Plataformas de desenvolvimento Java (SUN, 2002)
O J2ME é dividido entre Configurations, Profiles e APIs Opcionais (Figura 8). Essa
divisão permite ao desenvolvedor conhecer informações específicas sobre as diferentes
famílias de dispositivos e as APIs disponíveis para cada uma delas.
34
4.1.1. Configurations
A Configuration define o mínimo que um desenvolvedor pode esperar do dispositivo,
classificando-os por capacidade de memória e processamento. Especifica uma JVM que
pode ser portada entre dispositivos e também determina um subconjunto das APIs da J2SE
a serem utilizadas, além de outras APIs adicionais necessárias. Entre as configurações
disponíveis destacam-se a CDC (Connected Device Configuration) e a CLDC (Connected,
Limited Device Configuration).
A especificação CDC é baseada na máquina virtual Java convencional, definindo um
ambiente com um conjunto rico de recursos, semelhantes aos encontrados em um sistema
desktop. Destina-se a dispositivos wireless de alta capacidade, set-top boxes de TVs a
cabo, sistemas automotivos e outras plataformas que possuam pelo menos alguns
megabytes de memória disponível.
Principais características e restrições:
•
Implementação completa da JVM tradicional.
•
512 KB (mínimo) de memória (ROM) para rodar Java.
•
256 KB (mínimo) de memória (RAM).
•
Conectividade de rede, possivelmente persistente e de alta velocidade.
•
Processadores de 32 bits;
•
Mais de 2MB de memória total para o armazenamento da máquina virtual e
bibliotecas de classe.
•
Interface com usuário com variado grau de sofisticação.
A CLDC, por outro lado, consiste em uma máquina virtual reduzida (KVM) e um
conjunto de classes mais apropriado para dispositivos pequenos e com limitações de
desempenho e memória. Esta configuração é destinada para dispositivos wireless menores,
possuindo geralmente entre 160Kb e 512 Kb disponíveis para Java.
Principais características e restrições:
•
128 KB (mínimo) de memória (ROM) para rodar Java.
•
32 KB (mínimo) de memória (RAM).
•
Interface do usuário limitada.
•
Baixa potência de bateria.
•
Conectividade de rede, tipicamente sem fio, com baixas velocidades (9600bps ou
menos) e acesso não-contínuo.
•
Processador de no mínimo 16 bits com baixo consumo (adequado a baterias
típicas de um celular).
35
4.1.2. Profiles
Os perfis são conjuntos de APIs que suplementam as Configurations, fornecendo
funcionalidades para um determinado tipo de dispositivo ou mercado vertical. São mais
específicos que as configurações, apesar de serem baseados nelas. Adicionam APIs para
interface com o usuário, armazenamento persistente e outras auxiliares. O profile utilizado
em celulares é a MIDP (Mobile Information Device Profile), com o Foundation Profile sendo
utilizado em dispositivos de rede sem interface gráfica.
As principais exigências da MIDP 1.0 são:
•
128Kb de memória não-volátil para a implementação MIDP;
•
32Kb de memória volátil para o heap de runtime;
•
8Kb de memória não-volátil para persistência de dados;
•
Tela com pelo menos 96 x 54 pixels;
•
Algum tipo de entrada de dados.
No quesito de segurança, o MIDP 1.0 é semelhante às applets, com o conceito de
uma sandbox, onde o programa Java é mantido seguro, sem acesso ao ambiente externo.
No MIDP 2.0, as aplicações possuem um tratamento de segurança baseado em permissões
semelhantes à J2SE.
4.1.3. APIs Ocionais
As APIs opcionais são funcionalidades adicionais específicas que não serão
encontradas em todos os dispositivos de uma determinada configuração ou perfil, mas
importantes o suficiente para serem padronizadas.
Segue abaixo alguns exemplos de apis opcionais:
•
Mobile Media API (JSR-135)
•
Personal Profile (JSR-46)
•
FileConnection and PIM API (JSR-75)
•
Bluetooth API (JSR-82 No OBEX)
•
Wireless Messaging API (WMA); JSR 120, JSR 205
•
Mobile Media API (MMAPI); JSR 135
4.2. Recursos e Limitações Existentes
4.2.1. Configurações (CLDC)
O CLDC possui atualmente duas versões, sendo elas: CLDC 1.0 e CLDC1.1
36
4.2.2. CLDC 1.0
Restrições de Hardware:
•
128 KB para executar a JVM e as bibliotecas CLDC (memória não-volátil).
•
32 KB para executar a aplicação Java (memória volátil).
Restrições de Software:
•
Sistema Operacional deve ser capaz de executar a JVM e gerenciar a aplicação
Java (“load and remove”).
•
A linguagem Java utilizada nos dispositivos CLDC difere em alguns aspectos da
especificação oficial.
•
Sem suporte a finalização (Object.finalize());
•
Suporte limitado a erros. Apenas três classes de erros são utilizadas:
•
o
java.lang.Error
o
java.lang.OutOfMemoryError
o
java.lang.VirtualMachineError.
Não há suporte a JNI (Java Native Interface), por questões de segurança e
performance;
•
Não
há
suporte
para
ClassLoaders
personalizados.
O
ClassLoader
da
implementação é final, não havendo sobrecarga para especializações;
•
Não há suporte para reflexão (reflection) por questões de performance. E por
conseqüência não há suporte para serialização de Objetos;
•
Não há suporte para Daemon Thread e ThreadLocal. Apesar de suportar
multithreading (limitado), os sistemas devem simular estas funcionalidades não
suportadas;
•
Não há suporte para referências fracas (Weak References).
4.2.3. CLDC 1.1
Melhorias
•
Suporte a dados do tipo real (float);
•
Implementação das classes Float e Double;
•
Melhorias no tratamento de erros;
•
Maior compatibilidade nas classes Date, TimeZone e Calendar;
37
4.2.4.
Perfis
O MIDP também possui atualmente duas versões, sendo elas: MIDP 1.0 e MIDP 2.0.
Características
•
Disponibiliza um conjunto de classes e interfaces para representar os elementos
gráficos;
•
Armazenamento de dados persistentes;
•
Conexão de rede baseado no HTTP 1.1 utilizando-se o CLDC CGF (Connection
Generic Framework).
•
Recursos aprimorados para implementação de jogos (somente na versão 2.0)
•
Controle de Imagem e Som (somente na versão 2.0)
Restrições de hardware
•
A tela deve suportar a resolução mínima de 96 x 54 pixels;
•
Deve existir pelo menos um tipo de entrada disponível;
•
128 KB para executar os componentes MID (memória não-volátil);
•
32 KB para executar a aplicação Java (memória volátil);
•
Pelo menos 8 KB para armazenar dados persistentes da aplicação Java;
•
Conectividade com redes sem fio.
Restrições de software
•
Sistema Operacional (S.O) deve rodar a JVM com suporte a tratamento de exceção,
escalonamento e interrupção de processos;
•
S.O. deve oferecer suporte a escrita de gráficos bitmap na tela;
•
S.O. deve aceitar a entrada de dados e redirecioná-la para a JVM.
Ciclo de vida
O Application Manager (AM) de cada dispositivo é quem vai controlar os aplicativos a
serem instalados, onde e como serão armazenados e como serão executados.
Assim que a MIDlet é invocada, o AM invoca 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, ocorre o mesmo com o 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().
38
Paused
•
Inicializado e esperando
Active
•
Possui recursos e está executando
Destroyed
•
Liberou todos os recursos
•
Destruiu todas as threads
•
Finalizou as atividades
Figura 9. Ciclo de Vida do MIDlet
A Figura 9, ilustra a comunicação entre três estados do ciclo de vida do MIDlet.
4.3. Conhecimentos Necessários
Para se desenvolver aplicativos para celular utilizando a tecnologia J2ME, é
necessário conhecimento prévio da tecnologia Java, ter um conhecimento bom da
Orientação a Objetos dentro da plataforma e um conhecimento prévio das principais classes
existentes no Java. Conhecimentos sobre a interface gráfica do Java (principalmente AWT)
podem ajudar bastante no momento de desenvolver o layout do programa.
4.4. Ambiente de Desenvolvimento
4.4.1. O JDK
O JDK é o Kit de Desenvolvimento Java do J2SE (Standard Edition), utilizada na
maioria das vezes para o desenvolvimento desktop, porém para todo o desenvolvimento de
aplicações Java é necessário instalar essa ferramenta. É possível baixar a ultima versão do
JDK no site da sun (SUN, 2005b), embora para desenvolver programas para celular exista o
39
J2ME que possuí a API MIDlet e uma grande quantidade de classes utilizadas neste tipo
desenvolvimento, é necessário instalar também o JDK que disponibiliza classes e recursos
essenciais da própria tecnologia Java, como tratamento de datas, classes de I/O entre
outros recursos básicos para qualquer desenvolvimento.
Também é aconselhável baixar a documentação do J2SE, pois pode ser muito útil
para posteriores consultas. A documentação tem aproximadamente 33 MB e está disponível
para download no mesmo link do SDK, mostrado anteriormente. A documentação está num
arquivo compactado, é necessário descompactar preferencialmente na pasta onde será
instalado o SDK.
O SDK possui aproximadamente 50 MB, é necessário baixar o arquivo executável e
em seguida se faz o processo de instalação padrão do Windows, a instalação é muito fácil,
segue passo a passo a instalação sem precisar nenhuma configuração adicional.
4.4.2. Ferramenta de Desenvolvimento para Celular WTK
O WTK (Wireless ToolKit) é fornecida pela Sun para o desenvolvimento de aplicativos
para celular J2ME. Ele dispõe de compilador e emulador do aparelho celular, nele é possível
configurar a velocidade da CPU do aparelho e o fluxo de rede, para que a emulação seja a
mais próxima possível do real, já que computadores possuem muito mais memória e
Processador e nem sempre o desenvolvedor dispõe do aparelho celular para instalar e
testar o aplicativo.
Para conseguir a instalação do WTK basta acessar o site da Sun (SUN, 2005c) e fazer
o download da ferramenta. Essa ferramenta não ocupa mais que 10MB.
A instalação do WTK também instala a documentação do J2ME, muito útil para
aprender ou consultar classes disponíveis no Micro Edition. Ele é padrão Javadoc, ou seja,
no mesmo formato da documentação J2SE, instalado anteriormente.
O processo de instalação do WTK também é muito simples, sem a necessidade de
configurações adicionais.
4.4.3. Editor de Código
A escolha de um bom editor de código pode facilitar muito o trabalho de codificação,
um dos editores mais difundidos entre usuários que estão aprendendo a tecnologia Java a é
o Gel, pela sua facilidade de trabalho e alguns recursos um pouco mais avançados, que
facilita muito a codificação. O Gel é uma IDE de desenvolvimento feito para Windows, logo
se for necessário utilizar uma plataforma livre para o desenvolvimento, como o Linux, será
necessário optar por editores como o Eclipse ou NetBeans.
40
O processo de instalação do Gel é simples, porém após a instalação é necessário
fazer a configuração da IDE, para que ela possa trabalhar com o SDK.
4.5. Metodologia de Implementação
4.5.1. Criação de um Projeto
Para acessar o programa WTK utiliza-se o atalho chamado KToolBar que se encontra
no menu de programas. Em seguida, para criar o projeto, clica-se no botão New Project... e
preenche-se os campos com o nome do seu projeto e o nome da classe principal do projeto.
Para efetivar a criação do projeto, é necessário clicar em Create Project. A tela que aparece
em seguida é utilizada para informar informações detalhadas do projeto, estas informações
ficam disponíveis no arquivo.JAD (frisando que um programa para celular se divide em dois
arquivos, o .JAR que possui o programa e o arquivo .JAD que possui diversas informações
sobre o projeto), não é interessante alterar essas propriedades, a não ser que seja
realmente necessário, como colocar um ícone personalizado ou trocar a versão da MIDP.
Após a confirmação no OK, o projeto será criado. Automaticamente é incluído um
diretório dentro da pasta app, que se encontra no diretório do WTK, nesta pasta com o nome
do projeto ficará localizado todos os recursos do aplicativo, conforme Figura 10 e Figura 11:
Figura 10. Tela do WTK após a criação do projeto HelloWorld
41
Figura 11. Estrutura de diretórios criada pelo WTK
4.5.2. Codificação do Sistema
Para a codificação do sistema, dentro do editor de código Gel, cria-se um novo arquivo
“Java File”, gravando no diretório src do projeto. É neste arquivo que será digitado todo o
código-fonte da aplicação, a Listagem 5 possui o código de um programa simples, apenas
para exibição do tradicional “Hello World”.
import javax.microedition.lcdui.*;
import javax.microedition.midlet.*;
public class
private
private
private
HelloWorld extends MIDlet implements CommandListener {
Display tela;
TextBox areatexto;
Command comando;
public HelloWorld () {
tela = Display.getDisplay(this);
comando = new Command("Sair", Command.SCREEN, 1);
areatexto = new TextBox("Alo Mundo","J2ME",50,0);
areatexto.addCommand(comando);
areatexto.setCommandListener(this);
}
public void startApp() {
tela.setCurrent(areatexto);
}
public void pauseApp() { }
public void destroyApp(boolean condicional) { }
public void commandAction(Command c, Displayable d) {
if (c == comando) {
42
destroyApp(false);
notifyDestroyed();
}
}
}
Listagem 5.
Conteúdo do arquivo fonte .Java
Após a codificação do programa, resta fazer a compilação, apesar de existir o recurso
de compilação no Gel os arquivos .class serão gerados na pasta src junto com o código
fonte, porém eles devem ser gerados na pasta classes. Para agilizar este processo a melhor
alternativa é compilar o programa pelo WTK, clicando no botão Build, se existir erros de
compilação, será apresentado na própria console do WTK, então é só voltar para o Gel,
corrigir o erro, salvar, voltar para o WTK e voltar a pressionar o botão Build, até que a
mensagem Build Complete apareça.
4.5.3. Execução do Aplicativo no Emulador
O WTK dispõe do recurso para emular o aplicativo desenvolvido na tela do celular,
porém existem poucos modelos de aparelhos, modelos adicionais podem ser conseguidos
no site da empresa fabricante dos celulares, mesmo assim com os modelos básicos que
vem junto com o WTK já é possível ter uma idéia de como o software irá se comportar. Para
rodar o aplicativo clica no botão Run. Aparecerá a tela de menu do celular para escolher o
aplicativo, escolha a opção Launch e pronto, seu aplicativo já aparece no emulador, como
na Figuras 12.
Como o poder de processamento do celular bem como sua conexão com a rede é
bem menor de que qualquer computador, a redução destas velocidades pode ser feita
através da opção Edit – Preferences...
43
Figura 12. Emulador default do WTK
44
4.5.4. Transferência do Aplicativo para o Celular
Esse processo depende muito do aparelho onde o software vai ser instalado, tem
aparelhos em que é possível passar o aplicativo apenas através de Web, para fazer isso é
necessário disponibilizar os arquivos .jad e .jar (Figura 13) em um servidor Web, e digita o
endereço no celular junto com o nome do arquivo .jad (Listagem 6), outra forma é passar o
programa via cabo, quando o aparelho dispõe deste recurso a grande vantagem é que não
se paga nada para fazer a transmissão, a desvantagem é que o cabo costuma ser vendido
separadamente, além de ter um custo relativamente elevado e não é fácil encontrar estes
cabos a pronta entrega.
MIDlet-1: HelloWorld, , HelloWorld
MIDlet-Jar-Size: 1174
MIDlet-Jar-URL: HelloWorld.jar
MIDlet-Name: HelloWorld
MIDlet-Vendor: Arthon
MIDlet-Version: 1.0
MicroEdition-Configuration: CLDC-1.0
MicroEdition-Profile: MIDP-1.0
Listagem 6.
Conteúdo do arquivo descritivo .JAD
Figura 13. Arquivos que devem ser copiados para o celular
45
5. PRODUTOS DISPONÍVEIS NO MERCADO
Em estudo de mercado realizado em cada uma das operadoras de telefonia celular
que atuam no estado de São Paulo, sendo elas a Claro (CLARO, 2005), Vivo (VIVO, 2005) e
TIM (TIM, 2005), foi possível constatar que as operadoras Claro ( Figura 14) e TIM (Figura
15), que utilizam a mesma tecnologia (GSM) em média, 60% de todos os modelos
comercializados, possuem a tecnologia J2ME, todos os modelos lançados no ano de 2005,
possuem esta tecnologia. Quanto à tecnologia Symbian, nestas duas operadoras, não
existem muitos modelos, alcançando um pequeno percentual de 5%, nestas duas
operadoras, não existe nenhum aparelho com a tecnologia Brew
Na operadora Vivo (VIVO, 2005), que utiliza a tecnologia CDMA, o cenário é bem
diferente, com exceção dos modelos da Nokia, todos os outros modelos possuem apenas a
tecnologia Brew, marcando uma pontuação de 42%, não possuindo nenhum modelo com a
tecnologia Symbian (Figura 16).
16
14
12
10
8
6
4
2
0
Gradiente
LG
Motorola
Nokia
Samsung
Siemens
Modelos Disponíveis
Modelos com J2ME
Modelos com Symbian
Modelos com Brew
Figura 14. Comparação dos Modelos da Claro
Sony
Ericsson
46
35
30
25
20
15
10
5
0
Gradiente
LG
Modelos Disponíveis
Motorola
Nokia
Modelos com J2ME
Samsung
Siemens
Modelos com Symbian
Sony
Ericsson
Modelos com Brew
Figura 15. Comparação dos Modelos da Tim
16
14
12
10
8
6
4
2
0
Kyocera
Modelos Disponíveis
LG
Motorola
Modelos com J2ME
Nokia
Modelos com Symbian
Figura 16. Comparação dos Modelos da Vivo
Samsung
Modelos com Brew
47
5.1. Tecnologias Disponíveis no Mercado
Considerando todas as operadoras do estado de São Paulo, separando as tecnologias
que cada modelo comercializado possui, obtemos o gráfico da Figura 17, onde a tecnologia
predominante é o J2ME com 43%, seguida pelo Brew com 12% e por último com apenas
4% a tecnologia Symbian.
41%
43%
12%
4%
Modelos com J2ME
Modelos com Symbian
Modelos com Brew
Modelos sem Nenhuma Tecnologia
Figura 17. Comparação das Tecnologias Disponíveis no Mercado
48
6. CONCLUSÃO
Todas as conclusões referente a implementação, aprendizagem destas tecnologias
podem ser retiradas da Figura 17, que demonstra a atuação delas no mercado.
A tecnologia J2ME é a mais encontrada nos modelos comercializados e que
apresentam os melhores custos-benefícios. Como conseqüência desta aceitação do
mercado, é muito mais fácil encontrar documentação, inclusive em português, algo que nas
outras tecnologias é praticamente impossível, outros quesitos deixaram o J2ME na frente
são:
•
Facilidade de implementação, principalmente porque é idêntica à linguagem Java,
e por possibilitar a geração dos ‘binários’ de forma prática e integrada no Kit de
desenvolvimento wireless (WTK), que também é o principal responsável pela
emulação dos aplicativos em celulares ‘virtuais’.
•
Ainda no WTK, é possível gerar os arquivos necessários para upload da aplicação
para o celular, que pode ser feita via cabo, WAP ou infra-vermelho.
•
Devido ao grande número de documentação e livros em português, é muito mais
fácil encarar o desafio de conhecer a tecnologia.
Embora o J2ME possua vários pontos fortes, ele possui alguns pontos negativos, o
principal deles é uma quantidade de recursos nativos levemente inferior às demais
tecnologias, sendo necessário que cada fabricante de telefones celulares implementem seus
próprios recursos.
Quanto ao Brew, segunda tecnologia mais comercializada ele possui alguns recursos
a mais que o J2ME, é difícil encontrar documentação na internet, porém a fornecida
juntamente no SDK é bem completa, detalhada e dependendo da versão é disponibilizada
em português, para o usuário as aplicações Brew são mais seguras pois todas são
‘autenticadas’ pela Qualcomm. Quanto aos problemas do Brew, o primeiro que podemos
citar é a necessidade do desenvolvedor ser obrigado a pagar licenças para obter maiores
detalhes da tecnologia e também para fazer o upload da aplicação para o Celular, mesmo
que isto seja feito apenas para teste.
Para implementar, seu SDK possui vários aplicativos que facilitam a geração do
código, além das várias aplicações de exemplo que são fornecidas para melhorar o
entendimento dos recursos da tecnologia.
Quanto ao Symbian que é a tecnologia menos comercializada, não pode ter seus
recursos comparados, pois ele é um sistema operacional completo e todas as aplicações
rodam de forma nativa, permitindo compartilhamento total de todos estes recursos. O
Symbian aparenta ser a tecnologia que o mercado necessita, porém ainda é necessário
melhorar alguns pontos, principalmente no quesito facilidade de implementação, pois esta é
49
extremamente complicada, sendo necessária a criação de vários arquivos de controle
dificultando a codificação das aplicações. Outro detalhe que desfavorece o Symbian é o
emulador que parece que parou no tempo, pois ele é um pouco chato para se configurar,
nunca se sabe o que ele realmente está emulando.
Porém, embora existam todos estas complicações, a Nokia, principalmente empresa
que mantém o Symbian, possui o site Forum Nokia (NOKIA, 2004a) onde se encontra um
arsenal de documentos sobre a tecnologia, porém em português é praticamente impossível,
os documentos encontrados em português, são geralmente introdutórios e não resolvem
uma dúvida um pouco mais complexa.
A Tabela 2 resume as principais diferenças entre as tecnologias estudadas.
Características
Linguagem de programação
IDE integrada
Complexidade de Implementação
Facilidade de Emulação
Facilidade de Download no Celular
Quantidade de Documentação
Disponível
Quantidade de Documentação
Disponível em Português
Necessidade de Licença para Distribuir a
Aplicação
Execução nativa
Suportado por várias Fabricantes
Suporta Tecnologia GSM
Suporta Tecnologia TDMA
Suporta Tecnologia CDMA
Mensagem (SMS, EMS e MMS)
BREW
C++
Sim
Média
Média
Alta
Média
Symbian
C++
Sim
Baixa
Média
Média
Média
J2ME
Java
Sim
Alta
Alta
Média
Alta
Baixa
Baixa
Alta
Sim
Não
Não
Não
Sim
Não
Não
Sim
Sim, nativo
Sim
Sim
Sim
Sim
Sim
Sim, nativo
Não
Sim
Sim
Sim
Sim
Sim, depende do
aparelho
Email (POP3 e IMAP)
Sim, nativo
Sim, nativo
Não
Bluetooth, Infravermelho e USB
Sim, nativo
Sim, nativo
Sim, depende do
aparelho
TCP-IP
Não
Sim
Não
FTP
Não
Sim
Não
HTTP
Sim
Sim
Sim
HTTPS
Sim
Sim
Sim
Criptografia
Sim
Sim
Sim
Imagem
Sim
Sim
Sim
Gráficos 2d
Sim
Sim
Sim
Gráficos 3d
Sim
Sim
Sim, depende do
aparelho
Som
Sim
Sim
Sim
Banco de dados (persistência)
Sim
Sim
Sim
Acesso ao Calendário
Sim
Sim
Sim, depende do
aparelho
Acesso à Agenda
Sim
Sim
Não
Tabela 2 Comparação entre Brew, Symbian e J2ME
50
7. REFERÊNCIAS BIBLIOGRÁFICAS
IDGNow “IDGNow”. Online http://idgnow.uol.com.br, 06/Nov/2004
SYMBIAN “Symbian OS – the mobile operation system”. Online www.symbian.com,
24/No/2004
MOTOROLA “MOTOCODER Home”. Online
http://www.motocoder.com/motorola/pcsHome.jsp, 24/Nov/2004
NOKIA “Forum Nokia - Developer Resources”. Online
http://www.forum.nokia.com/main.html, 24/Nov/2004a
NOKIA. “Java MIDP Application Developer’s Guide for Nokia Devices”. [S.I.], 2002
NOKIA. “Symbian OS: Getting Started with C++ Application Development”. [S.I.], 2003
QUALCOMM. “Manual do BREW MIF Editor”. San Diego, CA, 2002a
QUALCOMM. “Manual do Usuário do BREW SDK”. San Diego, CA, 2002b
QUALCOMM. “QUALCOMM BREW Home”. Online http://qualcomm/brew,
24/Nov/2004a.
QUALCOMM. “Starting with BREW”. San Diego, CA, 2004b
QUALCOMM. “QUALCOMM | Manufacturer”. Online
http://brew.qualcomm.com/brew/en/manufacturer/oem.html, 13/Dez/2005.
SUN “Java 2 Platform, Micro Edition (J2ME)”. Online http://java.sun.com/j2me,
24/Nov/2004.
SUN “Introduction to Mobility Java Technology”. Online
http://developers.sun.com/techtopics/mobility/getstart, 20/Jun/2003
SUN “What’s New in MIDP 2.0”. Online
http://developers.sun.com/techtopics/mobility/midp/articles/midp20,
20/Jun/2005a
SUN “J2SE Downloads”. Online
http://java.sun.com/j2se/downloads/index.html, 20/Jun/2005b
51
SUN “J2ME Wireless Toolkit Download 2.2 Release”. Online
http://java.sun.com/products/sjwtoolkit/download-2_2.html, 20/Jun/2005c
SUN. “The Java platform for consumer and embedded devices”. Santa Clara, CA, 2002
CHRISTIANO PINHEIRO “iMasters – Java”. Online
http://www.imasters.com.br/artigo.php?cn=1539&cc=19, 20/Jun/2005
MUCHOW, John W. “Core J2ME – Tecnologia e MIDP”. São Paulo, SP: Makron Books,
2004
DEITEL, H.m; DEITEL, P. J. “Java – Como Programar”. Porto Alegre, RS: Bookman, 2002
RUMBAUGH, James. “UML Guia do Usuário”. Rio de Janeiro, RJ: Campus, 2000
DEITEL, H. M. “C++ Como Programar”. Porto Alegre, RS: Bookman, 2001
BRITO, Robison Cris. “Desenvolvimento de Aplicativos para celular - Java 2 Micro Edition”.
Centro Federal de Educação Tecnologia do Paraná, 2004 ?
CLARO “Claro”. Online http://lojaonline.claro.com.br/, 30/Out/2005.
TIM
“Loja
TIM”.
Online
http://www.lojatim.com.br/TIM/default.asp,
30/Out/2005.
VIVO “Os melhores celulares e as principais marcas estão na Vivo”. Online
http://www.vivo.com.br/portal/celulares.php, 30/Out/2005.
IIDA, Renato Faria. “Desenvolvimento C++ para Symbian OS”. Web Móbile, Grajaú, RJ, n.
4, p. 16-24, ago. 2005.
BORGES, Rosfran. “Introdução ao Desenvolvimento em Symbian”. Instituto Nokia de
Tecnologia, 2005
MERY, David. “Symbian OS Version 7.0 – Functional description”. Symbian, 2003
SYMBIAN Symbian: Symbian OS phones”. Online
http://www.symbian.com/phones/index.html, 01/Nov/2005