Universidade de São Paulo

Escola Politécnica

Projeto 9

Tema livre sobre programação de dispositivo móvel de internet

Orientador: Profº Dr. Felipe Miguel Pait

Carlos A. Agarie Junior – 6849599

Érico Augusto da Silva – 6850069

Lucas Gregolin Dias – 6849950

Maria Emília Midori Hirami – 6849877

São Paulo

2010

Agradecimentos

Nosso grupo gostaria de agradecer ao Profº Felipe Pait pela chance que nos

deu de aprender e conhecer a tecnologia envolvida na criação de programas para

smartphones, uma área que está passando por um crescimento notável.

Também queremos agradecer ao Profº Seabra por ter nos apresentado um

problema real para o qual conseguimos dar uma solução inicial. Isso foi muito

satisfatório e gratificante.

O Profº Paulo Menezes, da FMUSP, e sua equipe também merecem nosso

agradecimento. Foram muito claros nas explicações dos problemas existentes e das

especificações desejadas para o software, inclusive falando as limitações que

precisaríamos impor ao projeto. Tudo isso ajudou bastante, principalmente na fase

inicial e durante todo o projeto.

Resumo

Este é o relatório final do projeto 9 da disciplina PSI2222 – Práticas de

Eletricidade e Eletrônica II, “Tema livre sobre programação de dispositivo móvel de

internet”. Contém todos os tópicos englobados por nós durante o desenvolvimento

do projeto, iniciado em meados de julho deste ano.

Na introdução mostramos um pouco sobre a história do mercado de aplicativos

para celular e, principalmente, a história do iPhone. Depois explicamos o problema

que o projeto visa resolver, mostrando seus desdobramentos e características.

Detalhamos todas as ferramentas analisadas, justificando o descarte de cada uma,

até falarmos da que utilizamos atualmente, o Titanium. Também falamos um pouco

sobre o gerador de questionários que foi usado, o ODK Build.

Na seção “software” fizemos uma explicação sobre o que foi feito durante o

trabalho. Começamos com explicações a respeito do aplicativo, mostrando como ele

supre as necessidades discutidas na seção ”definição do problema”. Depois

explicitamos as funcionalidades do site construído, onde estão o servidor e os

conversores desenvolvidos, além de uma interface de upload/download.

Terminamos falando sobre a documentação não-técnica, voltada para o usuário.

Após isso falamos sobre o orçamento necessário para o projeto, o cronograma

que seguimos e concluimos resumindo as funcionalidades do software criado.

Também colocamos uma seção para trabalhos futuros, guiando possíveis indivíduos

ou grupos que desejarem continuar o projeto. Ao final tem dois anexos; no primeiro

deixamos as idéias antigas para aplicativos, no segundo colocamos algumas

explicações relacionadas com a lógica de jumps, conceito que ficará mais claro

durante o texto.

Lista de abreviaturas e termos

Anatel - Agência Nacional de Telecomunicações;

App – do inglês application, normalmente tratado como “aplicativo”;

App Store – loja virtual onde é possível navegar e adquirir apps gratuitos ou

através de um cartão de crédito;

CEO – Chief Executive Officer, algo próximo de “presidente” de uma empresa;

Depto. – Departamento;

FMUSP – Faculdade de Medicina da Universidade de São Paulo;

iTouch – iPod Touch;

Jailbreak – Hack para o iPhone que permite a instalação de aplicativos não

oficiais e manipulação de arquivos não transferíveis via iTunes;

Jumps – É uma característica de formulários extensos. Dependendo de qual

resposta foi dada em uma questão, podemos evitar ter de responder um bloco de

questões e pular direto para a próxima pergunta relevante. Isso ajuda a otimizar o

tempo das entrevistas.

Kick-off meeting – Reunião que marca o início da execução do projeto;

Macworld - feira anual oficial da Apple que ocorre em São Francisco, USA;

User friendly – característica de um programa fácil de usar, amigável com o

usuário.

Lista de figuras

Figura 1 – Diagrama do processo – p. 14;

Figura 2 – Diagrama da interface – p. 14;

Figura 3 – MacBook White – p. 15;

Figura 4 – Mac Mini – p. 16;

Figura 5 – iPhone 3GS – p. 16;

Figura 6 – iPhone 4 – p. 17;

Figura 7 – Cronograma inicial – p. 18;

Figura 8 – Cronograma atual – p. 18.

Sumário

1. Introdução ......................................................................... 1

2. Definição do problema ...................................................... 3

2.1 Restrições ......................................................................... 4

2.2 Escopo .............................................................................. 4

3. Ferramentas ...................................................................... 6

3.1 Ferramenta escolhida ....................................................... 9

3.2 Hackintosh ........................................................................ 9

3.3 Open Data Kit Build .......................................................... 10

4. Software ............................................................................11

4.1 Aplicativo ….....………………………………………………. 11

4.2 Site ..........……………………………………………………. 11

4.3 Documentação ................................................................. 12

5. Orçamento ....................................................................... 14

6. Cronograma ..................................................................... 17

7. Conclusão ........................................................................ 19

8. Trabalhos futuros .............................................................. 20

Referências Bibliográficas ................................................

Anexo A

Anexo B

1

Introdução

Entre os mercados que crescem atualmente, podemos destacar o de

aplicativos para dispositivos portáteis. Atualmente, o celular já assume um papel

importante no acesso à internet, e o número de pessoas que fazem uso de tal

