Personal Shopping Assistant

Asthana et al. [2] desenvolveram um assistente de compras inteligente, personali- zando a atenção específica ao cliente de forma automatizada.

O conceito era que um utilizador entrava num centro comercial, pegava num dispo- sitivo de um tamanho de um walkman, pousava-o no carrinho de compras e dizia ‘’olá‘’ ao microfone. A unidade instantaneamente responderia, e assim começava a interação com o assistente pessoal enquanto o utilizador estivesse dentro do centro comercial. O aparelho guiava os utilizadores através das diversas lojas, fornecendo detalhes sobre os produtos de interesse através do ecrã embutido no mesmo, re- ferindo produtos em saldos, fazendo análises comparativas de preços, chamando a atenção para itens comprados em visitas anteriores. Seria também possível que o utilizador fizesse scan ao preço de um produto através do leitor de códigos de barras presente no dispositivo.

Figura 2.3– Serviço de PSA [2]

Como se pode verificar pela Figura 2.3, este projeto está dividido em duas partes, a primeira, por um dispositivo sem fios que é entregue ao cliente, chamado PSA ou

Personal Shopping Assistant, e o segundo, um servidor central ao qual os clientes co- municam utilizando o PSA. Este serviço PSA possui uma arquitetura o mais aberta possível uma vez que o objetivo era criar um dispositivo que tivesse inputs/outputs que fornecessem informação acerca de algo, pelo que a sua funcionalidade deverá ser definida pelo servidor com que comunica. Assim, neste projeto foi focada a vertente da aplicação de compras. Este sistema teria então as seguintes funções:

• Simplicidade de uso e operações mãos-livres: Poucos botões (três a quatro) com um menu simples, onde outro método de introdução seria o discurso (voz).

• Localização de Produtos: Uso principal do PSA, que é ajudar o cliente a localizar produtos que este procura.

• Envolver o cliente: Outra função deste sistema é manter a atenção do utiliza- dor, envolvendo o mesmo numa conversação mais ou menos amigável.

• Direcionar o cliente: Ajuda o cliente a focar a sua atenção em novos produtos de acordo com as preferências do mesmo.

Como referido anteriormente, o PSA está dividido em duas componentes. A unidade PSA em si e o servidor PSA. O PSA é um pequeno dispositivo, low-cost, que possui um conjunto de headphones com microfone. Este é diferenciado de outros PDAs não só pelos seus métodos de entrada, mas também porque a sua funcionalidade é determinada pelo servidor com que comunica.

A figura2.4 representa o dispositivo PSA, que de forma a manter o custo reduzido e sua funcionalidade flexivel, apenas está encarregue de passar a informação definida pelo cliente e receber a resposta do servidor central.

Figura 2.4– Dispositivo PSA [2]

Relativamente ao servidor PSA, este é o cérebro do sistema, uma vez que tem a responsabilidade de fornecer a funcionalidade ao dispositivo PSA. Para establecer uma ligação entre o servidor e o dispositivo, poderá ser necessário um input como um controlo de voz, um número de identificação de cliente, ou uma combinação dos dois. Depois de establecida essa conexão, o sistema deverá ser capaz de identificar o perfil do cliente através da sua base de dados. este perfil poderá ser usado para ajudar o cliente, direciona-lo a produtos do seu interesse, etc.

A figura 2.5 ilustra a arquitetura do servidor PSA. As caixas representam tanto hardware como software. O transmissor e recetor representam o subsistema wireless que envia e recebe comandos, comandos de voz e imagens de e para o dispositivo PSA. O position finder mantém-se a par da posição do cliente. Speech recognition proporciona o reconhecimento limitado de vocabulário, como palavras ou frases sim- ples em tempo real. A reposta dada pelo servidor é depois convertida utilizando o text-to-speech uma vez que esta é enviada como uma string.

Este sistema inclui várias bases de dados. A do cliente possui todos os perfis dos clientes registados, e é alterada baseada nas interações que o sistema tem com os mesmos. Existe ainda uma base de dados para anúncios que podem ser reprodu- zidos sob a forma de áudio ou de vídeo. A base de dados da loja contém o preço

Figura 2.5– Servidor PSA [2]

