lucas damiani thiago przybylovicz homer framework ...damiani, lucas. przybylovicz, thiago homer...
TRANSCRIPT
-
Lucas Damiani Thiago Przybylovicz
Homer Framework – Biblioteca para coleta de dados em dispositivos móveis
Trabalho de Conclusão de Curso apresentado à UTFPR como requisito parcial para obtenção do título de Tecnólogo em Desenvolvimento de Sistemas Distribuídos.
Orientadora: Ana Cristina Barreiras Kochem Vendramin
Co-orientadora: Anelise Munaretto Fonseca
CURITIBA 2009
-
Damiani, Lucas. Przybylovicz, Thiago
Homer Framework - Biblioteca para Coleta de
Dados em dispositivos móveis.
74 p.
Trabalho de Conclusão de Curso – Universidade
Tecnológica Federal do Paraná. Curso de Tecnologia em
Desenvolvimento de Sistemas Distribuídos.
1. Ciências Exatas e da Terra - 2. Ciência da
Computação - 3. Sistemas de Computação - 4. Software
Básico.
-
DEDICATÓRIA
Este projeto é dedicado a todos os que estiveram presentes em
nossas vidas e nos apoiaram em todos os momentos desta caminhada,
sejam parentes, amigos, companheiros de classe, docentes ou pessoas que
tiveram apenas uma passagem em algum determinado momento, nos dando
força e esperança para continuar.
Também dedicamos o presente a todos os estudantes que possam
ver neste trabalho uma inspiração para conquistas futuras.
-
AGRADECIMENTOS
Primeiramente a Deus, por tudo.
Aos nossos familiares e amigos, que estiveram ao nosso lado, dando
apoio, nos reconfortando e torcendo pelo nosso sucesso.
Aos colegas de classe, pelos momentos de alegria, de aprendizado e
de auxílio mútuo.
Aos professores, que cumpriram com excelência a tarefa de nos
passar os conhecimentos por eles dominados, muitas vezes ultrapassando o
escopo da matéria e nos dando dicas valiosas para carregarmos para nossa
vida social e profissional, em especial à professora Ana Cristina, por aceitar
o convite de ser a orientadora deste projeto, nos indicar os procedimentos a
serem executados e por, muitas vezes, ter sido compreensiva conosco
diante das dificuldades que enfrentamos.
Às nossas namoradas, Gabrielle e Suelen, pela compreensão nos
momentos que tivemos que nos dedicar aos estudos e não pudemos dar a
devida atenção.
Por fim, a todos os que auxiliaram direta ou indiretamente na
idealização e implementação deste trabalho.
-
SUMÁRIO
1 INTRODUÇÃO ........................................................................................ 1
1.1 Apresentação ................................................................................ 2
1.2 Justificativa ................................................................................... 2
1.3 Objetivos do Trabalho .................................................................. 4
1.4 Conteúdo do Trabalho .................................................................. 5
2 LEVANTAMENTO BIBLIOGRÁFICO E ESTADO DA ARTE ................. 7
2.1 Symbian ......................................................................................... 7
2.2 S60 .................................................................................................. 8
2.2.1 Symbian OS ...................................................................... 10
2.2.2 Symbian OS Extensions .................................................. 10
2.2.3 Open C ............................................................................... 10
2.2.4 S60 Platform Services ...................................................... 11
2.2.5 S60 Application Services ................................................. 11
2.2.6 S60 Java Technology Services ....................................... 12
2.2.7 Web Run-Time .................................................................. 12
2.2.8 S60 Applications ............................................................... 12
2.2.9 Tecnologias principais da plataforma S60 ..................... 12
2.2.10 Edições da plataforma S60 ................................................ 13
2.2.11 Processo de desenvolvimento para a plataforma S60 .... 13
2.3 JavaME ......................................................................................... 15
2.3.1. JavaME e S60 .................................................................... 18
2.4 Symbian C++ ............................................................................... 20
2.5 Python for S60 ............................................................................. 21
2.6 Premissas de usabilidade na plataforma S60 ........................... 24
2.6 Estado da arte ............................................................................. 26
3 METODOLOGIA ................................................................................... 29
3.1 Levantamento de requisitos ....................................................... 29
3.2 Recursos utilizados .................................................................... 29
3.3 Monitoramento e controle do projeto ........................................ 31
3.4 Modelagem .................................................................................. 31
3.5 Implementação ............................................................................ 32
-
3.6 Testes ........................................................................................... 34
4 RESULTADOS ...................................................................................... 35
4.1 Conteúdo dos resultados ........................................................... 35
4.2 Modelagem .................................................................................. 36
4.2.1 Arquitetura da solução ..................................................... 36
4.2.2 Levantamento detalhado de requisitos .......................... 37
4.2.3 Diagrama de casos de uso .............................................. 43
4.2.4 Diagramas de sequência .................................................. 43
4.2.5 Diagrama de classes ........................................................ 44
4.3 Implementação ............................................................................ 48
4.4 Portal do projeto ......................................................................... 49
4.4.1 Wiki .................................................................................... 49
4.4.2 Controle de versão ........................................................... 50
4.4.3 Controle de tickets ........................................................... 50
4.5 Utilização da biblioteca Homer .................................................. 50
4.6 Discussão .................................................................................... 54
4.7 Dificuldades encontradas........................................................... 55
5 CONCLUSÃO ....................................................................................... 57
5.1 Contribuições .............................................................................. 57
5.2 Trabalhos futuros ........................................................................ 57
6 REFERÊNCIAS ..................................................................................... 59
-
LISTA DE FIGURAS
Figura 1 - Vendas de smartphones em 2008. (ELMER-DEWITT, 2009) ....... 1
Figura 2 – Arquitetura da plataforma S60. (NOKIA CORPORATION, 2006)
..................................................................................................................... 10
Figura 3 – Processo de desenvolvimento para a plataforma S60. (NOKIA
CORPORATION, 2006) ............................................................................... 14
Figura 4 – Exemplo das teclas de um aparelho que usa S60. .................... 25
Figura 5 – Elementos de interface da S60 (SCHEIBLE-TULLOS, 2007). ... 26
Figura 6 – Arquitetura da solução ............................................................... 36
Figura 7 – Diagrama de casos de uso ........................................................ 43
Figura 8 – Classes do Core da biblioteca. .................................................. 44
Figura 9 – Classes relativas à API de Collectors. ....................................... 45
Figura 10 – Classes relativas à API de Commands. ................................... 46
Figura 11 – Classes relativas à API de Validators. ..................................... 47
Figura 12 – Formulário inicial da aplicação exemplo. ................................. 51
Figura 13 – Exemplo de uso da API de Commands. .................................. 51
Figura 14 – Exemplo de uso da API de Validators. ..................................... 52
Figura 15 – Exemplo de uso do componente coletor de imagens. ............. 53
Figura 16 – Exemplo de uso do componente coletor de som. .................... 53
-
LISTA DE SIGLAS
API
CDC
CLDC
Application Programming Interface
Connected Device Configuration
Connected Limited Device Configuration
CSS
GPS
HTML
Cascading Style Sheets
Global Positioning System
Hyper Text Markup Language
http Hyper Text Transfer Protocol
IDE
IM
MIDP
Integrated Development Environment
Instant Messaging
Mobile Information Device Profile
MOAP Mobile Oriented Applicatinos Platform
PDA Personal Digital Assistant
S60
TCE
Series 60
Test Case Efectiveness
UIQ User Interface Quartz
UML Unified Modeling Language
XML Extensible Markup Language
-
RESUMO
O crescimento do mercado de smartphones tornou interessante o
desenvolvimento de aplicações para dispositivos móveis. Diante deste
cenário, o Homer Framework foi idealizado, com a proposta de fornecer uma
biblioteca de componentes de fácil manuseio para criação de aplicações de
coleta de dados que possam usufruir dos recursos que os aparelhos que
utilizam a plataforma Symbian S60 proporcionam. Foi escolhida a linguagem
de programação Java para desenvolver o projeto, devido à facilidade de
integração entre a linguagem e o sistema alvo. Como resultado final foi
obtido uma biblioteca de componentes para utilização em dispositivos
móveis em geral, desde que possuam os requisitos necessários.
Palavras chave: JavaME, Symbian, S60, PyS60, Nokia, Smartphone.
-
ABSTRACT
The growth of smartphones market made the mobile application
development an interesting investment. Observing this scenario, the Homer
Framework was idealized, with the proposal of provide an easy-handling
component library to develop data collection applications that can use the
features of smartphones that has Symbian S60 software platform. The Java
programming language was chosen for the project development due to the
ease integration between the language and the target system. As final result,
a component library for mobile phones was developed, according to their
features.
Keywords: JavaME, Symbian, S60, PyS60, Nokia, Smartphone.
-
Capítulo 1 – Introdução 1
1 INTRODUÇÃO
O mercado de smartphones, aparelhos de celular que possuem um
Sistema Operacional, permitindo a execução de programas de diversas
funcionalidades, tem um grande potencial para o desenvolvimento de
softwares especializados, como aplicações de pesquisa, coleta de dados e
aplicações com geração de dados geográficos. Aliado a isto, estes aparelhos
estão tornando-se mais robustos, com um hardware mais potente e com
várias facilidades para o desenvolvimento de aplicações.
Em 2008, a plataforma Symbian foi responsável por 52,4% das vendas
deste mercado no mesmo ano (DIGNAN, 2009). Logo após, estão os
aparelhos equipados com o sistema operacional da Research In Motion,
conhecidos como BlackBerry. Seguido destes estão Windows Mobile,
iPhone OS X, Linux, Palm OS e outros, conforme o gráfico apresentado na
Figura 1.
Figura 1 - Vendas de smartphones em 2008. (ELMER-DEWITT, 2009)
O domínio da plataforma Symbian neste nicho de mercado torna
atrativa a criação de aplicativos para a mesma. Esta plataforma é
representada por vários fabricantes de smartphones, destacando-se, em
-
Capítulo 1 – Introdução 2
ordem de maior utilização, Nokia e Sony Ericsson, que produzem,
respectivamente, o S60 e o UIQ.
Os usuários deste tipo de aparelho são, na grande maioria, clientes
corporativos, que muitas vezes subutilizam o potencial dos mesmos. A
proposta principal do Homer Framework é fornecer uma biblioteca de
controles gráficos para desenvolvimento de aplicações na plataforma
Symbian, com foco em componentes para aplicações corporativas. A
intenção do trabalho proposto é instigar a criação de softwares que utilizem
os recursos disponíveis nestes aparelhos.
Devido a haver uma ampla gama de aparelhos que utilizam o Symbian,
o escopo do trabalho será restrito aos aparelhos da Nokia, que utilizem a
versão 9.2, com a customização S60 3rd Edition Feature Pack 1. A
motivação para esta restrição está melhor apresentada no item 1.2 deste
trabalho.
1.1 Apresentação
O presente trabalho resume-se à criação de uma biblioteca de
componentes que facilite a interação do usuário com o smartphone, mais
especificamente em aplicações que utilizem formulários como mecanismo
para entrada de dados, visando maior propagação e utilização deste tipo de
aparelho, os quais têm muitas vezes seu potencial ofuscado pela falta de
conhecimento do usuário final e, até mesmo, dificuldade em encontrar
aplicativos úteis e de fácil manuseio.
1.2 Justificativa
Existe uma quantidade imensa de softwares para captura de dados em
campo. Contudo, estes softwares são executados em palmtops, PocketPCs,
notebooks ou outros coletores específicos de dados. Além disto, estes
softwares são normalmente concebidos para resolver problemas pontuais,
sem uma visão de reuso dos mesmos entre aplicações. A plataforma S60
tem um grande potencial para suportar estas aplicações, desde que os
-
Capítulo 1 – Introdução 3
componentes utilizados para isto funcionem de forma que traga uma
experiência agradável ao usuário.
É possível tomar como exemplo um representante comercial. Este tipo
de profissional normalmente possui um aparelho celular cedido pela
empresa, além de outro dispositivo para a coleta de dados, como, por
exemplo, um palmtop. Contudo, utilizando um smartphone S60, esta pessoa
poderia utilizar apenas o seu aparelho celular.
Podem ocorrer momentos onde um profissional tem um smartphone
S60, contudo o aparelho não é utilizado para coleta de dados devido à
complexidade para o desenvolvimento de uma interface amigável para os
aplicativos, subutilizando os dispositivos.
Situações como estas trazem custos adicionais para as empresas, pois
há desperdício de recursos materiais e implicam na necessidade de
gerenciamento de diversos dispositivos. Além disto, o oferecimento de uma
biblioteca que facilite o desenvolvimento para a plataforma, com
componentes já prontos pode ser um diferencial para conquistar novos
usuários para os aparelhos que utilizam o sistema S60.
A restrição de utilizar o Symbian foi tomada por quatro razões
principais, que são:
Amplo market share;
Facilidade de desenvolvimento;
Afinidade com o S60;
Recursos disponíveis nos aparelhos.
Conforme exposto na Figura 1, o amplo market share do Symbian é um
fator interessante para a escolha do mesmo. Este sistema operacional tem
como maior mantenedor a Nokia, que é a maior vendedora de telefones
celulares do mundo (ELMER-DEWITT, 2009). Isto indica que a procura de
componentes para esta plataforma tende a ser maior.
Outro fator que influenciou a restrição de escopo ao Symbian foi a
facilidade de desenvolvimento proporcionada pelos mantenedores do
sistema operacional. É possível desenvolver aplicações para a plataforma
em várias linguagens de programação, como C++, Java e Python. Além
-
Capítulo 1 – Introdução 4
disto, há um amplo suporte dos fabricantes que customizam o Symbian, seja
qual for a linguagem escolhida, tanto com documentação quanto com fóruns,
blogs, wikis e outras ferramentas colaborativas.
Como terceiro fator decisivo na restrição do escopo, está à afinidade
dos desenvolvedores com a plataforma S60. Ela está disponível em diversos
aparelhos da Nokia, amplamente comercializados no mercado brasileiro,
facilitando o acesso a equipamentos para testes. Devido a este fato, a
compatibilidade dos componentes criados foi testada nos aparelhos que
utilizam a versão S60 3rd Edition Feature Pack 1. Este versionamento foi
criado pela Nokia, e implica que todos os smartphones que utilizam o S60
possuem um conjunto mínimo de recursos, que serão levados em conta no
momento de criar a biblioteca de componentes.
Por fim, os aparelhos da S60 3rd Edition Feature Pack 1 trazem um
conjunto de recursos mínimos interessante, como câmera, gravador de som,
entre outros, o que possibilita usar os aparelhos como um coletor de dados
de baixo custo, oferecendo ao mesmo tempo um número maior de
funcionalidades.
Após todo o processo de implementação do produto e favorecimento à
linguagem Java para o desenvolvimento, fez-se desnecessária a restrição à
plataforma Symbian. Os motivos estão descritos de forma mais detalhada no
capítulo 2.
1.3 Objetivos do Trabalho
O objetivo principal do presente trabalho é desenvolver uma biblioteca
de componentes gráficos e de troca de informações que facilitem o uso de
dispositivos móveis para coleta de dados em campo, possibilitando o
desenvolvimento de aplicativos com tal finalidade para o mercado
corporativo.
Outro fator que está incluso ao objetivo principal é a necessidade de
ampliar o uso da total capacidade dos aparelhos móveis. Para atender estes
objetivos, foram gerados alguns artefatos, sendo eles:
-
Capítulo 1 – Introdução 5
Modelagem UML da biblioteca de componentes, visando
manter a organização no momento da implementação e ainda
possibilitando o uso da mesma estrutura de projeto para
trabalhos futuros;
Código-fonte da implementação, contendo toda a lógica
imposta nos componentes desenvolvidos, assim como o
Framework em si;
Arquivos binários para distribuição, buscando atingir o objetivo
principal de propagar o uso corporativo dos aparelhos celulares
apostando na interface amigável do Framework desenvolvido;
Site para compartilhamento de informações do projeto, para
auxiliar o trabalho de propagação do Framework, apresentando
vantagens, dicas e informações importantes para o uso do
mesmo;
Relatório final da implementação, apresentando todo o
processo de criação, suas particularidades, dificuldades e
motivações que tornaram este trabalho em realidade.
Estes artefatos podem ser usados individualmente em trabalhos futuros
baseados no objeto de pesquisa.
1.4 Conteúdo do Trabalho
Este documento está dividido em seis capítulos. O presente capítulo
introduz os conceitos de smartphone, sistemas operacionais para os
mesmos e a ampla possibilidade de desenvolvimento de aplicações que
podem permitir a substituição de vários dispositivos de interação de dados
por um aparelho apenas. Apresenta também o tema proposto, levantando os
objetivos principais e específicos, explicando brevemente a temática que
compõe este trabalho.
No segundo capítulo, todas as tecnologias utilizadas são apresentadas,
ressaltando suas particularidades, além de outros conhecimentos que sejam
relevantes para o desenvolvimento deste trabalho. Por fim, será exibido o
que já existe na área de estudo proposta.
-
Capítulo 1 – Introdução 6
O terceiro capítulo expõe as diretrizes utilizadas na confecção deste
trabalho, abordando desde diretrizes para desenvolvimento de software, até
as ferramentas utilizadas para o processo, passando pelos requisitos,
recursos necessários e métodos utilizados para testes de implementação,
integração e implantação para chegar ao resultado final.
O quarto capítulo exibe os produtos finais deste trabalho, utilizando
para isto artefatos gerados na fase de modelagem e outros produtos
originários da fase de desenvolvimento, além de informações sobre a
implantação do produto final, englobando testes, configurações e
informações sobre a utilização do sistema.
O quinto capítulo apresenta situações constatadas no processo de
desenvolvimento, que influenciaram no produto final esperado.
O último capítulo apresenta um parecer sobre os artefatos obtidos no
fim da implementação do projeto, informando o status de cumprimento dos
objetivos previamente apresentados e sugerindo novos trabalhos sobre o
objeto de estudo discutido.
-
Capítulo 3 – Metodologia 7
2 LEVANTAMENTO BIBLIOGRÁFICO E ESTADO DA ARTE
Neste capítulo, é realizada a apresentação das principais tecnologias
utilizadas para o desenvolvimento deste projeto, detalhando um pouco sobre
as histórias das mesmas e as características técnicas que proporcionaram a
sua escolha.
2.1 Symbian
O Symbian nasceu a partir a união entre as empresas Nokia,
Ericsson, Motorola e Psion. Esta última possuía um sistema operacional
chamado de EPOC32, que era utilizado nos PDAs produzidos pela empresa.
As premissas de arquitetura deste sistema foram utilizadas como base para
a construção do Symbian OS. No decorrer dos anos, novas empresas
entraram no consórcio, como Samsung, Matsushita e várias outras. O
primeiro aparelho lançado com Symbian foi Ericsson R380. Ao longo dos
anos foram lançados vários outros aparelhos utilizando o Symbian, de
fabricantes como Nokia, Siemens, Ericsson e Fujitsu. Atualmente, a Nokia
comprou a parte de todas as outras empresas, e doou isto para a Symbian
Foundation, que está liberando o sistema como open source.
O sistema operacional foi criado levando em consideração as
seguintes premissas (MORRIS, 2007):
Os dados do usuário são sagrados;
O tempo do usuário é precioso;
Todos os recursos são escassos.
Para atender a estas premissas, o Symbian apresenta algumas
características:
Todos os recursos são disponibilizados por intermédio de
servidores;
Todos os serviços são assíncronos, sendo necessário o uso de
um modelo de callback para invocação de funções;
-
Capítulo 3 – Metodologia 8
Há uma separação rigorosa entre interface do usuário e os
serviços que fornecem dados para as interfaces;
Concepção de funcionalidades sempre pensando em reuso;
Funcionamento em tempo real, atendendo prontamente a todas
as solicitações;
Concepção para ser extensível e de fácil modificação.
O sistema apresenta estas características tanto para satisfazer a
todas as partes interessadas do consórcio, quanto para atender o nicho de
mercado ao qual foi designado. Isto também possibilitou a customização do
sistema por várias empresas. Abaixo uma relação das principais empresas
que utilizam o Symbian, com o nome da sua versão:
S60, produzido pela Nokia, utilizado tanto pela Nokia quanto
pela Samsung;
UIQ, produzido e utilizado pela Ericsson, atualmente conhecida
como Sony Ericsson.
Uma das premissas do Symbian é garantir a segurança dos dados do
usuário. Para isto, foi criado o conceito de certificado para as aplicações na
plataforma. Este mecanismo garante que as aplicações não acessem dados
restritos do usuário indevidamente, através de permissões concedidas no
certificado distribuído no binário da aplicação. Softwares que fazem acessos
a dados do usuário ou acessam recursos críticos do aparelho tem que ser
assinados com um certificado que lhe conceda estas permissões de acesso.
Caso contrário, os mesmos nem são instalados no Symbian. O processo
para obter um certificado para assinatura das aplicações é relativamente
complexo, não sendo abordado em detalhes na pesquisa, contudo, ele deve
ser considerado, pois pode impactar diretamente no tempo para o
desenvolvimento de uma aplicação para Symbian.
2.2 S60
A plataforma S60 foi desenhada especificamente para smartphones.
Ela é baseada no Symbian OS, suportando características como, telas de
tamanho grande e interface intuitiva. Além disto, ela incorpora inúmeras
-
Capítulo 3 – Metodologia 9
tecnologias de comunicação e interoperabilidade, com respostas rápidas e
seguras utilizando qualquer uma das tecnologias. Os aparelhos com S60
trazem:
Tela colorida QVGA (Quarter Video Graphics Array);
Design inovador, com layout diferenciado no teclado;
Aplicações para gerenciamento pessoal, como contatos e
calendário;
Características avançadas de telefonia e conectividade;
Aplicações para transmissão de mensagens;
Navegação na internet.
Além disto, muitos aparelhos também trazem:
Possibilidade de execução de aplicações Flash;
Câmera digital;
Tocador de música;
Galeria de mídia;
Gravador de vídeo;
Gravador de áudio;
Rádio FM;
Sincronização OTA (Over The Air);
Editor e visualizador de documentos do Microsoft Office.
A plataforma S60 garante aos desenvolvedores que elementos
específicos estarão presentes em qualquer dispositivo de uma mesma
edição e o pacote de recursos da plataforma. Isto é obtido através da
arquitetura exposta na Figura 2.
-
Capítulo 3 – Metodologia 10
Figura 2 – Arquitetura da plataforma S60. (NOKIA CORPORATION, 2006)
2.2.1 Symbian OS
O Symbian OS é um sistema operacional concebido especificamente
para smartphones. Ele possui uma ampla gama de recursos, mesmo nas
suas versões mais antigas. Seu sistema de gerenciamento de memória e
capacidade de execução de múltiplas tarefas possibilita operação segura e
eficiente mesmo com limitação de hardware, situação típica em dispositivos
móveis.
2.2.2 Symbian OS Extensions
Este elemento arquitetural é o que permite à plataforma S60 interagir
com funcionalidades específicas do hardware dos dispositivos, como alerta
de vibração, luzes e status da bateria.
2.2.3 Open C
A partir da S60 3rd Edition, a plataforma S60 passou a incluir um
subconjunto da biblioteca POSIX, chamada Open C. Ela provê acesso a
bibliotecas conhecidas como libc e libdl, habilitando os desenvolvedores a
reaproveitar aplicações do ambiente desktop na plataforma S60.
-
Capítulo 3 – Metodologia 11
2.2.4 S60 Platform Services
O S60 Platform Services são serviços fundamentais oferecidos pela
plataforma S60. Entre eles estão inclusos:
Application Framework Services: provê funcionalidades básicas
para iniciar aplicações e servidores, gerenciamento de estado
das aplicações e componentes de interface gráfica;
UI Framework Services: provê funcionalidades de exibição dos
componentes gráficos, além de gerenciar os eventos
disparados pela interface gráfica;
Graphics Services: provê funcionalidades para criação de
gráficos e desenho dos mesmos na tela;
Web-Based Services: provê serviços para estabelecer
conexões e interagir com funcionalidade baseada na web,
como navegação, download de arquivos e troca de
mensagens;
Multimedia Services: provê capacidade para executar arquivos
de áudio e vídeo, além de suporte a fluxo multimídia via
streaming e reconhecimento de voz;
Communication Services: provê suporte para comunicação
local e a distância, e abrange desde a tecnologia Bluetooth até
chamadas de voz.
2.2.5 S60 Application Services
O S60 Application Services é um conjunto de recursos que fornecem
funcionalidades básicas para as aplicações embutidas da plataforma, e
estão disponíveis também para uso em aplicações de terceiros. Entre elas
estão inclusas:
PIM Application Services: provê as funcionalidades básicas
para aplicações de gerenciamento pessoal, como calendário,
contatos, tarefas, bloco de notas e relógio;
Messaging Application Services: provê suporte para vários
tipos de troca de mensagens, como SMS (Short Message
-
Capítulo 3 – Metodologia 12
Service), MMS (Multimedia Messaging Services) e IM (Instant
Messaging);
Browser Application Services: provê recursos para visualização
de páginas web, incluindo suporte ao Flash Lite, renderização
de vídeo, visualização de imagens SVG (Scalable Vector
Graphics) e renderização de áudio.
2.2.6 S60 Java Technology Services
O S60 Java Technology Services provê suporte para a plataforma
Java Micro Edition. A plataforma S60 suporta a especificação CLDC 1.1
(Connected Limited Device Configuration) e a MIDP 2.0 (Mobile Information
Device Profile), nos aparelhos S60 3rd Edition. Além disto, cada aparelho
S60 suporta uma ampla gama de APIs (Aplication Programming Interface)
Java ME, habilitando acesso ao sistema de arquivos, conexões Bluetooth,
web services, troca de mensagens, áudio, vídeo, localização e outros.
2.2.7 Web Run-Time
O WRT (Web Run-Time) é um ambiente que habilita nos aparelhos
S60 a exibição de Web Widgets. Ele foi introduzido no S60 3rd Edition,
Feature Pack 2. Ele é baseado no projeto WebKit, mesmo utilizados no
navegador Safari e no navegador para a S60.
2.2.8 S60 Applications
S60 Applications são as aplicações embutidas na plataforma que
estão disponíveis para os usuários, como perfis de uso, aplicações para
áudio, vídeo e fotos, etc.
2.2.9 Tecnologias principais da plataforma S60
Todos os dispositivos da plataforma S60 suportam uma série de
tecnologias para conectividade, troca de mensagens e navegação web.
Na área de conectividade, os aparelhos suportam:
Telefonia CDMA e 3G;
Infravermelho;
-
Capítulo 3 – Metodologia 13
Bluetooth.
WLAN em alguns modelos.
Para troca de mensagens, os aparelhos suportam:
SMS;
MMS;
E-mail;
IM (Instant messaging), variando de aparelho para aparelho
quanto às tecnologias suportadas.
Para navegação web, as versões antigas (1st edition e 2nd edition)
suportam navegação WAP. Nas versões mais novas, é suportada a
navegação HTTP completa, utilizando o WebKit da Apple como base.
2.2.10 Edições da plataforma S60
A plataforma S60 foi disponibilizada em três edições principais,
conhecidas como 1st edition, 2nd edition e 3rd edition. Dentro de cada
edição há vários pacotes de recursos, que são as atualizações dentro de
uma edição, sem mudanças significativas na mesma. O escopo deste
trabalho será restrito ao S60 3rd Edition Feature Pack 1. Isto implica que
todas as funcionalidades devem ser compatíveis em todos os aparelhos que
utilizem esta edição.
2.2.11 Processo de desenvolvimento para a plataforma S60
O processo de desenvolvimento para a plataforma S60 é bastante
similar ao processo de desenvolvimento de aplicações web, ou cliente-
servidor. Contudo, há diferenças que implicam no tempo de desenvolvimento
e nos recursos necessários para o mesmo.
-
Capítulo 3 – Metodologia 14
Figura 3 – Processo de desenvolvimento para a plataforma S60. (NOKIA
CORPORATION, 2006)
O processo de desenvolvimento de aplicações para a plataforma S60
segue os passos tradicionais do desenvolvimento conforme ilustra a Figura
3. O processo inicia-se pela codificação e posteriormente compilação do
código-fonte produzido. Contudo, o teste é realizado tanto no emulador da
plataforma S60 fornecido pela Nokia, no emulador fornecido pela Sun junto o
com o SDK Java ME, ou em um aparelho S60. Isto implica diretamente no
tempo de testes, pois é necessário testar as aplicações duas vezes.
Neste processo de desenvolvimento, torna-se muito importante
efetuar testes tanto nos emuladores quanto nos aparelhos. O emulador tem
como objetivo simular as condições existentes no aparelho, contudo, existem
situações complexas para serem simuladas como, por exemplo, a falta de
sinal de telefonia ou problemas no sinal de GPS (Global Positioning System).
Este tipo de problema só pode ser testado no aparelho, tornando essencial
esta política de testes.
-
Capítulo 3 – Metodologia 15
Tendo as três etapas concluídas, a aplicação pode ir para o próximo
passo, que é a assinatura da mesma. Este processo segue as atividades
exibidas no tópico sobre segurança na plataforma Symbian. Apenas após
este passo que a aplicação pode ser distribuída devidamente.
Em suma, as diferenças do processo tradicional estão no momento
dos testes da aplicação e no momento de distribuir a mesma.
2.3 JavaME
A tecnologia Java é amplamente conhecida no mundo da informática,
situando-se como uma plataforma de desenvolvimento completa, com
linguagem de programação própria – que leva o mesmo nome – e ambientes
de distribuição e desenvolvimento integrados que a tornam independente de
outras tecnologias, rodando suas aplicações através da JVM (Java Virtual
Machine).
“Java” é o nome comum dado à Java 2 Platform (SUN
MICROSYSTEMS, 2009), que é dividida em três edições: Java 2 Standard
Edition (J2SE), Java 2 Enterprise Edition (J2EE) e Java 2 Micro Edition. Esta
última tem como alvo aplicações para dispositivos móveis, o que a torna
interessante para o desenvolvimento deste projeto.
O JavaME possui três componentes principais (GIGUÈRE, 2009): o
CDC (Connected Device Configurations), o CLDC (Connected Limited
Device Configurations), e o MIDP (Mobile Information Device Profile), e
trabalha com conjuntos de API chamados configurations, profiles e optional
packages. Todo ambiente em JavaME é formado por um configuration e um
profile. CDC é um conjunto configuration criado para desenvolvimento de
aplicações para dispositivos embarcados, como pagers e PDAs. Já o CLDC
é voltado para desenvolvimento em dispositivos móveis e com poder de
processamento limitado. Unido ao MIDP, forma o ambiente de distribuição
atual mais popular para este tipo de aparelho.
O CLDC define o limite de capacidade da JVM, devido aos poucos
recursos dos dispositivos que utilizarão o ambiente, e um conjunto de APIs
para entrada e saída de dados, chamado Generic Connection Framework. O
-
Capítulo 3 – Metodologia 16
MIDP complementa o ambiente com as APIs necessárias para o
desenvolvimento de aplicações, como as classes de interface com o usuário.
A versão atual é o MIDP 2.0.
Aplicações escritas a partir do MIDP são chamadas MIDlets. Uma
MIDlet estende a classe javax.microedition.midlet.MIDlet, que define os
métodos abstratos que a classe principal deve implementar. Tais métodos
são chamados pelo sistema para informar que o estado da MIDlet está em
processo de mudança. Um exemplo básico é o uso do método startApp,
acionado no momento que a aplicação é iniciada.
As MIDlets são desenvolvidas em microcomputadores, apesar de
executadas nos dispositivos. Por esse motivo, é necessário que o
desenvolvedor possua um Development Kit, para simulação do ambiente de
utilização desse tipo de aplicação. A Sun possui seus próprios kits, porém,
como a MIDP é apenas uma especificação, qualquer fornecedor é livre para
criar outras especificações.
A interface com o usuário pode ser feita de duas formas: abstração,
onde a interface utilizada especifica os métodos a serem utilizados, e
descoberta, onde a aplicação detecta quais interfaces o dispositivo utilizado
comporta e se adapta à necessidade. O modo de abstração, entretanto, é o
padrão. A classe de interface utilizada é a LCDUI - Liquid Crystal Display
User Interface (javax.microedition,lcdui), possuindo também a subclasse
game, propícia para aplicativos de jogos. Tal interface engloba duas APIs:
uma de alto nível, responsável por efetuar a adaptação da interface gráfica
para o estilo nativo do dispositivo utilizado, composta pelas subclasses da
classe Screen, e uma de baixo nível, para trabalhos mais precisos de
implementações gráficas (como, por exemplo, em jogos), composta pelas
classes Canvas e Graphics.
A estrutura da interface gráfica é feita através da abstração da classe
Displayable, que encapsula os gráficos renderizados para o usuário. Um
objeto Displayable sempre é mostrado ao usuário, e apenas um por vez. O
usuário só poderá interagir com o conteúdo do objeto Displayable que está
sendo mostrado no momento. No início da aplicação, o método getDisplay é
-
Capítulo 3 – Metodologia 17
chamado, invocando o objeto Display, responsável pela apresentação dos
objetos Displayable. Toda vez que o método setCurrent, da classe Display, é
chamado, deve ser passado o objeto Displayable desejado. O ciclo de
utilização permanece o mesmo até que seja disparado o método
responsável pela finalização da aplicação, destroyApp.
Basicamente, a interface de usuário trabalha com quatro classes:
TextBox, Alert, List e a classe especial Form.
A classe Textbox, como seu nome sugere, cria uma caixa de entrada
de dados, possibilitando a personalização do conteúdo a ser inserido,
através das opções a seguir:
ANY: qualquer dado pode ser inserido;
NUMERIC: apenas números;
URL: apenas endereços de recursos;
PHONENUMBER: apenas números de telefone;
EMAILADDR: apenas endereços de e-mail;
PASSWORD: máscara para entrada de senhas, transformando
os caracteres em asteriscos.
A classe Alert é uma tela do sistema utilizada para apresentar
informações ao usuário, normalmente disparada junto a um evento. As telas
podem ser definidas como alerta, confirmação, erro, informação ou aviso. É
possível também estabelecer o tempo de exibição da tela, ou colocá-la como
tela fixa, dependendo de uma interação do usuário para a continuidade da
execução do aplicativo.
A classe List é uma forma de mostrar dados na tela, além da
possibilidade de seleção das informações apresentadas. Existem três tipos
de exibição e utilização de List:
Multiple: possibilita escolher mais de um item apresentado,
comumente conhecido em aplicativos web e desktop como
checkbox;
Exclusive: permite apenas a escolha de um item da lista, em
formato radio button;
-
Capítulo 3 – Metodologia 18
Implicit: apresenta uma lista simples, permitindo escolha de
apenas uma opção.
Por fim, a classe Form permite a composição de itens dentro da tela
apresentada ao usuário. Desta forma, é possível a construção de um
formulário com itens especiais provenientes da classe Form, listados a
seguir:
StringItem: texto simples;
TextField: campo de texto editável;
ImageItem: instância da classe Image, possibilita a exibição de
uma imagem;
DateField: campo de texto editável em formato de data e/ou
hora;
Gauge: representação gráfica de valores;
ChoiceGroup: lista de opções, semelhante à classe List;
Spacer: espaço em branco para divisão de itens do formulário.
O avanço dessa tecnologia, assim como das outras plataformas Java,
caminha através das JSRs (Java Specification Requests). Elas são
especificações técnicas enviadas ao JCP (Java Community Process), um
processo formalizado que possibilita o envolvimento de partes interessadas
na definição de novas versões da tecnologia. Essas especificações são
analisadas e votadas pelo comitê do JCP para tornarem-se especificações
oficiais a serem utilizadas.
Atualmente, existem 83 JSRs para a plataforma Java ME (JAVA
COMMUNITY PROCESS, 2009). Alguns exemplos são a JSR 30, que define
o CLDC, JSR 80, que especifica a API utilizada para comunicação com
outros dispositivos via USB, e o JSR 118, que define o funcionamento do
MIDP 2.0.
2.3.1. JavaME e S60
O sistema S60 suporta a utilização do Java ME a partir do JSR 139,
que define o CLDC na versão 1.1 e o JSR 118, supracitado. Também há
suporte para a utilização de várias APIs do JavaME, possibilitando o uso da
-
Capítulo 3 – Metodologia 19
aplicação para envio de mensagens SMS e MMS, visualização de imagens,
reprodução de áudio e vídeos, comunicação via Bluetooth, acessos a
arquivos de sistema e informações pessoais do usuário do aparelho, além
de permitir o uso de GPS, gráficos 3D e web services.
A respeito dos modelos de segurança do S60, o Java é uma exceção.
Ao invés de se adaptar à segurança da plataforma S60, o Java utiliza as
recomendações do MIDP 2.0. Basicamente, as MIDlets são divididas em
dois domínios de segurança: confiável e não-confiável. Para tornar uma
aplicação confiável, é necessário efetuar uma assinatura. O desenvolvedor
necessita de uma chave de autenticação de acordo com a estrutura de
chave pública X.509 (NOKIA CORPORATION, 2006). Com essa assinatura,
a aplicação não precisa solicitar acesso a alguns grupos de funções. Cada
grupo de funções em Java compartilha tipos similares de ações. Há também
a possibilidade do uso de permissões de usuário para acesso a
determinadas funções. Existem quatro grupos de permissões: denied (sem
permissão), one-shot (pede-se autenticação sempre que é necessário utilizar
uma função), session (a permissão é definida por uma sessão válida) e
blanket (válida a partir de uma autenticação na instalação da aplicação). Por
fim, também é possível utilizar criptografia para passagem de dados que
necessitam de maior nível de segurança, como informações bancárias e
dados pessoais.
A tecnologia Java fornece um amplo leque de funcionalidades para
desenvolvimento de aplicações, desde as mais simples até as mais
complexas, além de conseguir propiciar segurança e uso de recursos
específicos de alguns aparelhos, o que a torna uma ferramenta muito
interessante. Dessa forma, o desenvolvimento em JavaME permitiu que o
Homer Framework pudesse trabalhar não só com smartphones que
possuem a plataforma S60, mas também com qualquer dispositivo que
aceite aplicações em Java e possua os requisitos necessários para o seu
pleno funcionamento, tais como recursos multimídia ou localização via GPS.
-
Capítulo 3 – Metodologia 20
2.4 Symbian C++
A linguagem C++ é amplamente conhecida entre os desenvolvedores
do mundo inteiro. Esta linguagem de programação é terceira mais utilizada
no mundo (TIOBE, 2009). Para o sistema operacional Symbian, o C++
também é utilizado, sendo conhecido como Symbian C++. Todo o sistema
operacional e diversas aplicações principais da plataforma S60 foram
concebidos nesta linguagem de programação.
O Symbian C++ proporciona acesso completo às funcionalidades dos
aparelhos, possibilitando o máximo de aproveitamento dos recursos dos
mesmos. Além disto, o desempenho das aplicações tende a ser maior
devido a geração de binários compilados que são executados diretamente
pelo sistema operacional, e não interpretados. Contudo, é uma linguagem
que traz mais complexidades no processo de desenvolvimento, além de
exigir mão de obra mais experiente para utilizá-la.
O processo de desenvolvimento é idêntico ao exposto no tópico sobre
S60. Porém o passo de compilação da aplicação é mais complexo, devido
ao fato de a linguagem ser de baixo nível. Além disto, conforme mencionado
anteriormente, ela é mais complexa que linguagens como Java ou Python,
trazendo baixa produtividade no processo de codificação. Isto acarreta
diretamente no tempo de desenvolvimento das aplicações para a plataforma.
Para criar softwares utilizando o Symbian C++, é possível utilizar
qualquer IDE para C++, compilando as aplicações com as ferramentas e
bibliotecas disponíveis no SDK da Nokia para a plataforma. Contudo, é
recomendado utilizar a IDE Carbide++, pois a mesma já é preparada para
desenvolver aplicações para a plataforma S60, com facilidades de
depuração diretamente no aparelho, entre outros (NOKIA CORPORATION,
2006).
Antes de optar pelo Symbian C++ para o desenvolvimento de uma
aplicação para a plataforma S60, vale levar em consideração o tempo
disponível para execução do projeto, desempenho esperado da aplicação,
experiência da equipe e necessidade de uso de recursos específicos da
-
Capítulo 3 – Metodologia 21
plataforma. Devido a pouca experiência da equipe e ao tempo limitado para
execução do projeto, o Symbian C++ foi descartado para o mesmo.
2.5 Python for S60
A linguagem Python é relativamente antiga, desde 1990, contudo, seu
sucesso cresceu apenas recentemente, estando hoje em sexto lugar no
ranking da TIOBE. Sua popularidade deve-se à sua sintaxe simples, que traz
uma grande produtividade no desenvolvimento de aplicações. Python é uma
linguagem interpretada, sendo distribuída na plataforma S60 através de
scripts, que são lidos e executados pelo interpretador de Python para S60,
conhecido como PyS60. A sintaxe da linguagem compreendida pelo
interpretador é compatível com a versão 2.2 do Python, na versão 1.4.4 do
PyS60 (NOKIA CORPORATION, 2008). Esta característica possibilita que
vários scripts desenvolvidos para outras plataformas possam ser
reaproveitados no S60.
O processo de desenvolvimento para PyS60 é idêntico ao descrito no
tópico sobre a plataforma S60, mas pelo fato de ser uma linguagem
interpretada, é mais simples distribuir aplicações, sendo necessário apenas
copiar os scripts desenvolvidos para a pasta do PyS60, eliminando a
necessidade de compilar a aplicação e assinar a mesma digitalmente.
Contudo, a aplicação fica restrita às permissões que o interpretador Python
possui, característica que pode limitar o uso dos recursos do aparelho.
Devido ao fato de o Python ser uma linguagem interpretada, o acesso
aos recursos nativos do aparelho é limitado às APIs que são disponibilizadas
no interpretador, fazendo com que as aplicações Python sejam relativamente
simples, não podendo aproveitar ao máximo os recursos disponíveis no
aparelho. A informação mais detalhada sobre as limitações do Python está
definida no documento Python for S60 version 1.4.4 final. Além disto, o
desempenho pode ser comprometido devido à linguagem ser interpretada na
plataforma.
Para desenvolver aplicações utilizando PyS60 é necessário instalar o
interpretador no aparelho alvo e no emulador da plataforma. Além disto, é
-
Capítulo 3 – Metodologia 22
necessário apenas um editor de texto simples para criar os scripts Python.
Para distribuir o script é preciso uma ferramenta de acesso ao sistema de
arquivos do dispositivo, função normalmente contemplada pelo software
Nokia PC Suite. Existem ferramentas que permitem execução de código
Python diretamente no interpretador instalado em um dispositivo, através de
conexão Bluetooth. Porém, é recomendado utilizar uma IDE Python e
distribuir as aplicações através do sistema de arquivos, utilizando o
interpretador via Bluetooth apenas para depuração (SCHEIBLE-TULLOS,
2007).
Para aplicações simples, que envolvem pouco processamento
complexo e não utilizam muitos recursos da plataforma, a linguagem Python
torna-se extremamente interessante. Outro uso bastante adequado para a
linguagem é para prototipação de aplicações mais complexas, devido à
simplicidade e alta produtividade proporcionada pela linguagem. Para
aplicações mais complexas ou que exijam utilização de recursos específicos
da plataforma S60 não é interessante utilizar Python, devido ao número
restrito de APIs suportadas no interpretador PyS60.
A criação de interfaces gráficas nas aplicações Python é realizada
utilizando uma API criada para o interpretador. Essa API encapsula alguns
componentes nativos existentes na plataforma S60 dentro da classe appuifw
(SCHEIBLE-TULLOS, 2007). Os componentes disponíveis são:
Note: componente que exibe um alerta textual que é sobreposto
sobre a aplicação, similar a um popup HTML(Hyper Text Markup
Language). Há possibilidade de exibir vários tipos de mensagem,
como sucesso, erro ou informação;
Query: componente similar ao Note, mas que exibe um campo
para entrada de dados, com possibilidade de configurar o tipo de
informação no campo, de acordo com parâmetros configurados
na função que faz a construção do componente;
Multi-query: componente similar ao Query, mas que exibe dois
componentes para entrada de dados em um popup;
-
Capítulo 3 – Metodologia 23
Popup menu: componente que mostra um menu popup com
possibilidade de selecionar um dos registros exibidos. Este
popup é acionado através de uma das teclas de comando dos
telefones;
Selection list: componente que mostra uma lista de elementos,
permitindo a seleção de apenas um deles. Este componente traz
a possibilidade de fazer filtragem dos elementos através de um
campo de busca;
Multi-selection list: componente similar ao Selection list, mas que
possibilita selecionar vários elementos ao invés de um só;
Canvas: componente que permite desenhar elementos na tela,
como retas, figuras geométricas, imagens e vídeos.
Além dos componentes exibidos acima, a classe appuifw possibilita
criar abas, alterar o título e manipular nos botões de comando existentes na
aplicação.
Os componentes criados através de funções da classe appuifw,
retornam apenas os valores selecionados ou inseridos nos componentes,
não sendo possível obter uma instância dos mesmos. Como exceção existe
o componente Canvas, que permite acesso a uma instância do mesmo. Este
fator foi crítico para a equipe de desenvolvimento decidir pela não utilização
de Python na criação dos componentes, pois não há como acessar os
componentes nativos da plataforma para adicionar as características
necessárias que facilitem a coleta de dados.
Além dos fatores mencionados acima, não há uma forma de obter
metadados sobre os componentes usando PyS60. Isso impossibilita a
automatização da coleta de informações da aplicação o que é outro fator
crucial para que o Homer Framework proporcione produtividade aos
desenvolvedores. Como exemplo, esta situação é similar ao uso da
linguagem Java sem a API de Reflection (recurso da linguagem que permite
obter informações em tempo de execução das classes instanciadas), o que
impediria uma série de usos da linguagem, como automatização de
formulários e criação de bibliotecas para persistência de dados.
-
Capítulo 3 – Metodologia 24
2.6 Premissas de usabilidade na plataforma S60
A plataforma S60 foi concebida pensando que os usuários devem
utilizá-lo com apenas uma mão. Para atingir isto, há uma série de
características que são comuns a todos os aparelhos, como tamanho
mínimo de tela, conjunto de teclas específicas e disposição dos elementos
na interface.
Para utilização do S60 em um aparelho, é necessário ter um display
com resolução mínima 176x208 pixels, com possibilidade de exibir 256
cores. Contudo, é recomendada a utilização de uma tela QVGA, com
resolução 240x320, podendo ser na disposição retrato ou paisagem.
Existe um conjunto mínimo de teclas que devem ser disponibilizadas
no aparelho, que dão acesso direto a algumas funções do mesmo. Há um
conjunto de teclas opcionais, que normalmente dão acesso as funções
multimídia do aparelho. Além disto, há dispositivos que possuem um teclado
físico, que pode até mesmo conter teclas específicas para o idioma do país
onde o aparelho será vendido.
O conjunto exibido na Figura 4 é o mínimo que um aparelho da S60
deve suportar. Abaixo a descrição das teclas:
Left softkey e Right softkey: São as teclas que dão acesso às
ações disponíveis na aplicação. Para a S60, normalmente a
tecla da esquerda traz um menu e a tecla direita cancela a
operação corrente;
Five-way navigation: São as teclas de navegação do aparelho.
Estas teclas podem ser usadas para se movimentar sobre as
opções disponíveis nos softwares dos dispositivos. O botão
central serve como um botão para confirmação da operação
corrente no software;
Call Creation: Tecla que inicia uma chamada;
Call Termination: Tela que termina uma chamada. Serve
também para retornar a tela inicial do sistema, deixando a
aplicação atual em segundo plano;
-
Capítulo 3 – Metodologia 25
Applications: Tecla que dá acesso ao menu principal do S60,
exibindo todas as aplicações existentes;
Alpha-numeric keyboard: São as teclas principais do telefone.
Há aparelhos que, além disto, podem ter um teclado QWERTY
(layout de disposição de teclas padrão de teclados de
computador e máquinas de escrever);
Clear: Tecla utilizada para apagar texto no telefone, de forma
similar a tecla backspace nos computadores;
Edit: Tecla utilizada em conjunto com as teclas de navegação
para selecionar texto. A partir da S60 3rd edition FP1, esta
tecla deixou de ser obrigatória.
Figura 4 – Exemplo das teclas de um aparelho que usa S60.
-
Capítulo 3 – Metodologia 26
Estas teclas são o mínimo exigido para um aparelho executar a S60.
Porém, é comum os telefones apresentarem teclas para controle de volume
e acesso a câmera.
Outro fator que é muito importante para a S60 é à disposição dos
elementos da sua interface. A Figura 5 ilustra de maneira geral as principais
características da interface do software.
Figura 5 – Elementos de interface da S60 (SCHEIBLE-TULLOS, 2007).
A parte superior da interface é composta pelo título da aplicação e
pelas abas de navegação. O centro da aplicação pode ser composto por
vários componentes, como um Canvas, uma lista de elementos ou um
conjunto de textbox. A parte inferior da tela traz as ações das softkeys,
normalmente com o menu na softkey esquerda e com a função de cancelar
a operação corrente na softkey direita. Esta disposição garante uma
uniformidade nas interfaces das aplicações para a plataforma, trazendo
benefícios para o usuário.
2.6 Estado da arte
Nesta seção é apresentado o estado da arte de componentes
gráficos. Tais componentes são aplicações para dispositivos móveis que
-
Capítulo 3 – Metodologia 27
apresentam ao usuário uma interface gráfica amigável e inteligível, visando
facilitar a interação entre homem e aparelho.
O Diamond Powder (BELLIA 2009), por exemplo, é um framework
open source desenvolvido em Java ME que auxilia na criação de coletores
de dados para dispositivos móveis. Suas funcionalidades são definidas
através de um schema, dividido entre raiz, páginas, fluxo (conjunto de
páginas onde o usuário navega), textos de ajuda e campos de entrada de
dados, como campos de texto, data, lista de opções e filtros. A estrutura
consolida-se em um hashtable.
A construção do coletor de dados é feita através da classe Collector,
subclasse de Form, instanciada recebendo como parâmetros o objeto
display do MIDlet, o schema necessário e o nome do fluxo(flow) a ser
seguido. Além disso, o coletor deve receber, através do método
addCommand, ao menos um comando OK e um comando BACK para
integrá-lo a outros formulários dentro do dispositivo. Ele também deve
receber através do método setCommandListener o event handler do MIDlet
e o método showCurrentPage deve ser invocado para a montagem interna
das páginas a serem utilizadas.
A persistência de dados é feita através da classe StoredManager, que
armazena os dados em registro RMS (Record Management System, API do
Java ME para persistência de dados) e retorna um ID para consulta
posterior.
A recuperação de dados inseridos é feita pelo método getFields(), da
classe Collector, finalizando o ciclo de funcionamento de um coletor de
dados criado pelo Diamond Powder.
Existem outros frameworks que trabalham com interface do usuário,
porém apresentam como ponto chave a questão da criação de formulários
para entrada de dados, como proposto por este projeto. Alguns exemplos
interessantes a seguir:
jMobileCore (SOURCEFORGE.NET, 2009): ferramenta com
suporte para desenvolvimento de interfaces gráficas baseadas na
classe Canvas, oferecendo rapidez no acesso a dados e auxílio na
-
Capítulo 3 – Metodologia 28
criação de aplicações multithread para dispositivos móveis. Os
principais trunfos desse framework são o suporte de comunicação
com o protocolo HTTP e implementação de campos tipados, como
booleanos, inteiros e até dados binários, além de trabalhar com
persistência de dados via RMS;
Kuix (KALMEO, 2009): framework opensource desenvolvido pela
comunidade de software livre Kalmeo. Kuix é o acrônimo de
Kalmeo User Interface eXtensions, e sua proposta é uma aplicação
leve, sem recursos que possam comprometer o tamanho final da
aplicação, como imagens e informações locais. Os componentes
de interface gráfica são montados utilizando o conceito de widgets
e organizados em um arquivo similar a um XML combinado com
folhas de estilo CSS;
Apime (JAVA4EVER, 2009): este framework aposta na
customização completa da interface gráfica, possibilitando
alteração de fontes, skins, uso de barras de navegação, barras de
progresso e tooltips. As duas maiores particularidades deste
framework são o uso da interface por um ponteiro, da mesma
forma como se usa um mouse, e a possibilidade de
internacionalização da aplicação desenvolvida, incluindo
configuração de teclado para dispositivos que utilizem diferentes
tipos de código ou idioma.
De forma similar à proposta do Diamond Powder, o Homer Framework
visa disponibilizar ao usuário uma interface gráfica de fácil manipulação para
criação de formulários de entrada de dados para dispositivos móveis. Além
disso, oferece acesso a recursos de maior dinamismo, como a captura de
áudio, imagens e localização via GPS. Por fim, as informações coletadas
pelo formulário criado ficam armazenadas no aparelho em arquivos
compactados e à disposição do usuário para o transporte das informações a
outros aparelhos, móveis ou não, por qualquer forma de transmissão de
dados possível pelo dispositivo utilizado.
-
Capítulo 3 – Metodologia 29
3 METODOLOGIA
Neste capítulo são apresentadas as técnicas utilizadas para a
execução do projeto final, tanto para a parte de desenvolvimento quanto
para a criação do relatório final.
3.1 Levantamento de requisitos
O levantamento de requisitos deu-se a partir de um estudo a respeito
das características de aplicativos de entrada de dados pertencentes a outros
tipos de aparelhos, como palmtops, desktops e notebooks. Além disto, foi
utilizada a experiência da equipe para trazer algumas boas práticas do
desenvolvimento web para dentro do mundo dos dispositivos móveis, devido
a diversas semelhanças dos dois ambientes.
Foi levantada uma vasta lista de informações que podem ser
necessárias em uma aplicação que tem como objetivo angariar dados de
diversos tipos e formas diferentes. Feito isso, foi criado um critério de
escolha de quais componentes seriam criados, baseando-se nas seguintes
premissas: grau de importância, diversidade de uso, possibilidade do
desenvolvimento levando em consideração os recursos proporcionados pelo
sistema Symbian, possibilidade de desenvolvimento levando em
consideração a linguagem de programação utilizada e dificuldade de
implementação.
Escolhidos os componentes, foi estudada a melhor forma de
desenvolvê-los, envolvendo disposição visual dentro do aparelho, consumo
de processamento e forma de utilização, baseando-se em uma pesquisa a
respeito de interface homem-máquina, procurando trazer ao usuário a forma
mais agradável possível de manipular a aplicação.
3.2 Recursos utilizados
A pesquisa inicial foi feita amplamente através da Internet, mas
também utilizando revistas específicas sobre o assunto em pauta. Os
-
Capítulo 3 – Metodologia 30
acessos foram feitos através dos microcomputadores pertencentes aos
alunos gestores deste projeto.
O levantamento de requisitos foi criado em um documento de texto,
utilizando a aplicação Microsoft Word 2007 e será entregue junto com o
produto final. Toda a pesquisa de aplicações de entrada de dados foi feita a
partir da Internet, e os programas utilizados como base vieram da mesma
fonte de informação. Também foram analisadas aplicações de uso
corporativo em seus respectivos locais de utilização, como, por exemplo,
restaurantes e departamentos de recursos humanos.
O cronograma foi montado primeiramente com o auxílio da aplicação
Microsoft Excel 2007, em formato de planilha de dados e, posteriormente,
migrado para o programa Microsoft Project Professional 2007, utilizado para
gestão de projetos.
A modelagem do projeto foi desenvolvida utilizando a linguagem UML
através da aplicação NetBeans 6.5.1. Como artefatos desta fase, serão
desenvolvidos os diagramas de classe. Essa documentação será
disponibilizada junto com o produto final.
A implementação do Homer Framework deu-se através do uso da
linguagem de programação Java, seguindo as especificações definidas para
móbile, também conhecidas como Java ME ou JavaME, própria para
aplicações de aparelhos móveis. A IDE utilizada foi o NetBeans 6.5.1,
ferramenta de desenvolvimento especializada para a linguagem Java.
As simulações e testes da aplicação foram possíveis através do S60
3rd Edition FP1 SDK for MIDP, que reúne o emulador de smartphones com o
sistema S60 e as ferramentas para desenvolvimento de aplicações para a
plataforma. Para os testes reais de utilização, foi utilizado um aparelho Nokia
N95, de propriedade de um dos membros da equipe.
Para controle do andamento e possibilidade de trabalho conjunto
entre os dois membros deste projeto, foi utilizada a ferramenta de controle
de versão Subversion, possibilitando o armazenamento de toda a
documentação e códigos-fonte da aplicação em um repositório na Internet,
com possibilidade de criação de pontos de restauração e compartilhamento
-
Capítulo 3 – Metodologia 31
de informações de forma confiável. O repositório está configurado para
acesso nos dois microcomputadores utilizados pelos desenvolvedores do
projeto, que também foram às ferramentas utilizadas em toda a parte de
modelagem e desenvolvimento do projeto.
Por fim, os recursos humanos utilizados em todas as etapas foram os
dois membros deste projeto:
Lucas Damiani, Gerente de projetos da empresa Visionnaire
Informática S/A, estudante do ultimo ano do curso superior de
Tecnologia em Desenvolvimento de Sistemas Distribuídos pela
UTFPR. Possui experiência nas linguagens de programação
Java, C#, ASP.NET, C e Python. Profissional certificado SCJP
5.0 (Sun Certified Java Professional) e SCWCD (Sun Certified
Web Component Developer);
Thiago Przybylovicz, Desenvolvedor da empresa Visionnaire
Informática S/A, estudante do último ano do curso superior de
Tecnologia em Desenvolvimento de Sistemas Distribuídos pela
UTFPR. Possui experiência em linguagens de programação
Java, C# e ASP.NET. Profissional certificado MCP (Microsoft
Certified Professional) e MCTS (Microsoft Certified Technology
Specialist) em .NET Framework 2.0.
3.3 Monitoramento e controle do projeto
Para o monitoramento e controle das atividades do projeto foram
utilizadas técnicas descritas no PMBOK (Project Management Body of
Knowledge. Como auxílio, foi utilizada a ferramenta Microsoft Project 2007
para a gestão do cronograma e manutenção da WBS (Work Breakdown
Structure).
3.4 Modelagem
Para modelagem e definição da arquitetura da aplicação, foi utilizada
a linguagem UML. Esta linguagem traz uma representação gráfica de
-
Capítulo 3 – Metodologia 32
classes e interação entre as mesmas, trazendo uma especificação visual
para orientar o trabalho dos desenvolvedores. O principal motivo para utilizar
esta linguagem na especificação do sistema é a facilidade da mesma para
exibir componentes desenvolvidos utilizando o conceito de orientação a
objetos. Além disto, ela está amplamente difundida e facilita uma posterior
passagem de conhecimento sobre o código.
3.5 Implementação
O desenvolvimento da aplicação foi realizado utilizando a linguagem
de desenvolvimento Java. No início do projeto, foi levantada a possibilidade
de executar o projeto utilizando a linguagem de programação Python,
através do ambiente PyS60. Outra possibilidade era a execução do projeto
utilizando a linguagem C++.
A linguagem Python não foi adotada pelos seguintes motivos:
Falta de um modelo de objetos para manipulação de elementos
da interface gráfica. A estrutura exposta através da plataforma
S60 inviabiliza a criação de componentes gráficos que sejam
reutilizáveis através de aplicações. Não há um modelo de
objetos onde seja possível acoplar novos controles. Todo novo
controle deve ser desenhado, trazendo a necessidade de criar
todo um ambiente de exibição gráfica;
Não há possibilidade de acessar diretamente os controles
criados na aplicação Python, impossibilitando automatizar a
coleta de dados na aplicação;
Não há possibilidade de obter metadados sobre os controles
gerados na aplicação através das funções da classe appuifw o
que traz mais um fator impeditivo para coleta automatizada de
dados;
Não há possibilidade de estender os controles nativos da
plataforma, fato este que impede a alteração do
comportamento dos controles para inserção de validação e
outras características necessárias para o HomerForm;
-
Capítulo 3 – Metodologia 33
Escassez de material sobre a linguagem. Devido ao fato de o
Python ser uma linguagem relativamente nova no universo S60
não há muito material disponível para estudo;
Suporte limitado às APIs disponíveis na S60. Isto é um fator
crítico, pois o suporte às APIs disponíveis para a plataforma
S60 é mínimo, trazendo limitações para obter o máximo dos
aparelhos.
Há alguns outros motivos, como a falta de familiaridade com a
linguagem. Contudo, os motivos apresentados já foram determinantes para
descartar o uso da plataforma PyS60.
O uso de C++ foi descartado por dois aspectos principais, mas que
são muito relevantes tanto para o desenvolvimento desta pesquisa quanto
para aplicações comerciais:
Baixa produtividade proporcionada pela linguagem. Devido a
complexidade da sintaxe C++, tradicionalmente conhecida
como uma linguagem de nível médio, a produtividade dos
desenvolvedores é menor. Como há um prazo limitado para
execução do projeto, não é viável utilizar a mesma. Contudo,
esta linguagem garante o acesso a todas as APIs da
plataforma S60 e é recomendável onde é necessário acesso a
todos os recursos dos aparelhos;
Baixa popularidade da linguagem em relação a Java e Python.
A linguagem Java foi escolhida para a execução do projeto, devido
aos seguintes fatores:
Disponibilização de um modelo de objetos para manipulação
da interface gráfica;
Amplo suporte de grandes empresas, como Nokia e Sun;
Familiaridade dos desenvolvedores com a linguagem;
Vasta gama de materiais de estudo disponíveis tanto na
internet como em impressos;
Relação adequada entre funcionalidades dos aparelhos e APIs
para acesso a estas funcionalidades;
-
Capítulo 3 – Metodologia 34
Possibilidade de abranger um leque maior de dispositivos, não
havendo necessidade de restrição de escopo à plataforma S60.
Isso é possível devido à extensão de classes de interface para
criação dos componentes.
Dentre todos os fatores mencionados acima, é possível observar que
além das características técnicas, a familiaridade com a linguagem foi um
fator crucial para escolha de Java em detrimento às outras linguagens de
programação.
3.6 Testes
Os testes dos componentes gerados no projeto foram executados
através da confecção de planos de teste, realizando os mesmos na
aplicação modelo. A métrica utilizada para definir se a aplicação está
funcionando corretamente é o TCE (Test Case Efectviness), definida como a
razão entre o número de casos de teste que foram aprovados e o número
total de casos de teste Obter um percentual de 100% indica que a aplicação
foi implementada de acordo com a especificação prevista inicialmente no
projeto.
-
Capítulo 4 – Resultados 35
4 RESULTADOS
Neste capítulo, são apresentados os artefatos gerados durante a
execução do projeto, relativos à modelagem, implementação e artefatos
auxiliares do projeto.
4.1 Conteúdo dos resultados
Durante a execução do projeto, foram gerados artefatos para o
planejamento da implementação, artefatos relativos à implementação do
projeto na linguagem de programação escolhida, e artefatos auxiliares, que
colaboraram na execução do mesmo.
Como ferramentas para o planejamento da implementação do projeto,
foi gerado um levantamento de requisitos, além de diagramas de classe,
seguindo padrões de análise orientada a objetos. Estes serões descritos no
item denominado “Modelagem”, que consta neste capítulo. Além disto, neste
mesmo item será exemplificada a arquitetura dos componentes utilizadas no
projeto.
Dentre os artefatos gerados durante a implementação do projeto,
estão o código-fonte obtido e os arquivos compilados e empacotados,
prontos para distribuição junto com as aplicações. Os detalhes destes
artefatos estão expostos na seção 4.3.
Devido à complexidade do projeto e a necessidade de ter uma
ferramenta para centralização das informações do mesmo, a equipe de
desenvolvimento optou por criar um portal em um repositório de projetos de
código-fonte aberto, mantido pelo Google, chamado Google Code. Os
detalhes sobre esta ferramenta auxiliar e seus recursos são exibidos na
seção 4.4.
-
Capítulo 4 – Resultados 36
4.2 Modelagem
Para planejar a implementação do projeto foi necessário a utilização
de três artefatos principais: arquitetura da solução, levantamento detalhado
de requisitos e diagramas de classes.
4.2.1 Arquitetura da solução
A arquitetura da biblioteca de componentes foi concebida tomando
como premissa que os componentes devem servir como uma ferramenta
que reduza o trabalho de codificação de funcionalidades comuns a
aplicações de coleta de dados, como validação, navegação e extração de
dados. Além disto, devem facilitar a coleta de informações diferenciadas que
os aparelhos celulares disponibilizam como localização e conteúdo
multimídia.
Levando isto em consideração, a arquitetura nasceu separando as
quatro áreas principais da biblioteca (ver Figura 6), que são validação de
dados, navegação entre formulários, extração de informações e coleta de
dados diferenciados. Além disto, há o core da solução, que contém as
classes básicas para o desenvolvimento do restante das funcionalidades. A
partir deste core, é possível expandir a biblioteca para soluções
customizadas de coleta, validação, navegação e extração de informações.
Figura 6 – Arquitetura da solução
-
Capítulo 4 – Resultados 37
Desta forma, a solução ficou modular o suficiente para trabalhar com
outras bibliotecas já existentes, podendo também ser estendida facilmente
para a criação de novos controles.
4.2.2 Levantamento detalhado de requisitos
Para definir as funcionalidades previstas na biblioteca, foi realizado
um levantamento detalhado dos requisitos necessários na aplicação,
gerando uma lista de componentes que deve acompanhar a primeira versão
da biblioteca. Abaixo está descrito a listagem dos componentes gerados,
com uma descrição dos requisitos que os mesmos devem atingir.
4.2.2.1 HomerForm
O HomerForm é o componente principal do framework. Sua função é
receber os controles de interface e de troca de informações. Para a coleta de
dados, o conteúdo deste formulário será transformado em um arquivo de
saída.
HomerForm deve herdar a classe Form da biblioteca Java LCDUI;
Outros componentes que sejam parte do framework podem ser
chamados por ele;
Nenhuma tela deve ser feita sem o HomerForm.
4.2.2.2 HomerWizardForm
Extensão do HomerForm, preparado para funcionamento como um
wizard, trabalhando em vários passos com comandos para Voltar, Avançar,
Cancelar e Finalizar a coleta.
HomerWizardForm herdará HomerForm;
Todos os forms a serem utilizados devem ser instanciados junto
com o Wizard;
Os forms utilizados anteriormente persistirão os dados inseridos
pelo usuário, independente da navegação ter sido acionada pelo
“voltar” ou pelo “avançar”;
O wizard utilizará componentes do próprio HomerForm;
-
Capítulo 4 – Resultados 38
Ao finalizar, o wizard chamará o método para salvar os dados e
limpar o cache de informações. Será solicitado que o usuário insira
um nome para o arquivo gerado. Uma mensagem de sucesso será
mostrada e o arquivo salvo no diretório padrão do framework, com
o nome escolhido pelo usuário + data e hora corrente no formato
“aaaaMMdd_hhmmss”, no formato XML;
O wizard passará, basicamente, por quatro ciclos: inserção de
campo, informando seu tipo, descrição do campo, escolha de suas
características (validações, máscaras, número e descrição de
opções – no caso de itens de seleção, obrigatoriedade, vinculação
com outros campos – no caso de campos que necessitem de uma
opção em particular, como por exemplo, campos próprios para
pessoas de sexo feminino, tamanho máximo e tamanho mínimo) e
ordenação, para organizar o campo dentro do formulário. Ao final
do ciclo de criação do componente, é possível retornar ao início
para criar um novo componente, ou finalizar o formulário.
4.2.2.3 HomerGPSPositionCollector
Componente que coleta a posição de latitude e longitude corrente
através do GPS. Depende de disponibilidade de recurso no aparelho.
O HomerGPSPositionCollector irá herdar o seu comportamento da
classe CustomItem, para que possa ser utilizado dentro de um
form;
A possibilidade de escolha deste componente no wizard é
descartada caso o aparelho não tenha disponibilidade para GPS.
Essa verificação será feita no momento da inicialização do
componente.
4.2.2.4 HomerRequiredFieldValidator
Validador de TextField para campos requeridos. Mostra mensagem de
erro para o usuário em caso de entrada de dados nula. Será utilizado em
conjunto com a API de Command, sendo disparados de acordo parâmetros
especificados.
-
Capítulo 4 – Resultados 39
O construtor do HomerRequiredFieldValidator recebe por
referência o componente a ser validado como parâmetro. Tem
opção de construtor para receber mensagem personalizada de
erro, escolhida na etapa do wizard;
A mensagem de erro é disparada através de um alerta na tela,
caso o componente não esteja de acordo com a validação e
impede a continuidade da operação solicitada.
4.2.2.5 HomerRegexValidator
Validador de TextField contra uma expressão regular. Mostra
mensagem de erro para o usuário em caso de entrada de dados inválida.
Será utilizado em conjunto com a API de Command, sendo disparados de
acordo parâmetros especificados.
O construtor do HomerRegexValidator recebe por referência o
componente a ser validado como parâmetro e também a string de
validação. Tem opção de construtor para receber mensagem
personalizada de erro, escolhida na etapa do wizard;
A mensagem de erro é disparada através de um alerta na tela,
caso o componente não esteja de acordo com a validação e
impede a continuidade da operação solicitada.
4.2.2.6 HomerRangeValidator
Validador de TextField numérico para um conjunto de valores. Mostra
mensagem de erro caso o número não esteja entre os limites impostos. Será
utilizado em conjunto com a API de Command, sendo disparados de acordo
parâmetros especificados.
O construtor do HomerRangeValidator recebe por referência o
componente a ser validado como parâmetro e também dois
inteiros com os valores mínimos e máximos para validação. Tem
opção de construtor para receber mensagem personalizada de
erro, escolhida na etapa do wizard;
-
Capítulo 4 – Resultados 40
A mensagem de erro é disparada através de um alerta na tela,
caso o componente não esteja de acordo com a validação e
impede a continuidade da operação solicitada.
4.2.2.7 HomerCompareValidator
Validador de TextField numérica para comparação com valores. Mostra
mensagem de erro caso o número não esteja de acordo com o critério de
comparação. Será utilizado em conjunto com a API de Command, sendo
disparados de acordo parâmetros especificados.
O construtor do HomerCompareValidator recebe por referência o
componente a ser validado e também uma string com o valor para
validação. Tem opção de construtor para receber mensagem
personalizada de erro, escolhida na etapa do wizard;
A mensagem de erro é disparada através de um alerta na tela,
caso o componente não esteja de acordo com a validação e
impede a continuidade da operação solicitada;
4.2.2.8 HomerPhotoCollector
Componente para coleta de fotos. Devido a todos os aparelhos
contemplados no escopo do projeto possuírem ao menos uma câmera, não
há verificação de compatibilidade com o componente.
O HomerPhotoCollector implementará a classe CustomItem, do
HomerForm, podendo ser utilizado dentro de um form;
Esse componente possibilitará tirar foto instantânea através do
próprio formulário. Após tirar a foto, terá a possibilidade de
descartar ou salvá-la. Ao finalizar, o arquivo é salvo com o padrão
de nome do formulário + data e hora atual, no formato
“aaaaMMdd_hhmmss”.
4.2.2.9 HomerSoundCollector
Componente para coleta de sons a partir do gravador de som. Depende
da disponibilidade do recurso no aparelho.
-
Capítulo 4 – Resultados 41
O HomerSoundCollector implementará a classe CustomItem, do
HomerForm, podendo ser utilizado dentro de um form;
O componente possibilitará gravação de som instantânea através
do próprio formulário. Um botão permitirá o início da gravação. Ao
parar, é possível acessar uma opção para ouvir o som novamente.
O arquivo será salvo com o nome do formulário + data e hora
atual, no formato ”aaaaMMdd_hhmmss”;
A possibilidade de escolha deste componente no wizard é
descartada caso o aparelho não tenha disponibilidade para
captura de sons. Essa verificação será feita no momento da
inicialização do wizard.
4.2.2.10 HomerSubmitCommand
Comando que submete o formulário. Aciona os componentes de
validação e apenas submete o formulário se todas as validações forem bem
sucedidas. Utilizado no menu associado às softkeys.
O construtor do HomerSubmitCommand recebe um conjunto de
objetos de validação como parâmetro, de acordo com o número de
validators que o formulário tiver. Também há um construtor que
recebe uma string para a mensagem de erro personalizada,
anulando mensagens de erro vindas dos validators;
Ao tentar o envio de informações do formulário, o evento aciona a
validação de cada objeto. Em caso de erro, cada validação retorna
uma mensagem de erro. Todas as mensagens de erro são
coletadas e mostradas em uma tela Alert para o usuário, não
permitindo o cadastramento das informações. Se nenhuma
mensagem for retornada, o envio é feito com sucesso, salvando as
informações no diretório padrão, em arquivo XML formado pelo
nome do formulário + data e hora atual, no formato
“aaaaMMdd_hhmmss”;
-
Capítulo 4 – Resultados 42
4.2.2.11 HomerResetCommand
Comando que limpa todos os campos do formulário. Utilizado no
menu associado às softkeys.
O construtor do HomerResetCommand recebe um conjunto com
todos os objetos do formulário, a fim de retorná-los à informação
padrão no momento do acionamento do evento.
4.2.2.12 HomerDataSource
Fonte de dados para componentes. Inicialmente será implementada
com suporte somente a fontes de dados XML.
Haverá uma opção no wizard para usuários avançados,
possibilitando o vínculo de um arquivo XML no formato
para os tipos de componentes
informados acima. Também haverá a opção de população manual,
que criará o arquivo dessa forma;
O HomerDataSource encarrega-se de popular os componentes em
tempo de execução, na inicialização do HomerForm. Caso o
arquivo esteja em formato inválido, disparará um alerta ao usuário,
impossibilitando o carregamento do form e solicitando a verificação
do arquivo de origem. Todos os arquivos de origem de dados
ficarão em um diretório padrão, para verificação posterior sem
necessidade de remontagem do form.
4.2.2.13 HomerOutputDatafile
Componente que transforma um HomerForm em um arquivo de saída