dispositivo vem crescendo.

Segundo a empresa de consultoria Gartner, o faturamento das lojas de

aplicativos para smartphones e tablets deve subir de US$ 6,2 bilhões, registrado em

2010, para US$ 29,5 bilhões em 2013[1]. Estima-se ainda que 80% dos aplicativos

baixados sejam jogos.

Em escala global, calcula-se que, no terceiro trimestre de 2010, houve um

aumento de 50% na venda de aparelhos celulares com tecnologia 3G em relação ao

mesmo período do ano passado. Já no Brasil, o aumento registrado foi de 69%.

Segundo a Anatel, 10,4 milhões de usuários portam equipamentos 3G. Com esses

números, o acesso à banda larga móvel já é superior às conexões por modens fixos.

A origem do mercado de aplicativos nos moldes atuais está vinculada ao

lançamento do iPhone 3G e da App Store em 2008[2]. Neste contexto, a Apple

reestruturou este mercado, tirando o poder de venda do software das operadoras de

telefonia celular e já disponibiliza mais de 225 mil aplicativos para todos os modelos

do iPhone, iTouch e do recém-chegado iPad.

Outras empresas também ingressaram no desenvolvimento de celulares com

acesso à banda larga, bem como no desenvolvimento de sistemas para operá-los. A

Google trouxe o sistema operacional de código aberto Android, que foi adotado em

smartphones Motorola, LG, Samsung, entre outros. De maneira análoga à Apple, o

Android Market é o canal de distribuição dos softwares para a plataforma da Google,

com aproximadamente 100 mil aplicativos. Ainda existem outras plataformas, como

BlackBerry, focada no desenvolvimento de aplicativos úteis para o meio corporativo,

e o Windows Phone 7, que ainda será lançado.

O iPhone implementa de maneira eficiente os recursos mais relevantes para os

usuários comuns, como internet móvel, integração com redes sociais e reprodução

multimídia, tornando-se popular, se comparado aos demais dispositivos[3]. Parte

desta popularidade se dá ao fato da grande capacidade que a Apple tem de

surpreender os consumidores com novidades, permitindo uma experiência de uso

exclusiva. Além disso, ele apresenta maior aproveitamento do hardware em relação

ao software e vice-versa.

2

Já em 2002, logo após o lançamento do iPod, Steve Jobs (CEO da Apple)

cogitava a idéia de criar um dispositivo que pudesse reunir as funções que os

consumidores já dispunham, mas em aparelhos diferentes. Até então, tratava-se de

e-mails, telefonia celular e ouvir músicas. A princípio, reunir tais funções em apenas

um aparelho deveria ser simples. Surgiu uma parceria entre a Apple, a Motorola e a

operadora Cingular (uma das divisões de telefonia da AT&T), que deu origem ao

ROKR em 2005. No entanto, o aparelho teve uma aceitação negativa por vários

fatores, como a sua capacidade máxima de 100 músicas, independente da

quantidade de memória restante, interface precária e de difícil navegação, a

necessidade do computador como intermediário para colocar os arquivos multimídia

no celular e, por fim, seu design que não era atraente para os consumidores.

Deste modo, a Apple deveria apresentar um produto completamente novo para

ser apresentado na convenção anual Macworld de 2006, sob o risco de não

conseguir cumprir o prazo e sofrer severas críticas, afetando o faturamento da

empresa. Ainda mantendo a parceria com a AT&T para ser a operadora do iPhone,

a Apple escalou seus melhores engenheiros para realizar o projeto. Faltando

apenas algumas semanas para a Macworld, Jobs tinha o protótipo do iPhone para

apresentar à AT&T. Desta vez, o aparelho atendia às espectativas: tela brilhante,

navegador de internet podereso e interface bem trabalhada.[4]

A venda de iPhones foi iniciada em junho de 2007 e, segundo analistas, o

consumo poderia chegar a 3 milhões de unidades até o final do ano. O sucesso do

iPhone consolidou os atuais moldes do mercado de internet móvel e aplicativos,

permitindo seu crescimento vigoroso em tão pouco tempo de existência.

3

Definição do problema

Tendo em vista esse pioneirismo e sua inegável qualidade, nosso grupo optou

por desenvolver um aplicativo para o iPhone/iTouch. Escolhida a plataforma, faltava

definir sua função para podermos iniciar o projeto. Tivemos algumas idéias

preliminares, que explicaremos com mais detalhes no anexo A. Entretanto,

decidimos seguir uma sugestão do Profº Antônio Carlos Seabra e criar um app para

auxiliar pesquisas médicas.

Participamos de três reuniões junto ao Profº Paulo Menezes, do depto. de

Medicina Preventiva da FMUSP. A primeira, realizada no prédio da engenharia

elétrica da POLI, pode ser entendida como nossa kick-off meeting. Pudemos ouvir

sobre a situação atual dos pesquisadores e tivemos contato com algumas de suas

experiências.

No dia 08/09, fomos até a FMUSP para conversar com as pesquisadoras de

campo, em busca de mais informações. Logo de início percebemos o pouco

conhecimento de tecnologia delas, que é um ponto importante e será abordado no

decorrer do relatório. Também aprendemos sobre as condições estressantes em

que são realizadas as entrevistas e sobre os travamentos dos aparelhos utilizados –

um ocorreu quando fomos assistir a uma demonstração do funcionamento do

mesmo.