e o inventário de todos os produtos disponíveis na mesma. A base de dados das ‘’pechinchas‘’, piadas e citações contém clips de áudio e de vídeo que podem ser reproduzidos quando solicitados pelo cliente para seu entretenimento ou para pro- moções. A música poderá ser reproduzida de fundo enquanto o cliente passeia pela loja. Relativamente ao connection manager, este controla a alocação da largura de banda para os canais de vídeo e de áudio. É ainda responsável por toda a sessão com iniciada com o cliente, querendo isto dizer que é o principal processo que invoca serviços de outros subsistemas quando estes são necessários para ajudar um cliente específico.

2.3.4

The Interactive Workspaces Project: Experiences with

Ubiquitous Computing Rooms

Johanson et al. [3] desenvolveram espaços de trabalho interativos que permitiram explorar novas possibilidades para as pessoas trabalharem em conjunto em espaços tecnológicos. O projeto focou-se na adaptação de uma sala de reuniões com ecrãs, aparelhos wireless e aplicações móveis.

Visão geral, Objetivos e Contribuições do Projeto

Conforme foi sendo desenvolvida a construção do iRoom (do inglês Interactive Room), foram tidas algumas diretrizes em conta:

• Prática do que era o objetivo: Uma vez que o objetivo do projeto era a criação de uma sala interativa, todas as reuniões foram feitas no iRoom, utilizando as ferramentas que iam sendo desenvolvidas e aplicadas. Grande parte da motivação para avançar no projeto foi a frustração de encontrar alguma tarefa que não pudesse ser realizada no iRoom.

• Ênfase na co-localização: Uma vez que existem diversas pesquisas na área das tele-conferências, foi escolhido explorar novos tipos de suporte para as reuniões em salas privadas, usando as vantagens de uma sala partilhada, como forma de interação.

• Baseada em convenções sociais: Em vez da construção de uma sala que rea- gisse aos utilizadores, foi decidido que o foco iria ser fornecer as possibilidades necessárias para que um grupo de trabalhadores fosse ajustando o ambiente da sala, à medida que fossem avançando numa determinada tarefa. Assim, o sistema foi desenvolvido de maneira que os utilizadores e as convenções sociais tivessem a responsabilidade das suas ações, e o sistema apenas fornecesse uma infraestrutura responsável pela execução dessas mesmas ações.

• Vasta aplicabilidade: Foi feita investigação em técnicas de software que pu- dessem ser configuradas e adaptadas a diferentes espaços de trabalho. Assim, o objetivo era fornecer uma framework que fosse capaz de criar abstração independentemente do espaço de trabalho.

• Simplicidade: Tanto como na interface como no software foi mantida a sim- plicidade. Do lado da interface ao utilizador, existe uma ponderação entre a necessidade de suportar vários tipos de hardware e software e a necessidade de fornecer uma interface simples o suficiente para que as pessoas a usem. Este sistema deveria ser acessível mesmo para os utilizadores menos experientes.

Do lado do software tentaram manter as APIs o mais simples e flexíveis possí- vel, de forma a que fosse mais fácil fazer o port das bibliotecas, minimizando a problemática na criação de novas aplicações.

Figura 2.6– Fotografia real do iRoom [3]

O iRoom, como se pode também observar pela Figura 2.6, possuía três grandes touch screens ao longo de uma parede, outro grande (1,8 metros de diagonal) touch screen embutido na parede, uma mesa com um display, cãmaras, microfones, uma LAN wireless, e vários outros aparelhos de interação com a sala.

Caracterização do ambiente

Baseando as experiências realizadas no iRoom foram identificadas algumas carac- terísticas que deveriam ser suportadas pela infraestrutura numa área de trabalho interativa.

• Heterogeneidade: Uma variedade de diferentes dispositivos (PDAs, portáteis, etc) seriam usados no espaço de trabalho, cada um deles sendo específico e eficiente para determinada tarefa. Como tal, haveria software heterogéneo a correr nesses mesmos dispositivos, tendo portanto, este software, de ser acessí- vel na transversalidade das plataformas. Do ponto de vista da interação entre

Homem-Computador, as interfaces deveriam ser personalizáveis para diferen- tes tamanhos de ecrãs, diferentes inputs/outputs, etc.

