U
NIVERSIDADE DE
L
ISBOA
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
U
NIVERSIDADE DE
L
ISBOA
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
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.
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.
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.
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...2Capí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
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
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
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”.
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
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
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ê)
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
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
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
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
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.
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.