Com isso, constatamos que uma das dificuldades é o sucateamento da

tecnologia utilizada – no momento, Palms. Travamentos constantes geram demoras

nas entrevistas. Além disso, a venda da Palm para a HP[5] faz com que não seja

possível recorrer ao suporte técnico, tornando a manutenção dos aparelhos

complicada.

O software empregado até o momento também tem limitações. O

EpiSurveyor[6] roda em dispositivos Palm ou com Windows Mobile. É um programa

gratuito, onde o usuário pode criar questionários em um desktop e mandá-los para o

PDA, prosseguindo com a pesquisa.

Entretanto, dificuldades para gerenciar o fluxo das perguntas dentro do

questionário prejudica a criação dos mesmos, atrasando as pesquisas. Em alguns

casos, a equipe responsável pelo desenvolvimento dos mesmo transforma uma

pergunta em duas ou três, para conseguir implementar a lógica necessária.

Enfim, podemos dizer que o problema enfrentado é o de criar condições para a

troca dos aparelhos e tornar mais eficiente a maneira como os questionários são

4

montados. Mas, antes de detalharmos o escopo do projeto, é necessário

explicarmos as restrições impostas ao grupo.

Restrições

Até o momento conseguimos encontrar um certo número de restrições (ou

exigências), que se dividem em: uso, manutenção e financeiras, além do tempo

restrito para o desenvolvimento. Esse assunto será tratado com mais detalhes na

seção 6, cronograma.

Por restrições de uso entendemos aquelas que dizem respeito ao usuário dos

smartphones. De acordo com as informações levantadas, os pesquisadores chegam

a ficar o dia inteiro longe de algum local onde é possível recarregarem os aparelhos,

portanto nosso app precisa ser capaz de funcionar pelo maior período de tempo

possível. Além disso, devemos tornar a interface bastante amigável, possibilitando

uma adaptação simples e agradável.

Temos também aquelas relacionadas à manutenção, que são a criação dos

questionários e a transferência de dados. Queremos permitir maior agilidade à

realização das pesquisas, portanto devemos criar uma maneira bastante intuitiva

para os analistas montarem seus formulários. Além disso, a forma de trocar

informações entre o desktop e os iPhones/iTouchs deve ser segura e ágil, para

impedir a perda de informações e tempo. Sem esquecer que precisamos considerar

a compatibilidade de formatos entre os arquivos que o app cria e os bancos de

dados utilizados.

A restrição financeira é de que temos de deixar o projeto o menos custoso

possível para a equipe do Profº Paulo Menezes, permitindo o seu uso por outros

institutos de pesquisa e o aumento do número de aparelhos, caso sejam aceitos

novos membros.

Escopo

Após aprofundarmos nossos conhecimentos do problema e de suas restrições,

iniciamos a definição do escopo do projeto. Nossa meta é dar condições para a

equipe do Profº Paulo Menezes trocar todos os Palms por iTouchs, utilizando nosso

app para a realização das entrevistas, além de criar os questionários no computador

através de um método feito por nós.

5

Para tanto, devemos tornar nosso método não apenas bom, mas ótimo. Em

busca de satisfazer as exigências de uso e manutenção citadas anteriormente,

precisamos pesquisar e entender como tornar nosso projeto user friendly,

econômico (em gasto de bateria) e com fácil integração entre o desktop, o PDA e o

banco de dados.

Além disso, ao final do projeto, pretendemos disponibilizar nossa

documentação como um “guia de usuário” em formato PDF. Dessa maneira,

acreditamos que será mais conveniente para a equipe do Profº Paulo Menezes tirar

dúvidas de uso e treinar futuros novos pesquisadores sem a necessidade de nos

contatar.

Acreditamos que, junto do estudo que fizemos sobre as ferramentas de

programação e da compatibilidade do Mac OS X Snow Leopard com PCs, é

importante termos em mente um uso real para nosso projeto. Então, podemos

resumir que nosso objetivo daqui em diante é resolver o problema do usuário final

da maneira mais simples, elegante e eficiente possível.

6

Ferramentas

Após uma grande quantidade de pesquisa, iniciada no final de junho desse

ano, consideramos vários softwares para a realização do projeto. Aqui está uma

lista, dizendo as vantagens e desvantagens de cada um:

Sentenza[7]: kit de compilação capaz de criar aplicativos Web para iPhone e

iTouch de maneira totalmente visual em ambiente Windows.

Custo: $20;

Vantagens: não necessita de um Mac;

Desvantagens: suporta poucos recursos e os aplicativos não podem ser

disponibilizados na App Store, logo só funcionam em iPhones com jailbreak.

Além disso, trata-se de uma ferramenta nova e menos conhecida, com pouca

documentação;

Observações: por ser uma ferramenta pouco amadurecida, foi descartada

em pouco tempo.

Nitobi PhoneGap[8]: plataforma open source de desenvolvimento de aplicativos

para dispositivos móveis como iPhone, iPad, Android, entre outros.

Custo: nenhum;

Vantagens: facilidade de desenvolvimento (linguagens web são mais

intuitivas);

Desvantagens: possui pouca documentação e necessita de um Mac;

Observações: no início do projeto, ao ser cogitado o desenvolvimento de

um aplicativo web, o PhoneGap tinha sido a ferramenta escolhida.

Apple iOS SDK & Xcode[9]: pacote de aplicativos da Apple para Mac OS X, que

