Lucas Damiani Thiago Przybylovicz Homer Framework ...Damiani, Lucas. Przybylovicz, Thiago Homer Framework - Biblioteca para Coleta de Dados em dispositivos móveis. 74 p. Trabalho

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


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


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


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:


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.


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;


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


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.


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.


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


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;


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.


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.


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


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 é


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;


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


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.


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


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, é


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;


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.


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;


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.


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


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


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.


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


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


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


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;


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;


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.


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


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;


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.


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;




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;





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;



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.


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”;


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

Documents

Lucas Damiani Thiago Przybylovicz Homer Framework ...Damiani, Lucas. Przybylovicz, Thiago Homer Framework - Biblioteca para Coleta de Dados em dispositivos móveis. 74 p. Trabalho