Embed Size (px)
Citation preview
UNIVERSIDADE DE LISBOA Faculdade de Ciências
Departamento de Informática
DESENVOLVIMENTO DE DUAS APLICAÇÕES PARA O SISTEMA OPERATIVO GOOGLE
ANDROID
Sérgio André Santos Nunes
RELATÓRIO DE ESTÁGIO
MESTRADO EM ENGENHARIA INFORMÁTICA Especialização em Engenharia de Software
2012
UNIVERSIDADE DE LISBOA Faculdade de Ciências
Departamento de Informática
DESENVOLVIMENTO DE DUAS APLICAÇÕES PARA O SISTEMA OPERATIVO GOOGLE
ANDROID
Sérgio André Santos Nunes
RELATÓRIO DE ESTÁGIO
Trabalho orientado pelo Prof. Doutor Carlos Eduardo Ramos dos Santos Lourenço
e co-orientado por Eng.º Diogo Vitorino
MESTRADO EM ENGENHARIA INFORMÁTICA Especialização em Engenharia de Software
2012
Agradecimentos
Agradeço ao Prof. Carlos Lourenço, da Faculdade de Ciências da Universidade de Lisboa, pela disponibilidade e flexibilidade que demonstrou, ao orientar este projecto.
Agradeço também ao Eng.º Diogo Vitorino, Addition, pela oportunidade que me deu de realizar este projecto e pelo acompanhamento que prestou.
Dedicatória.
i
Resumo
As tecnologias móveis estão, neste momento, em grande evolução, com especial destaque para os telemóveis e outros dispositivos electrónicos móveis. É neste campo que se centra este trabalho.
No mercado das aplicações para dispositivos móveis, começamos agora a ver uma forte competição, com as principais marcas a lutar pelo seu lugar no mercado, fomentando o desenvolvimento de aplicações para o sistema operativo instalado nos dispositivos móveis que produzem. Uma destas marcas é a Google, com o sistema operativo Google Android [1], que está instalado em muitos dos smartphones utilizados hoje em dia, pelo público em geral. Neste esforço de incentivo ao desenvolvimento de aplicações para o Google Android, a Google criou uma loja de aplicações, acessível online por qualquer terminal — Google Play [2] (antigo Android Market) — na qual se pode pesquisar e comprar/descarregar aplicações que serão depois utilizadas em dispositivos com o sistema operativo Android instalado.
A Addition Serviços e Projectos Informáticos, Lda [3] inicia-se no desenvolvimento de aplicações para o sistema operativo Android com duas aplicações simples. A primeira é um utilitário que gere os sons de alerta (de chamada e de mensagem escrita) do dispositivo, tendo em conta o meio ambiente circundante.
A segunda é uma aplicação que pretende mostrar as interacções, ao nível das chamadas e mensagens escritas, num gráfico que pretende ser uma forma simples de visualizar a comunicação do utilizador num período de tempo.
Este documento descreve o planeamento e desenvolvimento destas duas aplicações, e, no caso da primeira aplicação, também o seu lançamento e divulgação.
Palavras-chave: tecnologias, móveis, android, smartphone
ii
iii
Abstract
Great developments are being observed in mobile technologies today, with special focus on mobile phones and other mobile electronic devices. This is where this paper is focused.
In the mobile applications market, we now begin to see a strong competition, with the leading brands fighting for their place in the market, encouraging the development of applications for the operating system installed on their mobile device. One such brand is Google, bringing the Google Android [1] operating system, which is installed in many of the smartphones used today, by the general public. In this effort to encourage the development of applications for Google Android, Google has created an application store, online accessible by any terminal — Google Play [2] (before was known as Android Market) — where you can search and buy/download applications which are then used in Android devices.
Addition Serviços e Projectos Informáticos, Lda [3] begins developing applications for the Android operating system with two simple applications. The first one is a utility that manages the alert sounds (calls and text messages) of the device, taking into account the surrounding environment. The second is an application that aims to show the interactions (calls and test messages) on a chart that purports to be a simple way to view user communication over a period of time.
This document describes the planning and development of these two applications, plus the release and promotion stage of the first one.
Keywords: mobile, technologies, android, smartphone
iv
v
Conteúdo
Capítulo 1 Introdução .............................................................................................1
1.1 Motivação .....................................................................................................1
1.2 Objectivos.....................................................................................................1
1.3 Contribuições................................................................................................2
1.4 Estrutura do documento................................................................................2
Capítulo 2 Trabalho Relacionado ...........................................................................1
2.1 Gestor de Alertas Sonoros ............................................................................1
2.2 Visualizador de Comunicação ......................................................................2
Capítulo 3 Objectivos .............................................................................................3
3.1 Gestor de Alertas Sonoros ............................................................................3
3.1.1 Nome, versões e forma de distribuição: ................................................3
3.1.2 Requisitos funcionais e não-funcionais: ................................................4
3.1.3 Resultados finais....................................................................................6
3.1.4 As diferenças entre o desenho e o resultado final ...............................10
3.1.5 Publicidade como receita da versão Free ............................................11
3.2 Visualizador de Comunicação ....................................................................13
3.2.1 Nome e forma de distribuição .............................................................13
3.2.2 Requisitos funcionais e não-funcionais ...............................................13
3.2.3 Resultados finais..................................................................................14
Capítulo 4 O Trabalho realizado na Addition .......................................................19
4.1 Aplicação Droid inPocket ..........................................................................19
4.1.1 Diferenças entre o planeamento e a execução .....................................21
4.2 Aplicação Today .........................................................................................22
4.2.1 Diferenças entre o planeamento e a execução .....................................22
Capítulo 5 Desenho e Implementação ..................................................................23
5.1 Desenho da aplicação Droid inPocket........................................................24
5.2 Pormenores de implementação da aplicação Droid inPocket ....................27
vi
5.2.1 Algoritmo utilizado para tratar os dados do sensor de proximidade ...28
5.2.2 Algoritmo utilizado para definir um volume de toque compatível com o nível de ruído........................................................................................................29
5.2.3 Uma nova funcionalidade decidida no momento de implementação ..30
5.3 Interface gráfica da aplicação Today ..........................................................31
5.4 Controlo de qualidade do algoritmo de geração dos gráficos produzidos..31
5.5 Mecanismo de verificação da licença de utilização....................................32
5.5.1 Restrições na aplicação Droid inPocket Premium ..............................33
5.5.2 Restrições na aplicação Today.............................................................33
Capítulo 6 Lançamento da aplicação Droid inPocket ..........................................35
6.1 Instalações e Desinstalações Diárias e Instalações Activas........................36
6.2 Campanha publicitária como forma de divulgação ....................................39
6.3 Mudança ligeira nas curvas de instalações e desinstalações ......................41
Capítulo 7 Conclusões ..........................................................................................42
7.1 Desenvolvimento de aplicações para o Android.........................................42
7.2 Lançamento de aplicações Android ............................................................43
Bibliografia 44
vii
viii
Lista de Figuras Figura 1– Ecrã inicial da aplicação Droid inPocket..........................................................6
Figura 2 – Ecrã do modo inPocket ....................................................................................7
Figura 3 – Ecrã do modo outPocket ..................................................................................8
Figura 4 – Ecrã do modo headPhones ..............................................................................9
Figura 5 - Ecrã about.......................................................................................................10
Figura 6 - Interface gráfica inicial da aplicação Droid inPocket ....................................11
Figura 7 - Interface da versão Free, com espaço publicitário.........................................12
Figura 8 - Ecrão inicial da aplicação Today ....................................................................15
Figura 9 - Ecrã com menu da aplicação Today ...............................................................15
Figura 10 - Ecrã com informações sobre a aplicação Today ..........................................16
Figura 11 - Ecrã com menu de exportação da aplicação Today......................................17
Figura 12 - Ecrã com menu de mudança de tipo de período da aplicação Today ...........17
Figura 13 - Live Wallpaper definido pela aplicação Today ............................................18
Figura 14 - Diagrama de classes da aplicação Droid inPocket .......................................25
Figura 15 - Exemplo da aplicação Today sem licença de utilização...............................34
Figura 16 - Instalações durante 2011 (cumulativo).........................................................35
Figura 17 - Instalações durante 2012 (cumulativo).........................................................36
Figura 18 - Instalações vs desinstalações (não cumulativo) ...........................................37
Figura 19 - Instalações activas no tempo (não cumulativo)............................................38
Figura 20 - Médias cumulativas de percentagem de instalações vs percentagem de desinstalações..........................................................................................................39
Figura 21 - Instalações dadas pela campanha publicitária ..............................................40
Figura 22 - Médias cumulativas de percentagem de instalações vs percentagem de desinstalações após o lançamento da versão final da aplicação..............................41
ix
x
1
Capítulo 1 Introdução
1.1 Motivação Observa-se actualmente um grande desenvolvimento na área das tecnologias
móveis, começando estas a assumir um papel preponderante na forma como as pessoas se relacionam, não só com as chamadas tecnologias de informação, mas também com os dispositivos electrónicos em geral.
Começa-se a perceber uma cada vez maior adesão a estas tecnologias, em detrimento dos tradicionais computadores pessoais, o que implica também uma mudança na forma como se utiliza o software. Agora, as aplicações para o público geral têm que ser criadas para os smartphones ou tablets, etc., ou pelo menos devem ter uma versão que seja compatível com estes dispositivos.
Nenhuma empresa de desenvolvimento de software, pode dar-se ao luxo de ignorar esta revolução, sob pena de não adquirir know how em tempo útil, perdendo competitividade num futuro muito próximo. A Addition não é excepção. As duas aplicações tratadas neste relatório são o seu primeiro esforço de experimentação, e também de reconhecimento do mercado das aplicações para o sistema operativo Google Android.
1.2 Objectivos Os objectivos deste trabalho são, como já foi dito atrás, o planeamento e
desenvolvimento de duas aplicações para o sistema operativo Google Android, bem como o lançamento e divulgação de uma delas.
A primeira aplicação, a que chamaremos de “Gestor de Alertas Sonoros”, deve fazer uma gestão automática dos alertas sonoros de que o dispositivo dispõe. Esta gestão deve ter em conta as condições que rodeiam o dispositivo, desde o nível de ruído que o rodeia, passando pela posição em que este se encontra e acabando na forma como este está guardado. Para além disto, existe também uma segunda versão desta aplicação, que tem como um dos seus objectivos, a leitura automática de mensagens escritas, recorrendo para isso à síntese de voz.
2
A segunda aplicação , que será referida como “Visualizador de Comunicação”, pretende mostrar, num gráfico de fácil compreensão, a interacção — em termos de chamadas e mensagens escritas — que o utilizador teve com o dispositivo num determinado período. A forma como os registos das chamadas e das menagens escritas são mostrados, deve ser simples, de modo a que, com uma rápida observação, o utilizador se aperceba facilmente, por exemplo, se aquele foi um dia em que utilizou o telemóvel para tratar de mais assuntos do foro pessoal ou do foro profissional. Esta aplicação foi encomendada à Addition por uma empresa de design de interfaces denominada CADA[4], pelo que os requisitos, tanto funcionais, como não funcionais, foram definidos por um colectivo externo à Addition.
1.3 Contribuições Este relatório aborda o desenvolvimento de duas aplicações para o sistema
operativo Google Android.
O desenvolvimento de aplicações para dispositivos móveis tem restrições, tanto ao nível do hardware em que correm, como ao nível do desenho de interfaces gráficas compatíveis com uma forma não tradicional de interagir com os dispositivos. Este relatório centra-se nestas questões, entre outros assuntos.
Por fim é abordado o lançamento de um produto da Addition, neste caso, uma das aplicações móveis desenvolvidas no âmbito deste projecto, e são tiradas conclusões quando ao sucesso/insucesso da aplicação.
1.4 Estrutura do documento Este documento está organizado da seguinte forma:
• Capítulo 2 – Descrição de algumas aplicações que tentam tratar os assuntos endereçados no ponto 1.2.
• Capítulo 3 – Descrição do objectivo do trabalho. Descrição das aplicações.
• Capítulo 4 – Explicação do trabalho realizado antes e durante o estágio. Discussão e diferenciação entre o planeamento inicial e o desenrolar do trabalho.
• Capítulo 5 – Descrição pormenorizada do desenho e implementação de ambas as aplicações.
• Capítulo 6 – Descrição e discussão do lançamento e resultados da aplicação “Gestor de Alertas Sonoros”.
• Capítulo 7 – Conclusões.
1
Capítulo 2 Trabalho Relacionado
Durante a fase de planeamento das aplicações, foi feito um esforço para descobrir aplicações que abordassem os mesmos problemas.
Embora coexistam no mercado aplicações muito parecidas entre si, não era isso que se pretendia. Pretendia-se sim, de alguma forma, preencher um espaço desocupado de forma a trazer algo de novo. Foi o que se conseguiu em ambas as aplicações, como veremos adiante.
De todas as aplicações testadas, destacam-se algumas que se aproximam dos objectivos do trabalho desenvolvido, embora não os atingindo na totalidade.
2.1 Gestor de Alertas Sonoros Smart Ring Control [5] – Aplicação que pretende controlar o volume de toque do
dispositivo, podendo o utilizador definir diferentes configurações de volume para diferentes condições/locais em que o dispositivo esteja. Em relação a esta aplicação, o maior factor de distinção é que o Gestor de Alertas Sonoros pretende retirar um pouco flexibilidade na utilização, com o objectivo de a tornar mais simples, melhorando a curva de aprendizagem.
FoxyRing: Smart Ringtone [6] – Aplicação que adapta o volume de toque às condições de ruído do meio ambiente. É também possível associar configurações de volume a localizações geográficas. Aqui, a aplicação a desenvolver, tem como principal diferença, o modo inPocket, que detecta se o dispositivo está ou não dentro do bolso do utilizador.
SmartPhoneComfort [7] – Esta aplicação permite associar configurações de volume às posições em que o dispositivo pode estar. São detectadas 4 posições: ecrã para baixo, ecrã para cima, vertical (modo automóvel) e outras (manuseamento, etc...). A aplicação a desenvolver distingue-se desta principalmente pelo modo outPocket, que permite adaptar o volume de toque às condições de som ambiente.
Os modos da aplicação Gestor de Alertas Sonoros referidos acima, serão explicados em maior detalhe no Capítulo 3.
2
2.2 Visualizador de Comunicação Dado que a definição dos requisitos desta aplicação não esteve a cargo da
Addition, a pesquisa de aplicações na área de actuação do Visualizador de Comunicação não foi tão intensa como no Gestor de Alertas Sonoros.
Ainda assim, pode-se avançar que não foi encontrada nenhuma aplicação no mercado que mostre a comunicação feita no dispositivo da mesma forma que o Visualizador de Comunicação.
A título de exemplo, existe uma aplicação Call Log Manager Pro [8], que também lida com o histórico de chamadas do dispositivo, permitindo o rastreamento de chamadas no histórico, visualização de estatísticas e gestão das entradas (apagar, exportar para ficheiro, etc.).
É importante estabelecer que esta aplicação não permite a criação de gráficos nem inclui as mensagens recebidas/enviadas, funcionalidades que estão incluídas no Visualizador de Comunicação, como será descrito no Capítulo 3.
3
Capítulo 3 Objectivos
Neste capítulo descreve-se o que se pretendia atingir com cada aplicação. São apresentados os requisitos funcionais e não funcionais de cada aplicação e são descritos os resultados finais, permitindo assim uma comparação entre planeamento e produto final.
3.1 Gestor de Alertas Sonoros Esta aplicação pretende ser um gestor dos alertas sonoros do telemóvel em que está
instalada, substituindo completamente as funcionalidades de gestão do sistema operativo, por alguns automatismos descritos adiante.
Para uma melhor organização da interface, as funcionalidades da aplicação estão divididas em três modos:
• Modo inPocket: Permite comutar entre modo de vibração e modo sonoro consoante o telemóvel esteja dentro ou fora do bolso (ou outro recipiente fechado), ou virado para baixo sobre uma superfície lisa.
• Modo outPocket: Permite o ajuste automático do volume de toque, tendo em conta as condições de ruído no momento do alerta sonoro. Para além disto existe ainda a possibilidade de definir um período diário de silêncio.
• Modo headPhones: Com duas funcionalidades distintas, destina-se a utilizadores que usem auscultadores ou auriculares (para ouvir música, por exemplo). A primeira funcionalidade consiste na leitura em voz alta das mensagens recebidas. A segunda é a leitura em voz alta do nome/número do contacto no momento em que está a ser recebida uma chamada.
3.1.1 Nome, versões e forma de distribuição:
A aplicação que, por conveniência de escrita, foi até agora chamada de Gestor de Alertas Sonoros chama-se na realidade Droid inPocket sendo este nome alusivo a um dos modos descritos anteriormente.
4
Por uma questão estratégica da Addition, a foram feitas duas versões da mesma aplicação — Free e Premium — que diferem em algumas funcionalidades e na fonte de receita.
A versão Premium [9], comercializada no Google Play [10] pelo preço de 1,54 €, tem todas as funcionalidades descritas nos três modos e não terá publicidade como fonte de receita.
A versão Free [11] é grátis e distribuída também através do Google Play, mas tem como fonte de receita um espaço reservado para publicidade e não tem todas as funcionalidades presentes na versão Premium. No modo outPocket, não permite definir um período diário de silêncio. Não tem o modo headPhones.
Elaborando um pouco mais esta estratégia da Addition, podemos justifica-la pela quantidade de aplicações grátis que existem no mercado Android. Segundo o relatório de Junho de 2010 [12] da Distimo [13], nessa altura 57% das aplicações do Android Market eram grátis. Assim, a intenção é que os utilizadores que estão dispostos a comprar a aplicação, tenham a possibilidade de experimentar uma versão grátis da mesma, que embora não tenha o mesmo nível de funcionalidade, permite travar conhecimento com as funcionalidades centrais.
3.1.2 Requisitos funcionais e não-funcionais:
Houveram algumas alterações relativamente aos requisitos funcionais e não-funcionais apresentados no Relatório Preliminar. Abaixo apresenta-se a versão final dos requisitos funcionais (sobre a qual foi desenvolvida a versão final da aplicação):
1 – A aplicação deve ser um serviço, pelo que uma vez inicializada, esta deve estar constantemente a correr e deve ser inicializada automaticamente quando o dispositivo é ligado.
2 – A aplicação deve ter os seguintes três modos activáveis:
2.1 – Modo inPocket: Sempre que o dispositivo esteja dentro do bolso do utilizador (ou outro recipiente fechado) ou com o ecrã virado para baixo, o alerta utilizado deve ser a vibração.
2.1.2 – Deve ser adicionada a este modo uma segunda funcionalidade que permita que sempre que a aplicação “detecte” que o dispositivo está dentro do bolso do utilizador, ou com o ecrã virado para baixo, deve ser dado um pequeno sinal de vibração para avisar o utilizador que o alerta será dado em vibração.
2.2 – Modo outPocket: Sempre que o dispositivo não esteja nem no bolso do utilizador nem com o ecrã virado para baixo, o volume de toque deve ser adaptado às condições de ruído que circundam o dispositivo.
5
2.2.1 – A este modo deve ser acrescentada uma funcionalidade que permita definir um período diário de silêncio, em que o tipo de alerta é sempre vibração.
2.3 – Modo headPhones: Sempre que este modo esteja activo, e que o utilizador tenha auscultadores ou auriculares ligados ao dispositivo, todas as mensagens escritas que cheguem sejam lidas em voz alta, utilizando as capacidades de síntese de voz do sistema operativo Android.
2.3.1 – A este modo deve ser adicionada uma funcionalidade que, nas mesmas condições, permita ler em voz alta o nome do contacto das chamadas recebidas.
3 – A aplicação deve ser desactivável a qualquer momento pelo utilizador.
4 – Quando activa, a aplicação estar acessível através da Status Bar [14] do sistema operativo.
Quanto a requisitos não funcionais temos os seguintes:
1 – A aplicação deve ser o mais simples de operar possível. Isto implica não ter um grande número de opções de configuração, reduzindo assim a complexidade para o utilizador.
2 – A interface gráfica deve ser simples e clara o suficiente para que o utilizador saiba facilmente, quais os modos que tem activos e qual a forma de os activar/desactivar.
3 – A interface gráfica deve ter um impacto moderado, mas não pode deixar o utilizador indiferente.
4 – A interface gráfica deve apresentar um ecrã onde se incluem os contactos da empresa responsável pelo seu desenvolvimento.
Em relação à definição inicial dos requisitos (presente no relatório preliminar) podemos destacar as seguintes diferenças:
1 – Passam a existir três modos em vez dos dois inicialmente previstos.
2 – O modo headPhones não estava de todo previsto na primeira definição dos requisitos.
3 – Não estava previsto que o utilizador pudesse definir um período diário de silêncio.
5 – Não estava previsto um ecrã com os contactos da empresa que desenvolve a aplicação.
6
3.1.3 Resultados finais
O desenvolvimento da aplicação Droid inPocket está concluído.
Visto que as diferenças entre as versões Premium e Free são apenas ao nível da funcionalidade e que, as funcionalidades da versão Free são um subconjunto daquelas que estão presentes na versão Premium, podemos a partir daqui assumir que, salvo indicação contraria, nos estamos sempre a referir à versão Premium.
Passando a uma descrição pormenorizada da aplicação, começamos pelo seu ecrã inicial:
Figura 1– Ecrã inicial da aplicação Droid inPocket
Como podemos ver, existem quatro botões que permitem activar ou desactivar a aplicação (o primeiro a contar de cima) e os seus três modos.
Do lado direito dos botões que activam/desactivam os modos da aplicação, temos o nome de cada modo. Quando o utilizador toca na zona que vai do final do botão até ao final do sinal de maior (>), é encaminhado para o ecrã do modo correspondente.
Por baixo dos três modos vemos o atalho (about) que leva o utilizador ao ecrã que contem os contactos da empresa responsável pelo desenvolvimento.
7
Por último temos uma área de estatísticas em que mostra a percentagem de tempo em que o dispositivo esteve dentro do bolso (desde que a aplicação foi lançada pela última vez) e o nível de ruído no momento em que o ecrã inicial foi mostrado ao utilizador.
Esta última funcionalidade não está presente na última versão dos requisitos. Foi inserida um pouco à margem destes, mas com a noção de que não interfere em nada com as restantes funcionalidade ou qualidades da aplicação.
Passando ao ecrã do modo inPocket:
Figura 2 – Ecrã do modo inPocket
Neste ecrã vemos, em cima e à esquerda, o botão que permite activar e desactivar o modo.
Por baixo temos uma pequena explicação das suas funcionalidades. Ainda mais abaixo temos duas caixas de selecção que dizem respeito a duas funcionalidades distintas:
1 – A primeira está nos requisitos funcionais. Quando activa, permite ao utilizador receber um pequeno alerta vibratório quando o dispositivo detecta que entro/saiu do bolso. Deve ser utilizada apenas durante um período de adaptação, de forma a que o utilizador perceba a forma como funciona este modo.
8
2 – A segunda funcionalidade, embora não esteja prevista na versão final dos requisitos funcionais, aparece porque, durante o desenvolvimento e teste, se percebeu que existem algumas diferenças ao nível do hardware entre os dispositivos móveis onde a aplicação pode ser instalada. Não adiantando muito mais sobre as razões da sua existência para já (serão explicadas no capítulo 5), podemos apenas dizer que quando activa, a aplicação utiliza o sensor de aceleração para detectar a posição em que o dispositivo tem o ecrã virado para baixo.
Esta última opção apenas deve estar activada se for necessária, ou seja, se a aplicação não conseguir detectar que o dispositivo tem o ecrã voltado para baixo sem recorrer ao sensor de aceleração. Isto é algo que depende do hardware presente no dispositivo.
Continuando, temos o modo outPocket:
Figura 3 – Ecrã do modo outPocket
Para além do botão que activa ou desactiva o modo e de uma pequena explicação, vemos uma caixa de selecção e duas barras horizontais.
Começando pelas barras horizontais, estas existem como forma de demonstrar o funcionamento do modo ao utilizador. A primeira mostra em tempo real o nível de ruído
9
detectado pelo dispositivo. A segunda mostra o volume de alerta calculado pela aplicação para aquele nível de ruído.
A cima destas, a caixa de selecção permite activar ou desactivar o período diário de silêncio. Se estiver desactivado, ao tocar na caixa, o utilizador precisa depois de introduzir a hora de inicio e de fim do período, para o poder activar.
O último ecrã de modo corresponde ao modo headPhones:
Figura 4 – Ecrã do modo headPhones
As duas caixas de selecção activam ou desactivam as funcionalidades descritas anteriormente — leitura em voz alta de mensagens escritas e dos contactos nas chamadas recebidas.
10
Por último temos o ecrã com os contactos da empresa responsável pelo desenvolvimento:
Figura 5 - Ecrã about
3.1.4 As diferenças entre o desenho e o resultado final
Existem diferenças significativas entre o que ficou previsto na fase de desenho e análise de requisitos e o resultado final. Diferenças essas que se concentram essencialmente na forma como o utilizador acede às funcionalidades, ou seja, na interface gráfica.
Para além disto, foi também adicionada uma pequena funcionalidade ao modo inPocket, descrita atrás, e sobre a qual ainda não nos detemos, por ser necessário entrar em pormenores que não dizem respeito a este capítulo.
Ainda assim, podemos concluir que os desvios em relação aos requisitos não atingem as funcionalidades centrais, nem inviabilizam nenhum dos requisitos não-funcionais.
No relatório preliminar estava presente uma figura, que recuperamos em seguida, que representava a interface gráfica inicialmente prevista para esta aplicação.
11
Figura 6 - Interface gráfica inicial da aplicação Droid inPocket
Como podemos ver, a interface era muito mais simples, mas também muito menos flexível.
Em discussão com o Eng.º Diogo Vitorino (responsável pelo desenvolvimento de software da Addition), chegou-se à conclusão que seria necessário tornar a interface mais apelativa ao utilizador tipo dos sistemas Android, isto é, a pessoas com conhecimentos de tecnologias móveis acima da média.
Desta decisão estratégica resultou uma interface que dá um controlo mais fino das funcionalidades, permitindo activar ou desactivar cada uma delas a gosto do utilizador, para além de ser também mais amigável, uma vez que contém mais e melhores textos explicativos de cada opção que o utilizador pode tomar.
A concretização da interface foi feita em conjunto com o responsável pelas artes gráficas da Addition — Pedro Rufino [15] — seguindo as mais recentes orientações de estilo para aplicações Android [16], ao nível dos estilos gráficos, ícones, caixas de selecção, botões, etc.
3.1.5 Publicidade como receita da versão Free
Como já foi dito atrás, a versão Free é suportada através de um pequeno espaço publicitário incluído no final de cada ecrã da aplicação.
Esta é uma forma recorrente de financiamento das aplicações móveis, normalmente utilizada em versões grátis.
12
Figura 7 - Interface da versão Free, com espaço publicitário
A publicidade incluída na interface vem através de um serviço que por sua vez é cliente de várias redes de anúncios para aplicações móveis. Esse serviço chama-se Mobclix [17], e permite a instalação (recorrendo a uma API[18]) do dito espaço publicitário.
Cada clique (no caso mais comum das aplicações móveis, um clique é um toque no anúncio) representa um valor monetário variável, que normalmente se situa algures entre os 0.01 US$ e 0.10 US$.
À primeira vista, estes valores podem parecer irrisórios e, sem mais análise, pode-se ficar com a ideia de que esta é uma má forma de financiamento. Ideia que pode rapidamente ser desmentida se tivermos em conta alguns números. Em 2010, a então independente Mobclix foi adquirida pela Velti [19] (empresa do mesmo ramo). Nessa altura, a rede Mobclix mostrava mais de 3280 anúncios por segundo, atingindo os 8,5 mil milhões de anúncios por mês [20].
13
3.2 Visualizador de Comunicação Esta aplicação pretende ser um visualizador da comunicação feita através do
dispositivo em que está instalada.
De uma forma simplista, pretende-se gerar um gráfico representativo de um período temporal, em que cada evento de comunicação — envio/recepção de chamadas ou mensagens escritas — é representado através de um símbolo diferente. Para alem disto, pretende-se também distinguir os vários eventos consoante o seu destinatário/remetente.
A Addition não é responsável pelo desenho da aplicação, apenas pela sua implementação. O desenho ficou a cargo da empresa que encomendou a aplicação, que entregou uma especificação de requisitos, que a Addition ficou responsável por cumprir. Desta forma, a este capítulo fica um pouco mais abreviado no que diz respeito ao visualizador de comunicação.
3.2.1 Nome e forma de distribuição
Pela mesma razão evocada para a aplicação Droid inPocket, até este momento temo-nos referido s esta aplicação como Visualizador de Comunicação, mas na verdade, esta chama-se Today.
Como já foi dito atrás, a distribuição da aplicação Today é feita, tal como no caso a aplicação Droid inPocket, através do mercado de aplicações móveis Google Play [].
3.2.2 Requisitos funcionais e não-funcionais
Esta análise foi desenvolvida pela CADA e a Addition não tem responsabilidade sobre ela. Ainda assim, a forma aqui apresentada não é a mesma que aquela que a informação trocada entre as duas empresas assumia. Esta é uma adaptação fiel mas resumida de todo um processo de troca de informação que ocorreu antes do aluno entrar na Addition.
Começando pelos requisitos funcionais:
1 – A aplicação deve poder navegar numa linha temporal, podendo o período de visualização ser de um dia ou de uma semana (este deve ser configurável pelo utilizador).
2 – Dado um período temporal a aplicação deve produzir (e mostrar) um gráfico que mostre claramente a comunicação feita com o dispositivo, durante o período escolhido.
3 – Cada contacto (entende-se por contacto, um número de telefone guardado na agenda do dispositivo) deve ser representado por uma cor num determinado dia. Contactos
14
diferentes têm cores diferentes. Comunicações diferentes do mesmo contacto têm cores iguais.
4 – A comunicação que chega ao dispositivo (chamadas recebida e mensagens escritas recebidas) e a comunicação que sai deste (chamadas feitas e mensagens escritas enviadas) devem aparecer em zonas distintas do gráfico.
5 – Devem existir símbolos diferentes para chamadas e mensagens escritas. As chamadas recebidas não atendidas também devem ser diferenciáveis das restantes.
6 – O tamanho dos símbolos deve reflectir a intensidade da comunicação que representam. Crescem com a duração da chamada ou o tamanho da mensagem escrita.
7 – A linha temporal deve ser navegável entre o passado e o presente, mantendo sempre, para o passado, os gráficos inalteráveis.
8 – Qualquer gráfico deve poder ser exportado para uma imagem a guardar na memória persistente do dispositivo.
9 – Qualquer gráfico deve poder ser partilhado, recorrendo às redes sociais que o utilizador tenha configuradas no dispositivo.
10 – Deve ser possível ao utilizador fazer zoom em qualquer gráfico, sendo que este lhe deve ser apresentado inicialmente sem qualquer efeito de zoom.
11 – O gráfico deve ser navegável, de forma a que, para cada símbolo, seja possível, ao utilizador, saber qual o contacto e a data/hora da comunicação.
12 – Deve ser possível criar um wallpaper a partir do gráfico gerado pela aplicação. Este wallpaper, deve conter a informação mais actualizada.
Também os requisitos não funcionais foram definidos pela CADA:
1 – A aplicação deve ter uma forma de operar intuitiva, de modo a que os seus botões sejam auto-explicáveis, sem que haja texto associado.
2 – Os gráficos produzidos devem ter um aspecto harmonioso. Para alem disso, devem mostrar a quantidade de comunicação do dia, sem que para isso seja necessária uma observação detalhada.
3.2.3 Resultados finais
Também a interface gráfica da aplicação foi definida pela CADA. O resultado da implementação, feita pela Addition, das directrizes dadas, é o que se pode ver nas próximas cinco imagens.
15
Figura 8 - Ecrão inicial da aplicação Today
Como podemos ver, existem vários símbolos, que mudam em forma, tamanho e cor. A lógica subjacente a estas diferenças será explicada mais à frente.
Figura 9 - Ecrã com menu da aplicação Today
Neste ecrã podemos ver o menu da aplicação:
• Topo temos o período a que diz respeito o gráfico. • Do lado esquerdo temos dois botões que têm a função de aumentar e diminuir o
zoom.
16
• No fundo temos uma barra de botões que têm como função (da esquerda para a direita):
o Mostrar um ecrã com informações sobre a aplicação. o Mostrar um menu que permite exportar o gráfico para um ficheiro de
imagem, ou partilha-lo através dos meios disponíveis no Android (e-mail, redes sociais, etc.).
o Mostrar um menu que permite comutar entre um período de visualização de um dia ou de uma semana.
o Ir para o período de comunicação anterior (se existir). o Ir para o período de comunicação seguinte (se existir).
Figura 10 - Ecrã com informações sobre a aplicação Today
Este ecrã contem informações que ajudam o utilizador a entender o modo de funcionamento da aplicação:
• Uma descrição dos objectivos da aplicação • Uma explicação da forma como estão organizados os gráficos gerados • Uma lista dos símbolos e seus significados • Uma lista das funcionalidades da aplicação • Uma declaração sobre os termos de privacidade (a aplicação não guarda dados
sobre a comunicação, apenas os lê) • Os contactos da equipa de desenvolvimento
17
Figura 11 - Ecrã com menu de exportação da aplicação Today
Figura 12 - Ecrã com menu de mudança de tipo de período da aplicação Today
As figuras 11 e 12 dizem respeito aos menus de exportação do gráfico e de mudança de tipo de período (dia ou semana).
A figura 13 mostra o Live Wallpaper [21] que a aplicação permite definir para o dispositivo. Este wallpaper é o gráfico que representa a comunicação feita até ao momento, dentro do período actual.
18
Figura 13 - Live Wallpaper definido pela aplicação Today
19
Capítulo 4 O Trabalho realizado na Addition
O aluno esteve envolvido em todas as fases de desenvolvimento de ambas as aplicações que se deram depois da sua entrada na empresa receptora do estágio.
Como já aqui foi dito, o aluno não tomou todas as decisões sozinho, mas sim em discussão com quem está responsável pelo desenvolvimento de software da Addition — Eng.º Diogo Vitorino — e, pontualmente, com o responsável pelas artes gráficas — Pedro Rufino.
4.1 Aplicação Droid inPocket Esta aplicação, descrita no capítulo 3, nasceu antes do aluno ter entrado na empresa, através da ideia de um ex-colaborador — Filipe Uva.
A ideia inicial consistia em incluir apenas os modos inPocket e outPocket numa primeira versão grátis (financiada através de publicidade) da aplicação. Depois, dependendo da forma como corresse o seu lançamento, poder-se-ia, ou não, fazer uma versão paga na qual se incluiria uma funcionalidade de leitura das mensagens recebidas pelo utilizador.
À data da decisão de avançar para o mercado com esta aplicação (Setembro de 2011), havia um protótipo da aplicação, já com alguma funcionalidade, nomeadamente a utilização de sensores que permite saber se o dispositivo está ou não dentro do bolso, e um mecanismo que analisa as condições de ruído do meio ambiente.
Foi nesta altura que o aluno entrou para o projecto, e após análise de todo o material existente, propôs ao Eng.º Diogo Vitorino, que fosse rescrito todo o código da aplicação, com a intenção de criar uma primeira versão da aplicação passível de entrar no mercado, algo que começou a fazer de imediato.
Esta decisão prendia-se com o facto de que o aluno não tinha, até à data, acompanhado o projecto, e como tal, demoraria mais tempo a inteirar-se de todas as especificidades do código, do que a reescrever toda a aplicação.
Um dos benefícios desta nova implementação foi a transformação da arquitectura de software numa arquitectura multi fio de execução, na qual as análises do meio ambiente
20
em que o dispositivo está inserido são executadas em paralelo. A nova arquitectura será explicada em detalhe mais à frente.
No início de Dezembro de 2011 foi feita a submissão desta primeira versão totalmente funcional no Google Play, altura em que já estavam previstas mudanças significativas:
• Uma nova interface com o utilizador • A inclusão na interface, de um ecrã com os contactos da empresa • A criação de duas versões Free e Premium • A inclusão das funcionalidades descritas anteriormente na versão Premium
Em Janeiro deu-se início à concretização das mudanças previstas, começando pela análise e desenho das novas funcionalidades, respeitantes à versão Premium. Recuperando os requisitos funcionais que lhes dizem respeito:
2.3 – Modo headPhones: Sempre que este modo esteja activo, e que o utilizador tenha auscultadores ou auriculares ligados ao dispositivo, todas as mensagens escritas que cheguem sejam lidas em voz alta, utilizando as capacidades de síntese de voz do sistema operativo Android.
2.3.1 – A este modo deve ser adicionada uma funcionalidade que, nas mesmas condições, permita ler em voz alta o nome do contacto das chamadas recebidas.
Estas novas funcionalidades demoraram cerca de um mês a desenhar e implementar pelo aluno.
No início de Março o aluno começou então a definir a nova interface gráfica, em conjunto com Pedro Rufino e com o Eng.º Diogo Vitorino.
Recuperando os requisitos que lhe dizem respeito:
2 – A interface gráfica deve ser simples e clara o suficiente para que o utilizador saiba facilmente, quais os modos que tem activos e qual a forma de os activar/desactivar.
3 – A interface gráfica deve ter um impacto moderado, mas não pode deixar o utilizador indiferente.
4 – A interface gráfica deve apresentar um ecrã onde se incluem os contactos da empresa responsável pelo seu desenvolvimento.
Desta discussão nasceu a nova interface (descrita no capítulo 3), que passou a ser integrada pelo aluno na aplicação, processo que estava concluído no início de Abril.
Por motivos que vão para lá do âmbito deste relatório, após a conclusão do desenvolvimento, houve uma interrupção no curso do projecto, o que fez com que a versão Free fosse lançada a 8 de Maio de 2012 e a versão Premium a 11 de Maio.
21
4.1.1 Diferenças entre o planeamento e a execução
Nem todas as tarefas do projecto foram finalizadas de acordo com os prazos estabelecidos no relatório preliminar. Recordando a lista de tarefas e respectivos prazos:
1. Até ao final de Novembro de 2011:
Comportamento da aplicação Gestor de Alertas Sonoros e respectivos testes.
Submissão no Android Market.
3. Até ao final de Janeiro de 2012:
Definição e implementação de uma forma de divulgação da aplicação Gestor de Alertas Sonoros.
4. Até ao final de Fevereiro de 2012:
Definição e análise dos requisitos da nova versão da aplicação Gestor de Alertas Sonoros.
5. Até ao final de Março de 2012:
Implementação da nova versão da aplicação Gestor de Alertas Sonoros.
6. Até ao final de Abril de 2012:
Lançamento no mercado da nova versão da aplicação Gestor de Alertas Sonoros.
7. Até ao final de Maio de 2012:
Escrita do documento que constitui o relatório de estágio, descrevendo toda a fase de análise de requisitos e desenvolvimento das aplicações descritas.
Visto que a tarefa 6 começou com mais que um mês de atraso, foi necessário executa-la em paralelo com a tarefa 7.
Embora pareça praticamente imediata, a tarefa 6 não o é, visto que o lançamento de uma aplicação, na óptica da Addition, é mais do que a sua submissão num qualquer meio de distribuição.
Outra das diferenças que se podem apontar é a tarefa 3 ter sido atrasada e executada apenas no início de Maio, quando estava planeado que estivesse concluída no final de Janeiro. Isto aconteceu porque se percebeu que fazia pouco sentido tratar de assuntos de lançamento, antes de a aplicação estar completamente desenvolvida.
Imediatamente após o lançamento, existe todo um processo de divulgação e monitorização, que não só demora tempo, mas também é exigente na definição da estratégia a adoptar. Este processo será descrito mais à frente.
22
4.2 Aplicação Today A aplicação Today teve dois responsáveis pelo seu desenvolvimento — Filipe Uva e Luís Loureiro — antes de chegar às mãos do aluno.
Foi em Outubro de 2011 que o aluno entrou para este projecto. Nessa altura a aplicação já tinha algo de funcional, no que diz respeito à pesquisa e organização da informação sobre a comunicação feita através do dispositivo. Também a geração de gráficos estava praticamente feita.
O trabalho do aluno neste projecto esteve muito ligado à interface com o utilizador e à garantia de correcção dos gráficos apresentados, algo que envolveu uma detalhada inspecção do código fonte da aplicação, bem como um período de testes alargado.
Para além disto, e visto que a CADA pretendia vender a aplicação através do Google Play, foi necessário implementar um mecanismo de verificação de licenças de utilização, que permite verificar se dada instalação da aplicação está licenciada pelo Google Play.
Toda a intervenção do aluno descrita acima foi feita em discussão permanente como Eng.º Diogo Vitorino, e foi concluída a 10 de Janeiro de 2012.
4.2.1 Diferenças entre o planeamento e a execução
Recordando o planeamento respeitante à aplicação Today:
2. Até ao final de Dezembro de 2011:
Requisito funcional número três da aplicação Visualizador de Comunicação.
Testes.
Acabamentos ao nível da interface da aplicação Visualizador de Comunicação.
Podemos notar alguma derrapagem (menos que duas semanas) no prazo de conclusão da tarefa 2, algo que pode ser explicado por ter havido alguma dificuldade em lidar com o mecanismo de verificação de licenças do Google Play.
23
Capítulo 5 Desenho e Implementação
As aplicações para o sistema operativo Android seguem uma arquitectura comum, pois são desenvolvidas com base numa Framework [22], desenvolvida pela Google, com o objectivo de facilitar e reduzir o tempo de desenvolvimento das aplicações [23].
Os constituintes base de uma aplicação Android são os seguintes:
• Application: Representa a aplicação. Toda a interacção com o sistema operativo é feita através deste componente.
• Activity: Representa um ecrã da aplicação. A interacção com o utilizador é feita através deste componente.
• Service: Representa um serviço, ou seja, uma tarefa que uma aplicação precise de executar durante longos períodos de tempo.
• Broadcast Receiver: Um componente que permite à aplicação ficar à escuta de eventos criados pelo sistema operativo, por outras aplicações ou pela própria aplicação.
Existem mais componentes na framework, sobre os quais não nos debruçaremos, já que não foram utilizados no desenvolvimento de nenhuma das aplicações.
Para além destes componentes básicos, há que destacar também a forma como se desenham interfaces para aplicações Android.
Cada objecto da interface é representado por um componente do tipo View. Os vários componentes do tipo View são agrupados em componentes do tipo View Group [24]. Assim, o layout de um ecrã de uma aplicação tende a ser constituído por um ou mais View Groups, cada um contendo um ou mais Views ou View Groups. Estes elementos são normalmente descritos em ficheiros XML, que depois a Framework trata de traduzir de forma a criar a interface propriamente dita.
Neste capítulo descreve-se o desenho e implementação da aplicação Droid inPocket. É descrita também a forma como foi implementada a interface da aplicação Today, o controlo de qualidade de parte do algoritmo de geração dos gráficos produzidos e a implementação do mecanismo de verificação da licença de utilização da aplicação.
24
5.1 Desenho da aplicação Droid inPocket Como foi dito acima, a arquitectura desta aplicação segue os desígnios da framework para desenvolvimento de aplicações Android, bem como a utilização de fios de execução paralelos para as tarefas de interacção com o meio ambiente. Na próxima figura vemos o diagrama de classes.
25
Figura 14 - Diagrama de classes da aplicação Droid inPocket
26
Descrevendo um pouco o desenho da aplicação, podemos olhar com mais pormenor para algumas das classes presentes no diagrama da figura 14:
• PocketDroidActivity: Esta é uma classe que estende a classe Activity da Framework, e que portanto, representa um ecrã da aplicação. Para além disto é abstracta, definindo apenas alguns comportamentos básicos que todas as suas subclasses devem ter, como por exemplo, mostrar ou esconder elementos da interface, desenhar um determinado layout no ecrã, etc.
• MainActivity: Uma subclasse de PocketDroidActivity. Deve representar o primeiro ecrã da aplicação, e é abstracta porque se trata de um dos poucos pontos de diferenciação entre as versões Premium e Free. As suas subclasses são FreeActivity e PremiumActivity.
• PocketDroidService: Sendo uma subclasse da classe de framework Service, esta é responsável por manter a aplicação a correr, mesmo quando nenhum dos seus ecrãs está visível. Este serviço mantém um BroadcastReceiver com o objectivo de receber eventos de telefonia e de alteração das definições de som pelo utilizador. Para além disto, recebe também eventos dos sensores de proximidade e acelerómetro.
• PocketDroidBroadcast: Como foi dito acima, o objectivo desta classe é tratar os eventos de telefonia e de alteração de definições de som pelo utilizador. Assim, e para poder receber estes eventos, esta classe estende a classe de framework BroadcastReceiver, que uma vez inicializada e registados os eventos que deve receber, é capaz apanhar os eventos mediante um callback no método onReceive, ao qual é passado um parâmetro do tipo Intent que contém informações sobre o evento. Os eventos tratados por esta classe são os seguintes:
o Mudança de estado da telefonia. Recepção de chamadas, início e finalização de chamadas provocam a difusão deste evento pelo sistema operativo.
o Recepção de mensagens escritas. o Mudança do estado do alerta sonoro. Evento difundido quando as
preferências de alertas sonoros do dispositivo são alteradas, tanto pelo utilizador como por uma qualquer aplicação, pelo que é necessário distinguir os dois casos.
• PocketDroidStatus: Esta é a classe que mantém a maior parte da informação necessária ao funcionamento da aplicação. Conforme se pode ver pelo diagrama da figura 14, guarda informação sobre os modos activos e respectivas preferências, o estado de verificação de licença de utilização para a versão Premium (na versão Free este estado é falso por defeito), e ainda os últimos valores obtidos pelos sensores de proximidade e acelerómetro.
27
Visto que esta classe é acedida por várias outras em simultâneo, optou-se por aplicar o padrão de desenho Singleton [25], para garantir que a informação alimentada e consumida é a mesma para todos produtores e consumidores. Ainda pelo mesmo motivo, e por o sistema ter múltiplos fios de execução, esta classe protege o acesso aos seus métodos não privados com um Lock [26], de forma a garantir a consistência dos seus valores de retorno.
• PocketDroidTask: Esta classe tem como objectivo definir o comportamento base das suas subclasses, que são as tarefas executadas em paralelo pela aplicação. Mais concretamente, define a forma como deve ser passada informação para dentro da tarefa e dada a ordem de execução num só método.
• ProximityListenerTask: Sendo uma subclasse de PocketDroidTask, esta tarefa é lançada quando o sensor de proximidade retorna um valor. Mais à frente, explica-se o algoritmo de detecção de utilizado para detectar se o dispositivo se encontra dentro do bolso.
• AccelerometerListenerTask: Esta classe é responsável por verificar a posição em que se encontra o telemóvel, de modo a saber qual o alerta sonoro a aplicar (vibração ou toque).
• ListenTask: Sempre que seja preciso avaliar as condições de ruído do meio ambiente, é lançada uma tarefa ListenTask. Esta é responsável por avaliar as condições de ruído e actualizar as preferências de alertas sonoros do dispositivo de acordo com o valor obtido. Mais à frente será explicado o algoritmo utilizado para este efeito.
• ContactNameReader e SMSReader: Estas duas classes são chamadas para ler em voz alta o contacto de uma chamada recebida ou o contacto e o conteúdo de uma mensagem recebida. Utilizam o serviço TextToSpeech do sistema operativo Android [27] para o efeito.
5.2 Pormenores de implementação da aplicação Droid inPocket
A framework de desenvolvimento de aplicações Android está definida em linguagem de programação Java, o que facilita e aligeira bastante a tarefa de implementação da aplicação, visto que existem muitas opções na biblioteca da máquina virtual, para implementar fios de execução e protecções de sincronização.
Em seguida destacamos as opções de implementação mais importantes.
28
5.2.1 Algoritmo utilizado para tratar os dados do sensor de proximidade
O sensor de proximidade é utilizado para detectar se o dispositivo está ou não no bolso do utilizador.
A ideia base seria, periodicamente, verificar o valor que este retorna (normalmente tem apenas um conjunto de dois valores possíveis: perto ou longe), e se o retorno fosse perto, considerava-se que o dispositivo estava dentro do bolso. Caso contrario considerar-se-ia que o dispositivo estaria fora do bolso.
Na verdade o que a framework permite é implementar a interface SensorEventListener [28], e registar a implementação como receptora dos eventos do sensor pretendido, através do método onSensorChanged(Sensor sensor, int accuracy).
A opção tomada foi lançar uma Thread Java [29], por cada valor recebido do sensor de proximidade e proteger o método de detecção com o Lock [30] comum a todas as Threads. Abaixo temos o algoritmo desta detecção (no valor de retorno do sensor, admitimos que o valor booleano verdadeiro significa perto): detect (boolean value): inOutLock.lock() if(status.isTransitioning() and
value=status.hasProximitySensorChanged()): status.cancelProximityTimer() status.setNotTransitioning() else: toggleNearFar(value) inOutLock.unLock() toggleNearFar(boolean value): status.setTransitioning() if(status.isProximityTimerRunnging()): status.cancelProximityTimer() var newTimerTask:=newTimerTask{ run(): inOutLock.lock() status.setNotTransitioning() status.setProximitySensorChanged(value) if(value): status.setNear() else: status.setFar() status.nullProximityTimer() inOutLock.unlock() checkinOutPocket()
} status.scheduleNewProximityTask(newProximityTask, TRANSISITON_TIME)
À primeira vista estes artifícios podem parecer demasiado complicados para uma simples detecção de um obstáculo à frente do sensor de proximidade, mas na verdade o que se pretende aqui fazer é mais que isso.
29
O sensor de proximidade é reactivo, tanto a um bolso, como a uma mão que inadvertidamente o utilizador lhe põe à frente e, como tal, não queremos que o sistema “se deixe enganar” tão facilmente. É aqui que entra o conceito de transição.
Sempre que o valor do sensor for actualizado é chamada a rotina detect, e esta verifica se o sistema está em transição.
Se estiver em transição e o valor actual for diferente do último e perto, ou então, igual ao último e longe, conclui-se que o caso é um “falso alarme” e a transição pode ser descartada.
Caso contrario dá-se início a uma nova transição, o que implica, com um atraso t, lançar uma nova tarefa paralela, que anula alguma eventual tarefa anterior do mesmo tipo, e define como valor de proximidade o valor recebido pela tarefa que a lançou.
O atraso t é o valor de afinação deste algoritmo, já que representa o tempo de transição em que a aplicação precisará de estar constantemente a detectar um objecto perto do dispositivo, sem interrupções, para que o considere “dentro do bolso”.
A rotina checkInOutPocket() verifica o valor definido em setNear() ou setFar() para decidir se considera que o dispositivo está dentro ou fora do bolso.
5.2.2 Algoritmo utilizado para definir um volume de toque compatível com o nível de ruído
O principal objectivo do modo outPocket é fazer com que o dispositivo toque baixo se o ruído do meio ambiente for baixo e que tente ser audível no caso de se encontrar num meio ruidoso.
Em seguida mostra-se o algoritmo utilizado para fazer este ajuste de volume: adjustVolume(recorder : AudioRecorder) : int var buffer := new short[BUFFER_SIZE] recorder.startRecording(buffer) var amp := listen(recorder,buffer) return maximum(amp*MAX_RING_VOLUME/MAX_SHORT_VALUE,1) listen (recorder : AudioRecorder, buffer : short[]) : short var min:=0
var max:=0 for (var i:=0 , i < buffer.length , i++) var val:=buffer[i] if(max=0 or val>max)
Max:=val if(min=0 or val<min) min:=val return absoluteValue(max-min)
Este algoritmo, estruturalmente menos elaborado, é executado apenas quando é preciso ajustar o volume de toque. Assim, há que ter cuidado com a sua complexidade.
30
Quando é recebida uma chamada/mensagem escrita e o dispositivo vai tocar, o volume de toque é posto a zero, momentaneamente, para que o mesmo possa ser ajustado sem interferências. Se este processo for demasiado lento, o que acontece é que a chamada pode terminar entretanto.
Explicando um pouco melhor o algoritmo, o que se faz aqui é obter uma amostra do som ambiente, gravando para um buffer de tamanho BUFFER_SIZE, o qual é depois percorrido com o objectivo de achar o seu máximo e o seu mínimo.
O valor absoluto (abs) da subtracção destes dois valores é a amplitude máxima registada na amostra de som obtida. O valor máximo de amplitude registável pelo dispositivo é o valor máximo do tipo de dados short.
Depois basta aplicar uma regra de três simples (a amplitude máxima está para o volume máximo de toque assim como a amplitude máxima medida está para o volume a definir), de forma a relacionar estes dois valores, e daí obter um valor de volume de toque.
O tempo de gravação é dado pelo tamanho do buffer de gravação sendo que os pormenores de inicialização do objecto AudioRecord [31] não são aqui descritos.
5.2.3 Uma nova funcionalidade decidida no momento de implementação
No final da implementação da aplicação Droid inPocket, no momento da transição para a fase de testes, percebeu-se que o sensor de proximidade funciona de formas diferentes em dispositivos diferentes.
Em alguns dispositivos, este sensor apenas detecta superfícies de determinados materiais, têxteis, por exemplo, não detectando superfícies demasiado lisas, como plástico ou vidro.
Já noutros dispositivos, o sensor de proximidade detecta qualquer superfície, incluindo vidro não pintado, pelo que, nestes casos se dispensa o uso do acelerómetro para verificar se o dispositivo tem o ecrã voltado para baixo.
Assim, e porque o sensor de aceleração, tendo uma precisão elevada, tem uma taxa de actualização elevada também, percebeu-se que nos casos em que não é imprescindível, é um gasto desnecessário e não desprezível em termos de tempo de processador utilizado pela aplicação e, consequentemente, de bateria.
Concluiu-se então que seria benéfico para os utilizadores dispor de uma opção em que podem desactivar a utilização deste sensor, uma vez que a funcionalidade a que se destina está garantida pelo sensor de proximidade, nos casos descritos no parágrafo anterior.
31
Daqui nasceu a funcionalidade “Use accelerometer sensor”, comum a ambas as versões e acessível através do ecrã do modo inPocket.
5.3 Interface gráfica da aplicação Today O desenho desta interface foi feito pela CADA, cabendo à Addition apenas a tarefa de a concretizar. Quando o aluno chegou ao projecto, parte deste trabalho estava feito, e a aplicação já estava utilizável.
Ainda assim, a CADA acabou por pedir várias modificações, que couberam ao aluno realizar:
• Ao nível dos controlos do navegador de tempo — botões que permitem a navegação entre gráficos — e do navegador de eventos — controlo que permite a navegação nos eventos de cada gráfico.
• Nos menus de selecção de tipo de período — dia ou semana — e de forma de exportação — imagem ou partilha através de redes sociais.
• No aspecto gráfico de todos os botões da aplicação.
5.4 Controlo de qualidade do algoritmo de geração dos gráficos produzidos Quando o aluno chegou ao projecto, tinha acabado de ser descoberta uma incongruência na atribuição das cores aos eventos representados nos gráficos.
Recordado o requisito funcional número 3:
3 – Cada contacto (entende-se por contacto, um número de telefone guardado na agenda do dispositivo) deve ser representado por uma cor num determinado dia. Contactos diferentes têm cores diferentes. Comunicações diferentes do mesmo contacto têm cores iguais.
Este requisito era totalmente cumprido para o período mais actual, mas para os anteriores, o que acontecia era que as cores dos contactos mudavam de cada vez que entrava um novo evento no gráfico mais recente.
O que se pretende é que, uma vez definida a cor de um contacto num determinado período de tempo — algo que é feito através de uma palete de 72 cores, que é repetida a cada 72 contactos — esta se mantenha independentemente do número de eventos e/ou períodos posteriores.
Para corrigir este problema, foi necessário rever todo mecanismo de procura de informação de eventos de comunicação (descoberta de eventos no tempo e respectiva
32
associação a contactos), conseguindo-se fazer uma triagem e reduzir o problema ao algoritmo que atribui as cores aos eventos de cada gráfico.
Cada vez que é gerado um gráfico, é necessário descobrir os eventos para aquele período de tempo e, para uma correcta atribuição de cores, é necessário saber qual o ponto de partida, ou seja, qual primeiro evento do primeiro gráfico gerado pela aplicação: variável P, ponto de partida.
Era aqui que residia o erro, pois esta variável P não era respeitada quando se gerava o gráfico do período actual. Estava-se a utilizar a primeira cor da palete e a actualizar o valor da variável com o último contacto do gráfico actual. Ao actualizar a variável P com um valor errado, o que acontecia era que se estragava a informação que o algoritmo de cálculo das cores iria utilizar, para atribuir a cor aos contactos de eventos passados.
A solução, como é óbvio, foi apenas utilizar a primeira cor da palete, se o gráfico actual for o primeiro a ser gerado pela aplicação. Também apenas neste caso se define o valor da variável P. A partir daí, existirá sempre um ponto de partida para o cálculo de cores, seja ele passado ou futuro (é futuro quando se calcula um gráfico anterior ao ponto de partida).
5.5 Mecanismo de verificação da licença de utilização Este mecanismo foi implementado tanto na aplicação Today, como na versão Premium da aplicação Droid inPocket.
A framewok disponibiliza um esqueleto do mecanismo de verificação de licenças de utilização do Google Play [32].
Este mecanismo, dada uma chave, fornecida pelo Google Play para cada aplicação paga, verifica se o utilizador comprou uma licença de utilização da aplicação. O resultado desta verificação é dado pelo callback de um de três métodos, diferentes, para os casos de licença válida, inválida, ou erro na verificação.
O que é recomendado fazer, na documentação da framework, em cada um dos casos é:
• Licença válida: Permitir o acesso do utilizador a todas as funcionalidades da aplicação.
• Licença inválida: Restringir de alguma forma a utilização de algumas ou todas as funcionalidades da aplicação.
• Erro na verificação: Considerar a aplicação como não licenciada e aplicar a politica de licença inválida.
Os dois primeiros casos são pacíficos e as politicas sugeridas parecem-nos acertadas. Já no caso de erro de verificação, as coisas se tornam um pouco mais complexas.
33
A primeira tentação é de facto seguir a politica sugerida, mas após um olhar mais atento para a forma como a verificação funciona, percebemos que esta está dependente de uma conexão à internet para poder ser executada.
Desta forma, seguir a politica sugerida significa restringir o acesso à aplicação a todos os utilizadores que não tenham conexão à internet no momento da verificação. Se é mau para quem desenvolve que hajam utilizadores a usar a aplicação sem licença, é inaceitável restringir o acesso a quem a tenha comprado.
Com um pouco de leitura da documentação deste mecanismo, chega-se à conclusão de que é feita cache da resposta da validação da licença, mas não é elaborado em que casos. Se a resposta “erro de verificação” ficar em cache, este é um efeito ainda mais nefasto, já que não é dada outra oportunidade de verificação enquanto a resposta estiver em cache, algo que também não é quantificado na documentação.
Por estas razões, foi decidido, na versão Premium da aplicação Droid inPocket, não seguir a politica sugerida no caso de erro de verificação. Nesse caso permite-se o acesso total à aplicação, na esperança que da próxima vez que for feita uma verificação já exista conexão à internet.
5.5.1 Restrições na aplicação Droid inPocket Premium
A politica de restrição no caso da versão Premium não licenciada, é a transformação da aplicação na versão Free, ou seja, retirar-lhe apenas as funcionalidades Premium e passar a incluir um espaço publicitário em cada ecrã da aplicação.
Dado que as aplicações apenas diferem entre si no ponto da verificação da licença — a versão Premium verifica-a enquanto a versão Free não o faz — para concretizar esta politica, basta guardar o valor da verificação da licença quando esta é feita, e depois consultar sempre este valor antes de executar qualquer funcionalidade Premium.
5.5.2 Restrições na aplicação Today
Esta aplicação é um pouco menos restritiva quando não licenciada. Após discussão com a CADA, decidiu-se que, quando a verificação da licença tem como resultado “Licença inválida”, é adicionada a cada gráfico a palavra “Unlicensed!”, de forma a informar o utilizador que a cópia que possui não está licenciada.
É de notar que esta palavra aparece mesmo nos gráficos exportados e no Live Wallpaper disponibilizado pela aplicação.
34
Figura 15 - Exemplo da aplicação Today sem licença de utilização
35
Capítulo 6 Lançamento da aplicação Droid
inPocket
Esta aplicação foi lançada pela primeira vez no Google Play (na altura chamado de Google Market) em Novembro de 2010.
A versão da aplicação incluída neste lançamento era um protótipo minimamente funcional, mas ainda pouco estável e com problemas recorrentes ao nível do consumo excessivo de bateria e de inconsistências na interface com o utilizador.
Ainda assim, observou-se alguma adesão por parte dos utilizadores, de uma forma até algo inesperada, dada a curva observada no gráfico de Instalações vs. Tempo:
Figura 16 - Instalações durante 2011 (cumulativo)
É de notar que, para além do lançamento no mercado, nada mais foi feito para divulgar a aplicação e que, portanto, é difícil explicar o que causou este aumento repentino de utilizadores. Ainda mais difícil de explicar se torna, se a isto adicionarmos o facto de que este crescimento não se mostrou consistente e que pouco depois praticamente desapareceu, como podemos ver no gráfico seguinte que inclui apenas o ano de 2012.
0
200
400
600
800
1000
1200
1400
36
Figura 17 - Instalações durante 2012 (cumulativo)
Neste gráfico podemos notar que o crescimento do número de instalações ainda se tornou mais lento após o início de Janeiro. A esta data seguiu-se um período de alguns meses de crescimento muito baixo, até meados de Maio.
A 11 de Maio foi lançada a versão final e a 14 de Maio foi iniciada uma campanha publicitária que ainda está a decorrer e que será explicada mais à frente. Podemos notar desde já os efeitos desta campanha no número de instalações, vendo-se um grande crescimento a partir da altura em que esta começou.
Nota 1: Todos os dados apresentados neste capítulo dizem respeito à versão Free, uma vez que à data da escrita deste documento, a versão Premium tinha apenas duas instalações, número claramente insuficiente para uma análise.
Nota 2: Os dados utilizados neste capítulo dizem respeito ao período desde o lançamento da aplicação — 27 de Novembro de 2011 — até ao dia 2 de Junho.
6.1 Instalações e Desinstalações Diárias e Instalações Activas Uma das métricas mais importantes para quem pretende desenvolver uma
aplicação que agrade ao público é o número de instalações activas, ou seja, o número de utilizadores que tem a aplicação instalada no seu dispositivo, num determinado momento. A seguir vemos o gráfico da evolução desta métrica.
1250
1450
1650
1850
2050
2250
2450
1-‐Jan
8-‐Jan
15-‐Jan
22-‐Jan
29-‐Jan
5-‐Feb
12-‐Feb
19-‐Feb
26-‐Feb
4-‐Mar
11-‐Mar
18-‐Mar
25-‐Mar
1-‐Apr
8-‐Apr
15-‐Apr
22-‐Apr
29-‐Apr
6-‐May
13-‐May
20-‐May
27-‐May
37
0
20
40
60
80
100
120
140
160
180
200
27-‐Nov
4-‐Dec
11-‐Dec
18-‐Dec
25-‐Dec
1-‐Jan
8-‐Jan
15-‐Jan
22-‐Jan
29-‐Jan
5-‐Feb
12-‐Feb
19-‐Feb
26-‐Feb
4-‐Mar
11-‐Mar
18-‐Mar
25-‐Mar
1-‐Apr
8-‐Apr
15-‐Apr
22-‐Apr
29-‐Apr
6-‐May
13-‐May
20-‐May
27-‐May
Instalações diárias (não acumulativo) Desinstalações diárias (não acumulativo)
Figura 18 - Instalações vs desinstalações (não cumulativo)
Como seria de esperar, quanto maior é o número de instalações, maior é o número de desinstalações. Ainda assim o número de desinstalações é demasiado grande, chegando em alguns casos a ser superior ao número de instalações.
Uma das razões para este efeito poderia ser o facto da aplicação ter sido lançada numa versão protótipo, ainda algo instável. Algo que é facilmente desmentido com o facto de que o rácio de instalações/desinstalações se mantém depois do lançamento da versão final, já estável, e até com mais funcionalidades.
Para além disto, é de realçar que é muito difícil de explicar o facto de não haver uma estabilidade mínima o nível do número de instalações/desinstalações diárias. Os picos que se vêm no gráfico até ao mês de Maio não coincidem com nenhum evento de que se tenha conhecimento.
Especulando um pouco sobre este assunto, podemos até assumir que a instabilidade que se observa entre o final de Dezembro e o início de Janeiro de 2011, possa ter a ver com um período de férias para muita gente, no qual, eventualmente, os utilizadores estejam mais receptivos à instalação de aplicações. Esta possível explicação não se aplica ao maior pico de instalações, que se deu entre o final de Novembro e o início de Dezembro de 2011.
Outra métrica interessante é o número de instalações activas (que também pode ser obtida relacionado instalações e desinstalações diárias). Este é o grande objectivo de
38
quem desenvolve aplicações gratuitas, principalmente se estas forem financiadas através de publicidade, como é o caso da versão Free.
Figura 19 - Instalações activas no tempo (não cumulativo)
Olhando para este gráfico consegue-se perceber que, se o número de instalações diárias não é favorável, o número de instalações activas é ainda menos encorajador.
Depois do período de crescimento inesperado entre Novembro de 2011 e Janeiro de 2012, o número de instalações activas veio sempre a decair até ao começo da campanha publicitária em Maio de 2012.
Comparando este gráfico com o da figura 18, que mostra o número de instalações e desinstalações diárias, percebemos que esta tendência foi revertida em Maio, não à custa da diminuição do rácio de desinstalações, mas à custa de publicidade, ou seja, à custa da subida do número de instalações.
Importa então perceber como evoluíram no tempo as instalações e desinstalações diárias. Para isto calcularam-se as médias acumuladas da percentagem de instalações e de desinstalações no total de transacções diárias (o total de transacções diárias é a soma das instalações e das desinstalações efectuadas em determinado dia). O próximo gráfico mostra essa evolução.
0
50
100
150
200
250
300
350
400
450
27-‐Nov 27-‐Dec 27-‐Jan 27-‐Feb 27-‐Mar 27-‐Apr 27-‐May
39
0.00%
10.00%
20.00%
30.00%
40.00%
50.00%
60.00%
70.00%
80.00%
90.00%
100.00%
27-‐Nov 27-‐Dec 27-‐Jan 27-‐Feb 27-‐Mar 27-‐Apr 27-‐May
Média de desinstalações (acumulativo) Média de instalações (acumulativo)
Figura 20 - Médias cumulativas de percentagem de instalações vs percentagem de desinstalações
Após o período referido atrás como de instabilidade percebe-se que a tendência é que as desinstalações tenham uma média acumulada de cerca de 58% e as instalações de 38%. Este é talvez o sinal mais evidente de que a aplicação Droid inPocket não teve o sucesso esperado, na medida em que para alem de um eventual problema em divulgar a primeira versão da aplicação, os utilizadores a quem esta chegou acabaram por a desinstalar, na sua maioria.
Pode o leitor questionar-se sobre a razão pela qual foi utilizada um artifício tão complicado para comparar as instalações com as desinstalações. De facto, à primeira vista, parece algo rebuscado, mas há que ter em atenção o facto de que, embora saibamos que no dia D foram feitas i instalações e d desinstalações, não sabemos em que dia foram feitas as instalações que correspondem às desinstalações do dia D. Por este motivo, para ver uma tendência, precisamos de acumular estes valores.
6.2 Campanha publicitária como forma de divulgação Como forma de divulgar a aplicação decidiu-se fazer uma campanha publicitária
através da internet. De entre as várias opções disponíveis, optou-se pela solução oferecida pelo website AppBrain [33].
Este website é um espelho do Google Play, na medida em que mostra as aplicações que lá estão disponíveis, mas com a sua própria organização e sistema de pesquisa. Como solução de publicidade, oferece lugares destacados no website para as aplicações em campanha.
40
0
10
20
30
40
50
60
70
14-‐May
15-‐May
16-‐May
17-‐May
18-‐May
19-‐May
20-‐May
21-‐May
22-‐May
23-‐May
24-‐May
25-‐May
26-‐May
27-‐May
28-‐May
29-‐May
30-‐May
31-‐May
1-‐Jun
2-‐Jun
O ponto diferenciador entre esta e outras soluções que existem em inúmeros outros websites do mesmo género, é a forma de cobrança desses mesmos lugares de destaque. Enquanto a maioria cobra ao tempo ou ao clique, o AppBrain apenas cobra quando a aplicação é efectivamente instalada pelo utilizador que clicou no anúncio. Esta solução tem, pelo menos, a vantagem de se saber de antemão quantas instalações se conseguem com determinada quantia em dinheiro.
Como já foi dito atrás, a campanha publicitária começou dia 14 de Maio de 2012 e ainda está a decorrer. Até ao dia 2 de Junho de 2012, já tinha garantido 496 novas instalações.
Figura 21 - Instalações dadas pela campanha publicitária
Como se pode ver pelo gráfico, o número de instalações é bastante instável, mas de facto o AppBrain não dá garantias nenhumas para além de que apenas cobra por cada instalação e não por cada clique. Em particular não dá garantias quanto ao número de visualizações do anúncio, nem quanto ao número de instalações por período de tempo.
Os efeitos desta campanha já foram vistos em parte no capítulo 6.1, em termos de número total de instalações também de instalações activas, pelo que não repetiremos aqui essa informação.
Há porém um detalhe que não foi explorado quanto às médias acumuladas das percentagens de instalações e desinstalações — gráfico da figura 20. Esse detalhe poderá estar relacionado tanto com a publicidade, como com o lançamento da versão final. É o que veremos adiante.
41
35.00%
40.00%
45.00%
50.00%
55.00%
60.00%
11-‐May
12-‐May
13-‐May
14-‐May
15-‐May
16-‐May
17-‐May
18-‐May
19-‐May
20-‐May
21-‐May
22-‐May
23-‐May
24-‐May
25-‐May
26-‐May
27-‐May
28-‐May
29-‐May
30-‐May
31-‐May
1-‐Jun
2-‐Jun
Desinstalações Instalações
6.3 Mudança ligeira nas curvas de instalações e desinstalações
Olhando para o gráfico da figura 20, a aplicação parece estar condenada ao fracasso, por força do grande impacto que uma média acumulada de 58% de desinstalações terá nas suas instalações activas.
A previsão piora se tivermos em conta que o lançamento da versão final da aplicação (bastante mais estável e sem os recorrentes problemas de bateria e inconsistências ao nível da interface) parece não ter efeito nesta questão.
A verdade é que um olhar mais atento sobre este gráfico, em particular sobre o período que vai desde o lançamento da versão final até ao dia 2 de Junho, revela que podemos estar perante uma mudança nesta questão, que poderá salvar a aplicação do fracasso.
Figura 22 - Médias cumulativas de percentagem de instalações vs percentagem de desinstalações após o lançamento da versão final da aplicação
Um olhar atento sobre este gráfico permite perceber uma tendência de subida da média cumulativa da percentagem de instalações e uma descida da média acumulativa da percentagem de desinstalações. A manter-se, esta tendência pode, a seu tempo, tornar a aplicação viável, garantindo uma subida do número de instalações activas.
Para isto poderá estar a contribuir tanto o lançamento da versão final, na medida em que há um ganho de qualidade relativamente ao protótipo da primeira versão, como a campanha publicitária, na medida em que poderá estar a divulgar a aplicação junto de utilizadores mais interessados nesta aplicação.
42
Capítulo 7 Conclusões
Após a conclusão deste projecto podem-se tirar algumas conclusões, quer ao nível do desenvolvimento de aplicações para o sistema operativo Google Android, quer ao nível do lançamento destes produtos no mercado.
7.1 Desenvolvimento de aplicações para o Android Começando pelo desenvolvimento, é unânime dizer que a framework de
desenvolvimento de aplicações para este sistema operativo é algo que realmente agiliza este processo e facilita bastante a tarefa de quem o faz.
Todos os recursos do sistema operativo estão modelados de forma a que sejam fáceis de aceder, e também, a tornar mais fácil a implementação das tarefas mais comuns.
Também a linguagem de programação disponibilizada — Java — é um ponto a favor da framework, na medida em que a orientação a objectos é, como sabemos, uma grande ajuda, tanto em tempo de desenvolvimento, como em tempo de implementação dos sistemas. Para além disso, temos também a extensa biblioteca disponibilizada com a generalidade das implementações desta linguagem, sendo que esta não é excepção.
Quanto à concretização das interfaces gráficas das aplicações, também aqui se tentou facilitar a tarefa de quem desenvolve as aplicações. Esta tentativa é em geral bem conseguida, principalmente nos casos de aplicações com interfaces mais simples, ou seja, que utilizem os objectos pré-definidos na framework (botões, caixas de texto, etc.). Já para quem pretende um pouco mais de personalização da interface que está a desenvolver, o tempo de aprendizagem desta ferramenta aumenta um pouco, embora o balanço continue a ser positivo.
No que toca à documentação da framework, ela é em geral completa e permite perceber a forma de utilização na maior parte dos casos, como se pode ver, olhando para as referências deste documento, em que muitos das hiperligações são para esta documentação. Ainda assim pode-se dizer que falta algum pormenor em alguns casos, talvez mais específicos, em que é difícil saber quais os comportamentos em casos marginais de utilização. Como exemplo mais flagrante desta questão, temos a
43
incompleta documentação do mecanismos de verificação de licenças de utilização disponibilizado na framework (capítulo 5.5).
7.2 Lançamento de aplicações Android Se tivermos em conta todos os dados apresentados no capítulo 6, é difícil não
concluir que a aplicação não teve o sucesso esperado. Deixando, para já, os motivos de lado, uma nível de desinstalações a rondar os 60% torna insustentável um projecto deste tipo. Ainda que se comece a notar uma tímida recuperação nesta questão, não temos ainda dados suficientes para concluir que a dita recuperação é efectiva.
Explorando os motivos desta problemática, já foi dito atrás que o lançamento de uma versão protótipo, de baixa qualidade, pode ter tido um efeito nefasto nos números apresentados. Neste cenário os utilizadores, desagradados com a falta qualidade da aplicação, tê-la-iam desinstalado, algo que parece fazer sentido, olhando para o gráfico da figura 18, que compara o número de instalações e desinstalações diárias.
Algo que contraria um pouco a tese da falta de qualidade do protótipo, é o facto do número de desinstalações se manter alto, mesmo depois do lançamento de uma versão estável, testada, e cumpridora dos parâmetros de qualidade em aplicações deste género. Se a falta de qualidade do protótipo fosse o único factor decisivo nesta questão, teríamos assistido a uma acentuada tendência de descida do número de desinstalações em relação ao número de instalações.
Assim, fica a ideia de que esta não é uma aplicação muito atraente para o público geral. De alguma forma os utilizadores são levados a experimenta-la, mas por algum motivo as suas expectativas saem goradas. É talvez difícil de entender a forma de funcionamento, uma vez que sai bastante fora do habitual, como vimos no capítulo 2, onde se descrevem algumas aplicações com objectivos parecidos.
Por último, temos a já referida tendência de recuperação, que ainda que tímida e incerta, a verificar-se pode deitar por terra ambos os cenários acima descritos, e apontar para uma nova conclusão. Esta é neste momento a hipótese menos provável, mas à qual a Addition estará atenta, de modo a tentar inverter o sentido que se observou até ao momento.
44
Bibliografia
[1] – Android: http://www.android.com/
[2] – Aplicações — Google Play: https://play.google.com/store
[3] – Addition - Serviços e Projectos Informáticos, Lda: http://www.addition.pt/
[4] – CADA: http://www.cada1.net/
[5] – Smart Ring Control: http://smartringcontrol.blogspot.com/
[6] – FoxyRing: Smart Ringtone: http://levelupstudio.com/foxyring
[7] – SmartPhoneComfort:
https://play.google.com/store/apps/details?id=com.mobicreators.smartphonecomfort
[8] – Call Log Manager Pro: http://www.appsbeyond.com/apps/call-history-plus
[9] – Droid inPocket Premium – Aplicativos para Android no Google Play:
https://play.google.com/store/apps/details?id=org.addition.inpocket.premium
[10] – Google Play: https://play.google.com/
[11] – Droid inPocket Free – Aplicativos para Android no Google Play:
https://play.google.com/store/apps/details?id=org.addition.inpocket
[12] – Relatório de Junho de 2010 da Distimo: http://www.distimo.com/wp-
content/uploads/2011/02/Distimo-Report-June-2010.pdf
[13] – Distimo: http://www.distimo.com/
[14] – Status Bar Icons | Android Developers:
http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.
html
[15] – Pedro Rufino: http://www.prude.pt/
[16] – Android Design: http://developer.android.com/design/index.html
[17] – Mobclix: http://www.mobclix.com/
[18] – Aplication Programming Interface:
http://en.wikipedia.org/wiki/Application_programming_interface
[19] – Velti: http://www.velti.com/
45
[20] – Marketwire – Velti Acquires Mobclix:
http://www.marketwire.com/press-release/Velti-Acquires-Mobclix-LSE-VEL-
1328116.htm
[21] – Live Wallpapers – Android Developers:
http://developer.android.com/resources/articles/live-wallpapers.html
[22] – Software Framework – Wikipedia, the free encyclopedia:
http://en.wikipedia.org/wiki/Software_framework
[23] – Application Fundamentals – Android Developers:
http://developer.android.com/guide/topics/fundamentals.html
[24] – User Interface – Android Developers:
http://developer.android.com/guide/topics/ui/index.html
[25] – Singleton Pattern - Wikipedia:
http://en.wikipedia.org/wiki/Singleton_pattern
[26] – Lock (computer science) – Wikipedia:
http://en.wikipedia.org/wiki/Lock_(computer_science)
[27] – TextToSpeech – Android Developers:
http://developer.android.com/reference/android/speech/tts/TextToSpeech.html
[28] – SensorEventListener – Android Developers
http://developer.android.com/reference/android/hardware/SensorEventListener.html
[29] – Thread – Android Developers:
http://developer.android.com/reference/java/lang/Thread.html
[30] – Lock – Android Developers:
http://developer.android.com/reference/java/util/concurrent/locks/Lock.html
[31] – AudioRecord – Android Developers:
http://developer.android.com/reference/android/media/AudioRecord.html
[32] – Licensing Overview – Android Developers:
http://developer.android.com/guide/market/licensing/overview.html
[33] – AppBrain.com: http://www.appbrain.com/
Nota: Os endereços electrónicos listados acima foram acedidos pela última vez a 4
de Junho de 2012.