permite o desenvolvimento de aplicativos para iOS (a plataforma do iPhone, iPad

e iPod Touch). É composto por:

• XCode: ambiente de desenvolvimento (IDE) que integra edição do código-

fonte com compilação, geração do executável, execução (tanto no iPhone

Simulator quanto no próprio aparelho) e depuração, além de gerenciar

projetos.

7

• Interface Builder: permite montar a interface do aplicativo visualmente,

através de “drag and drop” (arrastar e soltar itens na janela), utilizando

componentes pré-configurados (como botões, caixas de texto, views, etc.).

• Instruments: analisa graficamente o desempenho (uso de memória,

atividade de disco e rede, desempenho gráfico) dos aplicativos quando

executados no simulador ou no próprio dispositivo.

• iPhone Simulator: ambiente que simula o dispositivo localmente no Mac

para testar os aplicativos. Apesar de ter um funcionamento bastante

próximo do real (exceto o acelerômetro), podem existir diferenças

(principalmente quanto ao desempenho), o que justifica a importância de

também realizar testes no aparelho físico.

• Objective-C, a linguagem de programação utilizada para aplicativos da

Apple, consiste num conjunto de extensões da linguagem C (baseadas, em

sua maioria, no Smalltalk, uma linguagem orientada a objetos) que

possibilita orientação a objetos. O compilador da Apple é baseado no GCC

e também compila projetos em C e C++.

Custo: nenhum. A Apple disponibiliza as ferramentas gratuitamente,

exigindo apenas um registro;

Vantagens: fora todas as facilidades trazidas pelas ferramentas do pacote

(e o fato de todos os recursos do iPhone serem suportados, claro), há bastante

material de estudo acerca das ferramentas e da programação, além de guias de

como projetar interfaces e exemplos de código, tudo disponibilizado pela Apple.

Sem contar outras ótimas fontes, como as aulas da Stanford University via

iTunes U, livros e os inúmeros fóruns e tutoriais espalhados pela internet;

Desvantagens: necessita de um Mac e Objective-C é uma linguagem de

aprendizado complicado, principalmente por conta das inúmeras bibliotecas e

arquivos utilizados;

Observações: no site da Apple há apenas as versões mais novas de suas

ferramentas (apesar de os links para SDKs antigos não estarem desabilitados),

reforçando sua política de trabalhar pela inovação.

Adobe Flash Professional CS5[10]: software que permite a criação de projetos em

ActionScript 3 e executá-los como aplicativos nativos no iPhone (através de um

Packager específico para iPhone). Necessita também do Flex SDK e do AIR

2.0.1 SDK, disponíveis na página da Adobe.

Custo: $849;

8

Vantagens: não necessita de um Mac para poder desenvolver (não exige a

instalação do SDK da Apple), além de facilitar o trabalho com recursos gráficos;

Desvantagens: por ser uma ferramenta recente (foi lançada em abril deste

ano), possui pouca documentação. Algumas APIs em ActionScript 3 também

possuem limitações ou não são suportadas para iPhone;

Observações: Adobe e Apple mantêm uma relação delicada há anos. Steve

Jobs, CEO da Apple, chegou a publicar uma carta fazendo duras críticas ao

Flash[11] (com relação a desempenho, segurança, gasto da bateria dos

dispositivos, entre outros itens). Em 8 de Abril deste ano, houve uma

modificação do contrato de licença do Programa de Desenvolvedores para

iPhone que bania alguns aplicativos que utilizassem APIs que não fossem as da

Apple, ou seja, os desenvolvedores que utilizassem o Flash encontrariam

dificuldades em disponibilizar seus aplicativos na App Store. A Adobe respondeu

que tiraria o foco dos dispositivos da Apple. Entretanto, no dia 9 de Setembro

também deste ano, a Apple, sob pressão dos desenvolvedores, anunciou que

faria modificações no contrato para deixá-lo mais flexível.

Appcelerator Titanium Mobile[12]: plataforma de desenvolvimento para

plataformas desktop (Windows, Linux e Mac) e móveis (iPhone, Android) que

possui um compilador capaz de criar aplicativos nativos a partir de HTML, CSS e

JavaScript. Suporta todos os itens de interface com o usuário do iPhone (como

botões, switches, views, etc.) e funções como acelerômetro, câmera e GPS.

Custo: nenhum;

Vantagens: além da facilidade em desenvolver em javascript (simples e

legível), suporta suficientes recursos nativos do iPhone e apresenta uma

comunidade de desenvolvedores bastante ativa quanto à troca de informações.

Também possibilita o uso de módulos em Objective-C no código;

Desvantagens: necessita do XCode e SDKs da Apple (e portanto, de um

Mac);

Observações: O Titanium, por utilizar APIs próprias, se enquadra na

mesma problemática do Flash CS5 quanto à aprovação dos aplicativos

submetidos à Apple.

9

Ferramenta escolhida

A ferramenta avaliada como mais adequada às necessidades e restrições do

projeto foi o Titanium. O fluxo de trabalho consiste basicamente em criar o código

em javascript, editando um arquivo .js utilizando softwares como o Adobe

Dreamweaver, Dashcode, etc., fazendo uso das APIs do Titanium, compilá-lo e

verificar seu funcionamento no iPhone Simulator, além de testar no dispositivo físico.

Como dito anteriormente, o uso do Titanium exige as ferramentas oficiais da

Apple instaladas em um computador com Mac OS. Entretanto, por conta do alto