• Multiplicidade: Ao contrário de um computador pessoal onde um único utiliza- dor e um conjunto de dispositivos de inputs/outputs fornecem a interação com o computador, um espaço de trabalho interativo por natureza possui vários utilizadores, dispositivos e aplicações simultaneamente ativos.

• Dinamismo: O espaço de trabalho interativo seria dinâmico, uma vez que, a curto prazo, dispositivos presentes no mesmo poderiam ser desligados, apare- lhos wireless poderiam entrar/sair da sala e outros equipamentos que integram a sala poderiam avariar. A longo prazo, os espaços de trabalho serão mais de- senvolvidos em vez de se manterem no estado atual. Não era realista esperar que um administrador mantivesse o sistema do espaço de trabalho a correr sem cessar, portanto, a falha destes sistemas deveria ser antecipada como caso comum, e o sistema em si deveria ser capaz de uma rápida recuperação em caso de falha, quer automaticamente, quer manualmente pelo utilizador.

Uso comum

Foi necessário determinar quais os tipos de atividade que os utilizadores iriam exe- cutar nos espaços de trabalho interativo. Através de grupos de pesquisa chegaram-se a três grandes modalidades:

• Transferência de dados: os utilizadores do espaço de trabalho necessitariam de transferir dados entre as várias aplicações de visualização presentes nos ecrãs da divisão, portáteis e PDAs trazidos para o espaço de trabalho.

• Transferência de controlo: De forma a minimizar interrupções e atrasos du- rante reuniões/conferências, etc, qualquer utilizador deveria ser capaz de con- trolar qualquer dispositivo presente no espaço de trabalho a partir da sua própria localização

• Coordenação dinâmica das aplicações: As aplicações específicas necessárias para mostrar dados e analisar cenários nas reuniões poderão ser muito diversas, e qualquer aplicação existente no sistema poderá ter de ser utilizada durante uma reunião. Assim, as atividades de cada uma das ferramentas deverá ser coordenada com as outras apropriadamente.

iROS - Interactive Room Operating System

Na realidade este ‘’sistema operativo‘’ é um middleware que trata de ‘’vincular‘’ os dispositivos presentes da divisão, cada um deles correndo o seu próprio sistema operativo. No desenvolvimento deste projeto foi mantido o princípio dos limites da computação ubíqua, que refere que uma infraestrutura ubíqua necessita de permitir interações entre dispositivos apenas dentro dos limites do espaço físico local, neste caso, o espaço de trabalho interativo.

Figura 2.7– Estrutura do iROS [3]

Como se pode ver pela Figura2.7existem três sub-sistemas, sendo eles o Data Heap, iCrafter e Event Heap. Estes estão diretamente ligados aos usos mais comuns pre- viamente definidos, transferência de dados, transferência de controlo e coordenação dinâmica das aplicações, respetivamente.O único sub-sistema que o iROS usa é o Event Heap, que para além de fornecer coordenação dinâmica às aplicações, também é a infraestrutura de comunicação que as aplicações usam dentro do espaço de tra- balho interativo. o Event Heap armazena e envia mensagens sob a forma de eventos. Fornece um repositório a que todas as aplicações para que estas possam postar esses

mesmos eventos. O Data Heap facilita a transferência de dados, permitindo a qual- quer aplicação que coloque os dados numa base de dados associada ao ambiente local. Os dados são guardados com um número arbitrário de atributos, que caracterizam o ambiente. Usando atributos ao invés de localizações, as aplicações não necessitam de se preocupar com o ficheiro físico específico de sistema que está a ser usado para armazenar esses mesmos dados. Este sub-sistema também é responsável pela trans- formação de ficheiros em caso de incompatibilidade, por exemplo, se um aparelho apenas suporta JPEG, um PowerPoint que esteja no sistema é automaticamente convertido nesse formato de imagens. O iCrafter fornece serviços de criação de in- terfaces para serviços. Este fornece métodos que permitem ao utilizador selecionar um ou mais serviços para controlar e automaticamente retorna a melhor interface para os serviços escolhidos. Quando já existe um par serviço/interface definido, este é retornado, caso contrário um criador genérico de interfaces é usado para a criação da mesma, suportada por aquele dispositivo específico, baseando a sua criação nas características do ambiente local. Este sub-sistema comunica diretamente com os serviços através do Event Heap.

