universidade de são paulo escola politécnicaacseabra/grad/2222_files/psi2222-2010 iphone.pdf ·...
TRANSCRIPT
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.