valor do investimento e da exigência inicial do projeto ser a não dependência dos

orientadores e demais professores do curso para conseguir os componentes

necessários, a solução encontrada foi instalar o Mac OS em PCs comuns, prática

que explicaremos na próxima seção.

Hackintosh

Inicialmente pensou-se na utilização de máquinas virtuais (VMware Player e

VirtualBox), primeiro usando a imagem de uma máquina “pronta” (ou seja, que outra

pessoa já havia criado) e um bootloader (EmpireEFI, Darwin), depois criando uma

nova a partir do DVD original e, mais tarde, usando uma distro (dvd original

modificado). Por conta da lentidão e dos problemas do funcionamento das máquinas,

partiu-se para a instalação do Mac OS em dual boot com o Windows 7, sistema

operacional já instalado nos computadores (ou seja, cada SO ficaria em uma

partição do HD).

Como oficialmente o Mac OS deve ser instalado apenas em Macs, a Apple não

fornece qualquer suporte aos “hackintoshes”, ou seja, às instalações em PCs. Logo,

há sérios problemas com compatibilidade como placas de rede, som, vídeo, etc.,

que às vezes podem ser resolvidos através de drivers e kexts (kernel extensions).

No caso deste projeto, um sério caso de incompatibilidade foi a placa de rede de um

dos notebooks, que não era nem mesmo reconhecida pelo sistema operacional (o

problema foi resolvido com a aquisição de um adaptador USB wireless que, por

sorte, tinha drivers que funcionavam). Portanto, os requisitos para tal prática são:

1. Muita pesquisa. Há vários guias pela internet, mas quando há algum

problema (o que acontece com frequência) é necessário caçar informações

por fórums e outras fontes;

2. Não ter medo, porém estar ciente dos riscos, pois são feitas várias

modificações delicadas, que podem trazer danos como a perda de dados;

10

3. Mínima familiaridade com utilização de terminais similares aos do Linux;

4. Bastante paciência e tempo. São necessárias várias tentativas, demoradas

instalações e desinstalações constantes;

5. Um pouco de sorte, por conta da compatibilidade.

Open Data Kit Build

O Open Data Kit Build (ODK) é um software gratuito para a criação de

formulários, com uma interface simples e com suporte aos tipos de questões

necessárias para o projeto. Entretanto, possui problemas no que diz respeito à

maneira como implementa os jumps e no formato de arquivo de saída, que é XML.

Nosso programa utilizava uma lógica onde o jump era função da resposta da

questão atual, enquanto no ODK Build o jump é definido a partir das respostas nas

questões anteriores. Por exemplo: quando na questão 1 (Q1) for dada a resposta A

(Q1 = A), o programa vai direto para a questão 3 (Q3). No nosso app, a informação

“se ‘Q1 = A‟, então „pular para a Q3‟” está ligada à Q1, enquanto no programa

utilizado está conectada à Q3.

Isso se tornou um problema no momento que podem ser criados jumps

múltiplos, i.e. dadas as respostas para duas questões (por exemplo: Q1 = A, Q2 =

B) o programa deve pular para a Q4. Precisaríamos modificar a forma como nosso

app entende a estrutura dos jumps para conseguir implementar essa estrutura, ou

apelar para um aumento substancial na capacidade computacional necessária para

o funcionamento do programa, o que vai contra nossos objetivos.

Esse problema foi resolvido modificando-se a estrutura inicial de jumps, como

comentado no anexo B. Colocamos explicações mais detalhadas sobre as idéias

para contornar o problema e porque escolhemos como solução a de adaptar nosso

código.

11

Software

Nesta seção serão mostrados aspectos relacionados ao software como um

todo: o aplicativo, o servidor e a documentação. Descreveremos as características

já implementadas e comentaremos sobre futuras adições, que serão trabalhadas

com mais detalhes ao final do relatório.

Aplicativo

O app está funcional, podendo sincronizar questionários entre o servidor e o

aparelho sem problemas. Também é possível utilizá-lo para realizar entrevistas e

editar respostas. Ou seja, o app já poderia ser utilizado em pesquisas de campo –

infelizmente ainda precisamos terminar algumas características da criação de

formulários e outros, otimizando esse processo.

Futuras adições ao app são a verificação de consistência de dados

simultaneamente ao preenchimento (e.g.: impedir que “homem grávido” seja

considerada uma entrada consistente), criação de novas opções na aba de

configuração, como escolha do idioma, ativar/desativar verificação de dados, etc. A

respeito da implementação de jumps, que já foi concluída, consultar o anexo B.

De modo geral, acreditamos que o aplicativo está de acordo com o planejado e

obedece ao escopo do projeto.

Site

Nossa idéia era criar todos os programas necessários ao correto

funcionamento do software, como pedido pelo Profº Paulo Menezes: aplicativo para

os smartphones, capacidade de criar formulários para o mesmo e a transferência de

arquivos do smartphone para o computador e do computador para o smartphone,

além da adequação de formatos. Todas essas funcionalidades, exceto a realização

de entrevistas (que é feita nos iPhones/iTouchs) seriam feitas através de um site

comportando a interface que controla os arquivos presentes no servidor, a

conversão de formatos dos arquivos e onde podem ser colocados novos

questionários e retiradas as respostas para posterior análise.

Entretanto, graças à limitação de tempo e prezando pela unificação do nosso