2.3.5

Classification of Sporting Activities Using Smartphone

Accelerometers

Mais recentemente, em 2013, E. Mitchell et al. [4] apresentaram uma framework que permite a identificação automática de atividades desportivas, utilizando um smartphone. Neste artigo, os autores utilizaram os acelerómetros presentes no dis- positivo, posicionando o mesmo nas costas de vários indivíduos, como é observável na Figura 2.8.

O objetivo seria proporcionar aos atletas alternativas com um custo mais reduzido (quando comparados com os aparelhos específicos para o efeito) para que estes con- seguissem tirar vantagem desta tecnologia para poderem analisar a sua participação e disponibilidade física, tanto durante os treinos, como durante os jogos. Esta tec- nologia poderia também ser utilizada para que os fisioterapeutas das equipas fossem

Figura 2.8– Posicionamento do dispositivo no indivíduo. [4]

notificados em casos de choques e possíveis lesões, fornecendo também ao treinador um feedback de como este deveria organizar e individualizar o treino, mediante o desgaste/estado físico de um atleta específico.

Atividades Alvo e Metodologia Experimental

Foram recolhidos dados de acelerómetros em dois desportos específicos, futebol de salão (futsal) e hóquei em patins. A premissa era então conseguir identificar sete tipos diferentes de atividades, sendo elas:

• Sujeito estacionário (0 m/s); • Sujeito a caminhar (1 ± 1 m/s); • Sujeito a correr (3.5 ± 1.5 m/s); • Sujeito a sprintar (5+ m/s); • Sujeito a rematar;

• Sujeito a driblar.

Para o futsal, a aquisição de dados foi feita em cinco jogos, cada um com duração de uma hora. Nestes cinco jogos, os dados da aceleração foram retirados de 15 jo- gadores diferentes. Relativamente ao hóquei, foram recolhidos dados em seis jogos, por um total de 17 jogadores diferentes. Todos os jogos foram gravados em vídeo, permitindo assim sincronizar esse mesmo vídeo com os dados recolhidos, possibili- tando a anotação das ações dos jogadores. Para a caracterização da atividade foram usados 9 segundos de dados recolhidos. Este valor específico foi utilizado por ser um valor de tempo grande o suficiente para que estas atividades sejam realizadas, e por ser pequeno o suficiente para não aumentar drasticamente o tempo de compu- tação. Foram criadas bases de dados que continham 30 exemplos de cada atividade específica, tanto no futsal como no hóquei. Todos os estes exemplos permitiram a comparação baseando-se na variação de parâmetros do modelo de classificação. Foram posteriormente extraídas características específicas discriminadas de cada tipo de movimento, usando a Discrete Wavelet Transform. A informação retirada deste método foi utilizada por diversos classificadores como por exemplo Árvores de Classificação ou Redes Neuronais Artificiais, para que a atividade pudesse ser efetivamente classificada.

Os resultados obtidos demonstraram uma percentagem de 87% de precisão na de- teção de atividades quando usando uma fusão de diversos classificadores, sendo 6% melhor do que o uso de apenas um classificador.

3

_{APIs do Android}

Apesar de a Framework que vai ser desenvolvida possa ser aplicada em qualquer plataforma que suporte Java, como caso de estudo será utilizada a plataforma An- droid. Torna-se portanto necessário conhecer melhor esta plataforma bem como as APIs que esta nos fornece.

O Android Studio é um IDE que fornece uma estrutura para a construção e de- senvolvimento de aplicações Android para dispositivos móveis [24], e neste caso, baseando-se na linguagem de programação Java. Todo o código escrito é compilado, pelas ferramentas do Android SDK num ficheiro executável com todos os recursos e dados necessários ao funcionamento da aplicação, a que se dá o nome de Pacote Android ou APK, que para além de conter todo o conteúdo da aplicação, possui também o método de instalação da mesma.

