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

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

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, da Addition, pela oportunidade que me deu
de realizar este projecto e pelo acompanhamento que prestou.
Dedicatória.
 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

i
ii
 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

iii
iv
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
1.5 Trabalho Relacionado .................................................................................. 3
1.5.1 Gestor de Alertas Sonoros..................................................................... 3

1.5.2 Visualizador de Comunicação .............................................................. 3

Capítulo 2 Objectivos ............................................................................................ 5
2.1 Gestor de Alertas Sonoros............................................................................ 5
2.1.1 Nome, versões e forma de distribuição:................................................ 5

2.1.2 Requisitos funcionais e não-funcionais: ............................................... 6

2.1.3 Resultados finais ................................................................................... 7
2.1.4 As diferenças entre o desenho e o resultado final............................... 12
2.1.5 Publicidade como receita da versão Free ........................................... 13
2.2 Visualizador de Comunicação ................................................................... 15
2.2.1 Nome e forma de distribuição............................................................. 15

2.2.2 Requisitos funcionais e não-funcionais............................................... 15

2.2.3 Resultados finais ................................................................................. 16
Capítulo 3 O Trabalho realizado na Addition ...................................................... 21
3.1 Aplicação Droid inPocket.......................................................................... 21
3.1.1 Diferenças entre o planeamento e a execução .................................... 23

3.2 Aplicação Today ........................................................................................ 24

3.2.1 Diferenças entre o planeamento e a execução .................................... 24

Capítulo 4 Desenho e Implementação ................................................................. 25

4.1 Desenho da aplicação Droid inPocket ....................................................... 26

4.2 Pormenores de implementação da aplicação Droid inPocket.................... 29

v
 4.2.1 Algoritmo utilizado para tratar os dados do sensor de proximidade... 30

4.2.2 Algoritmo utilizado para definir um volume de toque compatível com

o nível de ruído ....................................................................................................... 31

4.2.3 Uma nova funcionalidade decidida no momento de implementação . 32

4.3 Interface gráfica da aplicação Today ......................................................... 33
4.4 Controlo de qualidade do algoritmo de geração dos gráficos produzidos . 33
4.5 Mecanismo de verificação da licença de utilização ................................... 34
4.5.1 Restrições na aplicação Droid inPocket Premium.............................. 35

4.5.2 Restrições na aplicação Today ............................................................ 35

Capítulo 5 Lançamento da aplicação Droid inPocket.......................................... 37
5.1 Instalações e Desinstalações Diárias e Instalações Activas ....................... 38
5.2 Campanha publicitária como forma de divulgação.................................... 41
5.3 Mudança ligeira nas curvas de instalações e desinstalações...................... 43
Capítulo 6 Conclusões ......................................................................................... 44
6.1 Desenvolvimento de aplicações para o Android ........................................ 44
6.2 Lançamento de uma aplicação Android ..................................................... 45
Bibliografia 46

vi
vii
Lista de Figuras

Figura 1– Ecrã inicial da aplicação Droid inPocket ......................................................... 8

Figura 2 – Ecrã do modo inPocket ................................................................................... 9
Figura 3 – Ecrã do modo outPocket ............................................................................... 10
Figura 4 – Ecrã do modo headPhones............................................................................ 11
Figura 5 - Ecrã about ...................................................................................................... 12
Figura 6 - Interface gráfica inicial da aplicação Droid inPocket.................................... 13
Figura 7 - Interface da versão Free, com espaço publicitário ........................................ 14
Figura 8 - Ecrão inicial da aplicação Today ................................................................... 17
Figura 9 - Ecrã com menu da aplicação Today .............................................................. 17
Figura 10 - Ecrã com informações sobre a aplicação Today.......................................... 18
Figura 11 - Ecrã com menu de exportação da aplicação Today ..................................... 19
Figura 12 - Ecrã com menu de mudança de tipo de período da aplicação Today .......... 19
Figura 13 - Live Wallpaper definido pela aplicação Today............................................ 20
Figura 14 - Diagrama de classes da aplicação Droid inPocket ...................................... 27
Figura 15 - Exemplo da aplicação Today sem licença de utilização .............................. 36
Figura 16 - Instalações durante 2011 (cumulativo) ........................................................ 37

Figura 17 - Instalações durante 2012 (cumulativo) ........................................................ 38

Figura 18 - Instalações vs desinstalações (não cumulativo)........................................... 39
Figura 19 - Instalações activas no tempo (não cumulativo) ........................................... 40
Figura 20 - Médias cumulativas de percentagem de instalações vs percentagem de
desinstalações ......................................................................................................... 41
Figura 21 - Instalações dadas pela campanha publicitária ............................................. 42
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 ............................. 43

viii
ix
x
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.