trabalho com o do grupo que mexe com o sistema operacional Android, utilizamos o

ODK Build (seção 3.3). Por isso, só após a criação de formulários que o site entra

em ação, colocando o arquivo XML no servidor e convertendo-o.

12

Por enquanto, o site já possui opções para upload de arquivo XML, conversão

de XML para JSON, passagem dos formulários para o iPhone/iTouch, retorno dos

formulários preenchidos para o servidor e conversão de JSON para CSV, que é o

formato escolhido para a saída do software, por ser lido pela maioria dos programas

de mineração de dados existentes.

Documentação

Para a documentação do software, além do relatório final pedido pela disciplina,

que possuirá as informações de como o projeto foi desenvolvido, também será

criado um manual para o usuário final. O objetivo deste é permitir que dúvidas sejam

tiradas com maior facilidade, evitando que os pesquisadores da FMUSP precisem

nos contatar para isso, além de facilitar o treinamento de novos membros para a

equipe deles.

Vai ser um documento contendo diagramas explicando o fluxo de dados e

como o software se relaciona com o processo deles, de acordo com a figura 1.

Depois, vamos listar e apresentar todas as funcionalidades do site e do app,

ilustrando com screenshots de ambos. Podemos adicionar um capítulo falando

como resolver possíveis falhas no aparelho, etc. Por fim, uma lista de possíveis

melhorias e informações para contato conosco.

13

Figura 1 – Diagrama de processo

Figura 2 – Diagrama da interface

ODK Build

Página Web

Interface

14

Orçamento

Muitas de nossas compras foram de cunho pessoal, não tendo sido feitas

exclusivamente para o projeto. Entretanto, vamos deixar nossa documentação como

um guia para os próximos grupos que quiserem trabalhar com essa plataforma,

portanto optamos por montar um orçamento visando a introdução no mundo de um

desenvolver de apps para produtos da Apple.

Embora existam maneiras de se trabalhar apenas com um Mac usando

simulações, é melhor ter um aparelho onde poderá realizar testes. Também

consideramos a licença de desenvolvedor, que permite a transferência de protótipos

para um iPhone, iTouch ou iPad sem recorrer a métodos ilegais, e também é

necessária para enviar apps à App Store.

Lembramos que o ideal é ter sempre as versões mais atualizadas do sistema

operacional para o Mac e o iPhone/iTouch/iPad, evitando possíveis

incompatibilidades e problemas na obtenção de ferramentas. Consideramos os

valores em dólares para minimizar os efeitos que flutuações de mercado ou

mudanças na (imensa) carga tributária brasileira possam gerar, tornando esse

orçamento desatualizado até o ano que vem. Por fim, colocamos os produtos mais

baratos e sem considerar extras, como HD ampliado, programas, etc.

Mac: pode-se utilizar um Macbook White ($999) ou um Mac Mini ($699).

Figura 3 – Macbook White

15

Figura 4 – Mac Mini

Aparelho: sugerimos o uso de um iPhone 3GS ($99) ou de um iPhone 4 ($199).

Figura 5 – iPhone 3GS

16

Figura 6 – iPhone 4

iOS Developer Program: é a licença para desenvolvedores ($99/ano).

Todos os preços e imagens foram retirados do site oficial da Apple[13].

17

Cronograma

A coordenação da disciplina determinou que fossem consideradas 10 semanas

oficiais de trabalho. Os dias a mais não documentados no cronograma são

considerados “folgas” para mudanças de planos, imprevistos, etc. A seguir

apresenta-se o cronograma inicial, entregue com a inscrição do projeto.

Etapa Semana

1 2 3 4 5 6 7 8 9 10

Estudo de aplicativos existentes x

Definição do aplicativo - plano geral x x

Estudo das ferramentas de desenvolvimento x x x x x

Definição do design do aplicativo x x

Desenvolvimento x x x x

Testes x

Testes com usuários x

Documentação x x x x x x x x x x Figura 7 – Cronograma inicial

Após algumas reuniões, verificamos que era necessário alterar o cronograma

de modo a comportar maior quantidade de testes visando o benefício do usuário

final, além de termos nos adiantado em relação ao inicial. Portanto, apresentamos

aqui o cronograma atual e a descrição de suas etapas, da forma como as

pensamos:

Etapa Semana

1 2 3 4 5 6 7 8 9 10

Estudo de aplicativos existentes x

Definição do aplicativo - plano geral x x

Estudo das ferramentas de desenvolvimento x x x x x

Definição do design do aplicativo x x

Desenvolvimento x x

Testes I x

Testes com usuários I x

Aprimoramento x x x

Testes II x

Testes com usuários II x

Documentação x x x x x x x x x x Figura 8 – Cronograma atual

18

Estudo de aplicativos existentes: pesquisa e estudo dos apps mais vendidos e

usados atualmente;

Definição do aplicativo – plano geral: é o momento em que projetamos o que o

app deve fazer, tendo em vista o que foi discutido no escopo do projeto (seção

2.2);

Estudo das ferramentas de desenvolvimento: pesquisa das ferramentas

disponíveis para desenvolver o aplicativo, avaliando vantagens e desvantagens,

além da viabilidade. Graças às dificuldades previstas e ao pouco conhecimento

inicial sobre o Mac OS, esta atividade foi iniciada o quanto antes, em meados de

julho;

Definição do design do aplicativo: os produtos da Apple são também conhecidos

pelo design diferenciado, portanto a preocupação com este aspecto do aplicativo