Já o Android em si é um sistema operativo que é baseado num sistema Linux (ker- nel ) [25], onde cada aplicação é um utilizador diferente do mesmo. É atribuída a cada aplicação um ID de utilizador diferente (que é usado pelo sistema operativo, mas desconhecido da aplicação em si) para a atribuição permissões da aplicação. O código de cada aplicação é executado separadamente, uma vez que cada pro- cesso tem a sua máquina virtual (Dalvik VM ). Assim, cada aplicação é executada

no seu próprio processo, facilitando o inicio do mesmo quando é necessário execu- tar um componente da aplicação, e terminando-o quando deixa de ser necessário, libertando memória e recursos para outras aplicações. A isto se chama o Princi- pio de privilégio mínimo, onde por padrão, cada aplicação apenas tem acesso aos componentes necessários para a sua execução, proporcionando segurança ao sistema operativo [26].

3.1

Componentes da Aplicação

Cada aplicação é constituída por ‘’módulos‘’ que permitem a sua criação e desenvol- vimento. Cada um destes módulos funciona como uma entidade específica, com uma função específica que ajuda a definir o comportamento da aplicação. Existem quatro tipos de componentes de aplicações, sendo eles: Activity, Services, ContentProvider e BroadcastReceiver.

3.1.1

Activity

Uma Activity apresenta uma determinada janela ao utilizador com a respetiva in- terface com a qual os utilizadores poderão interagir. Por exemplo, uma aplicação de nutrição poderá ter uma Activity que mostra a lista de alimentos consumidos recen- temente, outra Activity poderá mostrar as calorias ingeridas, e ainda outra Activity que permita inserir novos alimentos na dieta. As Activities podem portanto iniciar várias Activities para desempenharem diferentes funções, e embora estas funcionem em conjunto para a coesão da aplicação, elas funcionam independentemente umas das outras. Se essa aplicação possuir as respetiva permissões, poderá também iniciar uma Activity noutra aplicação, como por exemplo na aplicação da câmara, para que o utilizador partilhe uma foto da sua refeição.

Enquanto um utilizador entra, navega e sai de uma aplicação, as instâncias da classe Activity passam para diferentes estados no ciclo de vida da mesma. Todas as apli- cações contêm esta classe Activity que fornece 6 callbacks que permitem ao sistema

saber se um determinado estado foi alterado, como por exemplo, se a aplicação e/ou Activity foi iniciada, parada, resumida ou destruída [5]

No ciclo de vida onde os métodos são implementados deve ser declarado o com- portamento desejado da Activity, nomeadamente quando o utilizador entra e sai da aplicação. Assim, resumidamente, cada callback possui uma função específica, apro- priado a um tempo específico no ciclo de vida da aplicação, tornando a aplicação mais fiável e otimizada. Esta implementação, quando bem feita, permite evitar por exemplo:

• Que a aplicação perda os dados (progresso) do utilizador quando este sai da mesma e depois a retoma;

• O fecho inesperado ou perda de dados quando se dá a rotação de ecrã do modo retrato para o modo paisagem e vice-versa;

• O consumo excessivo de recursos quando na realidade a aplicação não está a ser usada;

• O fecho inesperado da aplicação quando o utilizador recebe uma chamada.

Os callbacks que a classe Activity fornece são então os seguintes:

• onCreate(); • onStart(); • onResume(); • onPause(); • onStop(); • onDestroy().

O diagrama seguinte apresenta um algoritmo com a respetiva invocação de métodos callback que deverão integrar o ciclo de vida de qualquer aplicação, bem como a explicação dos mesmos:

Passando à caracterização dos métodos callback [5], temos o seguinte:

• O método onCreate() é invocado quando a Activity é criada. Na sua imple- mentação é necessário definir os componentes essenciais da mesma, bem como toda a lógica inicial que deverá acontecer apenas uma vez em todo o ciclo de vida da aplicação. É neste método que deve ser chamado o setContentView() que define o layout da interface da Activity em questão. Após a invocação deste método, a Activity não permanece no estado created, mas entra no es- tado Started e o sistema invoca onStart() e onResume() sucessivamente; • onStart() é invocado quando a Activity entra no estado Started tornando a

mesma ‘’visível‘’ para o utilizador da aplicação. Assim, entre este e o método