1
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 mensagens 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 do objectivo do trabalho. Descrição das aplicações.
• Capítulo 3 – 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 4 – Descrição pormenorizada do desenho e implementação de ambas as
aplicações.
• Capítulo 5 – Descrição e discussão do lançamento e resultados da aplicação
“Gestor de Alertas Sonoros”.
• Capítulo 6 – Conclusões.

2
1.5 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.

1.5.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 2.

1.5.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.

3
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 2.

4
Capítulo 2 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.

2.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.

2.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.
Por uma questão estratégica da Addition, foram feitas duas versões da mesma aplicação
— Free e Premium — que diferem em algumas funcionalidades e na fonte de receita.

5
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 justificá-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.

2.1.2 Requisitos funcionais e não-funcionais:

Existem 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.
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.

6
 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 deve 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.

2.1.3 Resultados finais

O desenvolvimento da aplicação Droid inPocket está concluído.

7
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
contém os contactos da empresa responsável pelo desenvolvimento.
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.

8
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 entrou/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.
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

9
pode ser instalada. Não adiantando muito mais sobre as razões da sua existência para já
(serão explicadas no capítulo 4), 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
detectado pelo dispositivo. A segunda mostra o volume de alerta calculado pela
aplicação para aquele nível de ruído.

10
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.

Por último temos o ecrã com os contactos da empresa responsável pelo

desenvolvimento:

11
 Figura 5 - Ecrã about

2.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.

12
 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.

2.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.

13
 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].

14
2.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 além 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.

2.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 [].

2.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

15
diferentes têm cores diferentes. Comunicações diferentes do mesmo contacto têm cores
iguais.
4 – A comunicação que chega ao dispositivo (chamadas recebidas 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 além disso, devem
mostrar a quantidade de comunicação do dia, sem que para isso seja necessária uma
observação detalhada.

2.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.

16
 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.

17
 • 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ã contém 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

18
 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.

19
Figura 13 - Live Wallpaper definido pela aplicação Today

20
Capítulo 3 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.

3.1 Aplicação Droid inPocket

Esta aplicação, descrita no capítulo 2, 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

21
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 2), 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.

22
3.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 executá-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.

23
3.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.

3.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.

24
Capítulo 4 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.

25
4.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.

26
Figura 14 - Diagrama de classes da aplicação Droid inPocket

27
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.

28
 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.

4.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.

29
4.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.

30
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.

4.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.

31
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.

4.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.

32
Daqui nasceu a funcionalidade “Use accelerometer sensor”, comum a ambas as versões
e acessível através do ecrã do modo inPocket.

4.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.

4.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

33
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).

4.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.

34
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.

4.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.

4.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.

35
Figura 15 - Exemplo da aplicação Today sem licença de utilização

36
Capítulo 5 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:

1400

1200

1000

800

600

400

200

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.

37
 2450

2250

2050

1850

1650

1450

1250
15-Jan
22-Jan
29-Jan
5-Feb
12-Feb
19-Feb
26-Feb
4-Mar
11-Mar

15-Apr
22-Apr
29-Apr
6-May
18-Mar
25-Mar
1-Apr
8-Apr
1-Jan
8-Jan

13-May
20-May
27-May
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.

5.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.

38
 200

180

160

140

120

100

80

60

40

20

0
4-Dec
11-Dec
18-Dec
25-Dec
1-Jan
8-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

13-May
20-May
27-May
15-Jan
22-Jan
29-Jan

6-May
27-Nov

Instalações diárias (não cumulativo) Desinstalações diárias (não cumulativo)

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 no número de instalações/desinstalações diárias. Os picos que se
vêem 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

39
quem desenvolve aplicações gratuitas, principalmente se estas forem financiadas através
de publicidade, como é o caso da versão Free.

450

400

350

300

250

200

150

100

50

0
27-Nov 27-Dec 27-Jan 27-Feb 27-Mar 27-Apr 27-May

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.

40
 100.00%
90.00%
80.00%
70.00%
60.00%
50.00%
40.00%
30.00%
20.00%
10.00%
0.00%
27-Nov 27-Dec 27-Jan 27-Feb 27-Mar 27-Apr 27-May

Média de desinstalações (cumulativo) Média de instalações (cumulativo)

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 além 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.

5.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.

41
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.

70

60

50

40

30

20

10

0
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

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 5.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.

42
5.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.

60.00%

55.00%

50.00%

45.00%

40.00%

35.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
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.

43
Capítulo 6 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.

6.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

44
incompleta documentação do mecanismos de verificação de licenças de utilização
disponibilizado na framework (capítulo 5.5).

6.2 Lançamento de uma aplicação Android

Se tivermos em conta todos os dados apresentados no capítulo 5, é 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 1,
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.

45
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/

46
 [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.

47