é bastante importante;

Desenvolvimento: programação do aplicativo;

Testes I: apesar de também ser uma atividade contínua (parte essencial do

desenvolvimento), decidiu-se reservar uma semana para testes intensivos a fim

de assegurar o correto funcionamento do aplicativo;

Testes com usuários I: etapa criada por conta da grande preocupação com a

aceitação dos usuários. Avalia se o aplicativo é intuitivo, de fácil utilização e

possui design atraente. Será realizado junto da equipe do Profº Paulo Menezes;

Aprimoramento: avaliaremos os resultados dos testes para procurar falhas e

funções que podem ser aperfeiçoadas, inclusive envolvendo mudanças no

design;

Testes II: idêntico ao período inicial de testes, tem como objetivo garantir que as

possíveis mudanças realizadas estão de acordo com o nosso escopo;

Testes com usuários II: verificação final das funções disponíveis;

Documentação: atividade contínua e de grande relevância. Por ser bastante

extensa, foi distribuída por toda a programação.

19

Conclusão

A versão atual do aplicativo está funcional, podendo ser usada para testes. As

modificações faltantes são relacionadas com o site, principalmente no conversor de

XML para JSON. As características presentes no app até o momento são:

Utilização do aplicativo em modo paisagem ou retrato;

Campos de variáveis para texto curto, texto longo, números (teclado numérico),

switch (escolha de uma ou mais alternativas), data e picker (escolha de uma

alternativa);

Gravação das respostas de cada entrevistado sequencialmente no arquivo do

questionário;

Acesso às entrevistas já feitas no próprio programa, com possibilidade de

alteração;

Suporte a infinitos questionários e variáveis (ou o quanto couber na memória);

Suporte a jumps em qualquer tipo de questão;

Interface escura para economia de bateria;

Aba de configuração para a especificação do servidor.

No momento estamos nos concentrando em resolver os problemas de uso,

para que o software como um todo já possa ser utilizado, até o final da disciplina

PSI2222, pela equipe do Profº Paulo Menezes. Algumas de nossas idéias vão,

infelizmente, ser deixadas de lado para cumprirmos o prazo definido. Mas vamos

deixá-las listadas e brevemente comentadas na seção seguinte, caso algum grupo

tenha interesse em continuar esse projeto em 2011. Também acreditamos que é um

tema interessante e pode ser tratado em uma iniciação científica (IC) ou mesmo em

um trabalho de conclusão de curso (TCC), como será tratado na seção seguinte.

20

Trabalhos futuros

Pensamos ser interessante que o software seja totalmente desenvolvido na

Universidade de São Paulo, aqui na Escola Politécnica. Portanto, uma sugestão é,

ao invés de utilizar o ODK Build (seção 3.3), criar um programa integrado ao site

que realize a função de criar formulários. Para tanto, acreditamos que a utilização

do Titanium Desktop[14] é bastante adequada.

Obviamente também serão necessárias revisões no manual e no código de

todo o software para limpar possíveis bugs e facilitar a leitura, além de adicionar

explicações relacionadas a um futuro form builder. Outro upgrade bom é o suporte à

outros idiomas, permitindo que o software seja utilizado mais amplamente. Além

disso, descobrimos que um arquivo em .docx pode ser interpretado como um

arquivo em XML, sendo possível convertê-lo diretamente – o que pode ser útil, visto

que muitas vezes o rascunho do questionário é escrito nesse formato.

Além disso, o Profº Seabra tem vontade de iniciar um projeto junto do Profº

Paulo Menezes em busca de patrocínio de alguma entidade de apoio à pesquisa

para possibilitar o uso generalizado do software desenvolvido na Faculdade de

Medicina. Com isso, serão necessárias pessoas para realizar manutenções e

melhorias constantes, não só no software como em toda a estrutura (smartphones,

servidores, etc).

É uma função que nosso grupo naturalmente receberia. Entretanto, estamos

trabalhando em projetos paralelos, como nossas próprias iniciações científicas,

grupos dos quais fazemos parte, etc, e achamos que é uma boa oportunidade para

outros alunos se envolverem. Dessa forma, podemos nos reunir com eles e explicar

o que foi realizado, inclusive ajudando com os passos iniciais.

Imaginamos que a continuação deste projeto tem potencial para ser tema de

iniciações científicas, envolvendo o detalhamento do projeto de implementação em

larga escala do software, e também de trabalhos de conclusão de curso, com o

estudo de modificações permitindo-o ser usado por outras áreas que não a medicina,

inclusive em outras instituições e países.

21

Referências Bibliográficas

[1] Pequenas empresas, grandes negócios. O mercado de aplicativos para celular cresce sem parar. Fonte: http://twurl.nl/f7xtty Acessado em 14 de setembro de 2010.

[2] Site oficial da Apple. Apple Introduces the New iPhone 3G. Fonte: http://twurl.nl/v24bz3 Acessado em 12 de setembro de 2010.

[3] Info reviews. Os 5 melhores smartphones do Brasil. Fonte:

http://twurl.nl/qplsfj Acessado em 14 de setembro de 2010.

[4] Wired Magazine. The untold story: How the iPhone blew up the wireless

industry. Fonte: http://twurl.nl/1cwdpx Acessado em 14 de setembro de 2010.

[5] The Official Palm Blog. Palm and HP. Fonte: http://twurl.nl/j4c3ds Acessado

em 16 de setembro de 2010.

[6] DataDyne. EpiSurveyor for Windows/Palm. http://twurl.nl/dyn5bn Acessado

em 12 de setembro de 2010.

[7] Site oficial do Sentenza. Fonte: http://twurl.nl/hn46qe Acessado em 16 de

setembro de 2010.

[8] Site oficial do PhoneGap. Fonte: http://twurl.nl/w7cwl0 Acessado em 16 de

setembro de 2010.

[9] Site oficial da Apple. Apple Developer. Fonte: http://twurl.nl/m8iik5

Acessado em 16 de setembro de 2010.

[10] Site oficial da Adobe. Adobe Flash Professional CS5. Fonte:

http://twurl.nl/qygmqd Acessado em 16 de setembro de 2010.

[11] Site oficial da Apple. Thoughts on Flash. Fonte: http://twurl.nl/eumobu

Acessado em 17 de setembro de 2010.

[12] Site oficial da Appcelerator. Fonte: http://twurl.nl/mpqx1q Acessado em 16

de setembro de 2010.

[13] Site oficial da Apple. Fonte: http://twurl.nl/n0ky5z Acessado em 17 de

setembro de 2010.

22

[14] Site oficial da Appcelerator. Titanium Desktop. Fonte: http://twurl.nl/pdx0i7

Acessado em 16 de setembro de 2010.

Anexo A

Neste anexo citaremos as idéias que tivemos para o app. A maioria versou

sobre necessidades estudantis – como organização e acesso à informações do local

de ensino -, ou apenas algo que surgiu no meio de uma noite de insônia.

Tentaremos apresentá-los em ordem cronológica.

Editor de texto otimizado para resumos: uma espécie de NotePad com algumas

funções específicas para criação de tabelas, formas geométricas, equações,

inclusive podendo copiar/colar partes de arquivos PDF e outros. Chegamos à

conclusão de que seria ideal para o iPad;

Organizador (To-do List): queríamos um app que possibilitasse a criação de

lembretes e listas com tarefas para serem feitas, suas necessidades,

observações e datas. Entretanto, descobrimos que já existe um app com essas

características – o iStudiez, disponível na App Store;

Consulta à material técnico: seria um app basicamente de texto, contendo

algumas imagens e possivelmente sites. Teria informação técnica de algum

assunto, permitindo que o usuário pudesse fazer uso dela em seus estudos ou

mesmo trabalho. Temos bons exemplos disso no Tae Kim’s Guide to Learning

Japanese, ótimo auxiliar para estudar gramática japonesa, e o Pró-Química

Online, feito para quem trabalha no setor de emergências. Foi descartado por

ser um apanhado de textos, tendo pouco desafio no lado da programação;

iUSP: app parecido com o iStanford e o MIT Mobile, feito para acessar

informações da universidade. Seria possível ler notícias através de um leitor

RSS, ver mapas, ter uma lista com telefones importantes (Hospital Universitário,

institutos, etc), cardápio on-line dos bandejões, além de possibilidade de

encontrar detalhes sobre as matérias (como no Jupiterweb) e dados de contato

dos professores.

Tivemos mais algumas idéias que surgiram em brainstorms, mas foram pouco

aprofundadas e achamos melhor deixá-las de fora. Vale ressaltar que só

descartamos a idéia do iUSP graças à sugestão do Profº Antônio Carlos Seabra,

tendo sido ela bastante aceita pelo grupo. Seria interessante que os próximos

grupos a trabalharem com esse tema continuem-na – ficaríamos felizes em ajudá-

los.

Anexo B

Neste anexo vamos explicar as maneiras que encontramos de interpretar

jumps no ODK para permitir o total funcionamento de seus questionários em nosso

aplicativo. Também vamos justificar a escolha do método atual.

Primeiramente pensamos em utilizar o campo underlying value, que serve para

modificar o valor registrado na memória ao se responder um formulário, como salvar

“sim” como 1 e “não” como 0. O mesmo não pode ser aproveitado no nosso

programa graças ao fato de todas as variáveis relacionadas com perguntas de

múltipla escolha serem gravadas como números inteiros, indo de 0 até (n – 1), onde

n é o número de alternativas.

Poderíamos ler o número presente nessa string e admitir que é a questão para

a qual o programa deve pular, caso essa seja a resposta escolhida. Claro, há o

problema da equipe envolvida com o sistema operacional Android utilizar esse

campo, mas combinaríamos o uso de uma expressão como “N; > M” ou algo do tipo,

onde N é o underlying value verdadeiro e M é o nosso jump.

Para evitar o uso de expressões para cada jump e a unificação ainda maior

dos questionários, achamos mais conveniente utilizar o campo “relevance”, como o

outro grupo. Foi necessário modificar bastante a lógica dos jumps. Primeiro,

retiramos o vetor de jumps J e criamos um vetor de estados S, de dimensão igual

ao número de perguntas, onde cada entrada é a expressão lógica presente no

underlying value (que admite valor 1 apenas na situação em que a questão deve ser

pulada).

Com isso, definimos que S[i] = 1 significa que a pergunta não deve ser

mostrada e, após cada questão, o aplicativo recalcula os valores de S, sendo

possível controlar os jumps em tempo real. Outra vantagem desse método é que,

uma vez pulada certa pergunta, só é possível vê-la ao modificar a resposta que

desativa sua visualização, evitando preenchimentos acidentais.