Universidade Federal do Rio de Janeiro. Escola Politécnica. Departamento de Eletrônica e de Computação. Gerenciador de Eventos do Facebook

Transcrição

1 Universidade Federal do Rio de Janeiro Escola Politécnica Departamento de Eletrônica e de Computação Gerenciador de Eventos do Facebook Autor: Orientador: Examinador: Examinador: Eduardo Fernando Costa de Niemeyer Prof. Flavio Luis de Mello, D. Sc. Prof. Aloysio de Castro Pinto Pedroza, D. Sc. Prof. Miguel Elias Mitre Campista, D. Sc. DEL Agosto de 2014

2 UNIVERSIDADE FEDERAL DO RIO DE JANEIRO Escola Politécnica Departamento de Eletrônica e de Computação Centro de Tecnologia, bloco H, sala H-217, Cidade Universitária Rio de Janeiro RJ CEP Este exemplar é de propriedade da Universidade Federal do Rio de Janeiro, que poderá incluí-lo em base de dados, armazenar em computador, microfilmar ou adotar qualquer forma de arquivamento. É permitida a menção, reprodução parcial ou integral e a transmissão entre bibliotecas deste trabalho, sem modificação de seu texto, em qualquer meio que esteja ou venha a ser fixado, para pesquisa acadêmica, comentários e citações, desde que sem finalidade comercial e que seja feita a referência bibliográfica completa. Os conceitos expressos neste trabalho são de responsabilidade do(s) autor(es). ii

3 DEDICATÓRIA Dedico à minha família, que sempre colocou o estudo em primeiro lugar e me apoiou em todo o percurso até aqui. iii

4 AGRADECIMENTO Aos meus professores, principalmente os da UFRJ, mas também os dos intercâmbios em Portugal (IST) e Estados Unidos (SUNY New Paltz), que me ajudaram a obter o conhecimento necessário para a realização desse trabalho. Ao meu orientador, Flávio Luis de Mello, que acompanhou e auxiliou o desenvolvimento desta monografia. À instituição UFRJ, que me permitiu realizar dois intercâmbios, sempre me apoiando no que fosse ajudar o meu enriquecimento cultural e profissional. Às universidades Instituto Superior Técnico e State University of New York at New Paltz, que abriram suas portas e me acolheram bem para que eu realizasse meus estudos. Aos meus amigos, da UFRJ, dos intercâmbios e do trabalho, que me apoiaram nos estudos e trabalharam junto comigo para que pudesse obter o conhecimento necessário para concluir esse projeto. À minha família, pais, irmãos, avós, tios e primos, que sempre acreditaram em mim e investiram na minha educação. Ao povo brasileiro que contribuiu de forma significativa à minha formação e estada nesta Universidade, assim como nos intercâmbios. Este projeto é uma pequena forma de retribuir o investimento e confiança em mim depositados. iv

5 RESUMO Este trabalho descreve o desenvolvimento e a engenharia relacionada à produção de um software para Smartphone Android com conexão à nuvem e à rede social Facebook. O software em questão é um Gerenciador de Eventos do Facebook. Ele auxilia ao seu usuário, que possua uma conta no Facebook, escolher a quais eventos ir. Um evento no Facebook é um acontecimento social previamente planejado e organizado na Rede Social, como uma festa ou concerto. O sistema permite avaliar seus eventos e aos participantes dos mesmos, verificar a média geral das avaliações, incluindo a de outros usuários, possibilitando-o ter uma visão complementar de eventos que estejam por vir e dos que já passaram baseadas nessa média geral. Ele visa aprimorar as funcionalidades já existentes na área de eventos do Facebook, além de possibilitar a avaliação de aspectos deles, como empatia pelos participantes, custo, diversão e local - algo inexistente atualmente - e simplificar o acesso a informações dos mesmos, ao exibir as avaliações relacionadas a cada aspecto, o numero total de participantes e a porcentagem de homens e mulheres para cada evento. Palavras-Chave: Android, Smartphone, Facebook, Eventos, Gerenciador, Nuvem. v

6 ABSTRACT This paper describes the development and engineering related to the production of software for Android Smartphones with connection to the cloud and the social network Facebook. The software in question is a Facebook Event Manager. It assists its user, who has a Facebook account, to choose which events to go. A Facebook event is a pre-planned and organized social occasion at the Social Network, like a party or concert. The system allows the user to evaluate his events and its participants, check the overall average of ratings, including ratings of other users, allowing the user to have a complimentary view of events that are to come, and that have passed based on this overall average. It aims to enhance the existing functionality in the events area of Facebook, in addition to permit evaluation of aspects of them, like empathy for the participants, cost, fun and place - something currently lacking - and simplify access to the events information, displaying the evaluations related to each aspect the total number of participants and the percentage of women and men for each event. Key-words: Android, Smartphone, Facebook, Events, Manager, Cloud. vi

7 SIGLAS API Application Programming Interface EC2 Elastic Compute Cloud HTTP Hypertext Transfer Protocol HTTPS Hypertext Transfer Protocol Secure JSON JavaScript Object Notation MySQL Software de Banco de Dados relacional PHP Linguagem de scripting Server-Side SDK Software Development Kit UFRJ Universidade Federal do Rio de Janeiro UML Unified Modeling Language URL Uniform Resource Locator XML extensible Markup Language vii

8 Sumário 1 Introdução Tema Delimitação Justificativa Soluções similares existentes Objetivos Metodologia Descrição Fundamentação Teórica Facebook Graph API Facebook SDK Desenvolvimento Android Autenticação com o Facebook AndroidManifest Classe Activity Classe Fragment Classe FagmentActivity Desenvolvimento Servidor Amazon Métodos HTTP-POST e HTTP-GET Extraindo dados do Facebook viii

9 3 Modelagem do Sistema Materiais e Métodos Modelo de Dados Diagrama de Componentes e de Distribuição Fluxo do Sistema Autenticação no Sistema Ambiente de Eventos Tela Histórico Tela Avaliar Tela Fomulários Tela Configurações Avaliação do Sistema 37 6 Conclusão 43 Bibliografia 43 A Especificação de Requisitos 46 B Casos de Uso 49 C Casos de Testes 59 ix

10 Lista de Figuras 2.1 Graph API Explorer Camadas da plataforma Android Aplicativo no Facebook Comunicação Dispositivo Mobile Servidor Facebook Ciclo de vida de uma Activity Ciclo de vida de um Fragment Exemplo de leitura via Graph API em sintaxe JSON Estrutura de Dados Diagrama de Distribuição Telas de Introdução Autenticação com o Facebook Ambiente de Eventos Tela Histórico Tela Histórico com item expandido Tela Avaliar Tela Formulários Tela Formulários com item expandido Tela Configurações Formulário de avaliação do sistema Instalações do aplicativo Empatia pelo APP Empatia pelo layout do APP Avaliação do Desempenho do APP Frequência de uso do APP Frequência de avaliação de participantes x

11 Lista de Tabelas 2.1 Métodos Callback de uma Activity Métodos Callback de um Fragment Dicionário de Dados xi

12 Capítulo 1 Introdução 1.1 Tema Este trabalho tem como tema o desenvolvimento e a implementação de um aplicativo para smartphones Android conectado a um servidor em nuvem. O projeto consiste em um gerenciador de eventos do Facebook, chamado Tiupar, onde o usuário possa avaliar e analisar diversos quesitos referentes aos eventos disponíveis, ajudando-o a decidir-se em qual ir. Um evento no Facebook é um acontecimento social previamente planejado e organizado na Rede Social, como uma festa ou concerto 1.2 Delimitação Este projeto focará apenas em eventos do Facebook, sendo implementado no Sistema Operacional Android para smartphones e Linux para o Servidor Cloud, ou seja, um computador com a aplicação instalada, acessado via Internet. Sua função será gerenciar eventos, utilizando-se de notas atribuídas pelos usuários para diversas características dos eventos. Neste sentido, será necessário que a pessoa possua uma conta no Facebook e dê as permissões básicas ( e identificador de usuário) e de leitura de seus eventos. 1.3 Justificativa Uma das funcionalidades disponíveis no Facebook é o sistema de eventos, onde se pode confirmar participação em atividades diversas, visualizar outros usuários, quantos confirmaram presença, etc. Porém, não existe um avaliador e nem direcionador de informações que poderiam ser interessantes ao usuário do Facebook, como a distribuição de pessoas por sexo em um determinado evento. 1

13 Por isso, têm-se a necessidade da criação de uma ferramenta, no caso um aplicativo Android, que ajude o usuário a gerenciar os eventos de seu interesse, podendo decidir em qual ir baseado nas suas avaliações e nas da comunidade. 1.4 Soluções similares existentes Existem algumas soluções parecidas com o Tiupar no mercado nacional, porém todas se diferenciam do modelo implementado no Tiupar. Duas delas serão estudadas nesse tópico, a WeGoOut e a #PartyU. O WeGoOut está disponível para ios, Android e via browser, também possui conexão com o Facebook. Permite visualizar quantidade de participantes por evento do Facebook e porcentagem de homens e mulheres, como o Tiupar. Além disso, também sugere eventos baseados na localidade do usuário, exibe mapa com a localidade dos eventos e informa quais amigos do usuário confirmaram presença nos eventos listados. Como pontos negativos, exibe somente eventos pré-selecionados do Facebook, ou seja, não exibindo todos os eventos disponíveis no Facebook, o aplicativo para Android não funcionou quando foi testado, provavelmente por algum bug ainda não corrigido e a solução possui um desempenho lento. O #PartyU só existe atualmente para ios. Ele não oferece eventos, mas sim casa de festas onde eventos ocorrem. Não é dependente do Facebook, porém, são poucas as opções de casas de festas registradas e se concentram apenas em algumas cidades principais do sul e sudeste do Brasil, como Rio de Janeiro, São Paulo e Curitiba. Possui diversas funcionalidades, como sugerir eventos, colocar nome na lista VIP de eventos, ranking das melhores casas de festas, sorteio de ingressos, avaliação geral das casas de festas, chat e mapa com a localização de casas de festas próximas, baseadas no GPS do dispositivo móvel, confirmar presença em uma festa e exibir número de participantes confirmados, porém, apenas os que confirmaram presença no #PartyU. Como pontos negativos, possui alguns erros de formatação no layout e não exibe porcentagem de homens e mulheres. Nenhuma das soluções possui uma quantidade de usuários ativos expressiva, identificando um mercado não estabelecido e aberto para novas ideias, como a do Tiupar. 2

14 1.5 Objetivos Tendo em vista as soluções já existentes, procurou-se desenvolver uma solução que integrasse aspectos latentes nas anteriores, como o trabalho coletivo e a interatividade dos usuários com o Tiupar para avaliar os eventos e seus participantes. O objetivo geral do trabalho é desenvolver e implementar um aplicativo Android com integração ao Facebook, conectado a um Banco de Dados em um Servidor Cloud da Amazon, para gerenciar eventos. Os eventos gerenciados serão os que o usuário confirmou presença na rede social. Os objetivos específicos do trabalho são: Extrair informações de eventos do Facebook e gravar no banco de dados do servidor; Desenvolver um aplicativo que se comunique com o banco de dados no servidor e que permita: o Avaliar os eventos; o Avaliar os participantes de eventos que estão por vir e que o usuário tenha confirmado presença no Facebook, para que essa nota seja atribuída aos eventos relacionados a eles. As notas individuais de cada participante não devem ser nunca divulgadas; o Preencher formulários de avaliação para eventos que já tenham passado; o Configurar preferência sexual do usuário. 1.6 Metodologia Para atingir os objetivos do projeto, foram usadas as informações extraídas com base em permissões dadas pelos usuários - que liberam acesso a informações privadas como os eventos e lista de amigos do usuário, sendo também usadas informações públicas, como identificador e sexo - do banco de dados do Facebook. A partir dessas informações é possível organizá-las e tratá-las num banco de dados em um servidor do Tiupar na nuvem. Nele são atribuídos campos de notas que são preenchidos de acordo com as avaliações realizadas pelos usuários do aplicativo. 3

15 No servidor tratam-se os dados gravados no banco de dados, para atribuir uma nota final a cada evento, a qual pode variar de acordo com a preferência sexual do usuário, já que as notas para homens e mulheres podem ser diferentes. 1.7 Descrição O capítulo 2 disserta sobre o Desenvolvimento do Sistema. Serão tratadas questões sobre Servidor na nuvem e gerenciamento de páginas no Android, focando nas classes Activity, Fragment e FragmentActivity. A API do Facebook, com a qual se extrai os dados referentes a eventos, também será estudada. O capítulo 3 apresenta a modelagem do sistema. Detalhes sobre a arquitetura do sistema, desde a Estrutura de dados na nuvem até Diagramas de Componentes e de Distribuição. O fluxo do sistema e a interface com o usuário são apresentados no capítulo 4. Serão também documentadas situações importantes referentes ao aplicativo. A avaliação do sistema é relatada no capitulo 5. Nele, são explicitados os resultados do teste realizado após o lançamento do App na PlayStore, analisando desempenho e feedback dos usuários. Na conclusão são retratadas as dificuldades enfrentadas, conhecimentos adquiridos com o projeto da aplicação atual e sua alta escalabilidade, buscando melhorias que serão parte dos Planos Futuros. 4

16 Capítulo 2 Fundamentação Teórica 2.1 Facebook A maior rede social do mundo fornece uma área para desenvolvedores em seu website [1], onde existem tutoriais e manuais que explicam a sintaxe e como realizar consultas aos dados de seus servidores, além da autenticação de sistemas, criados pelos desenvolvedores, com o Facebook. Para consultar os dados do Facebook, como os eventos de um determinado usuário, é necessário realizar chamados aos servidores do Facebook, com as permissões necessárias concedidas. Existem casos que não será necessário conceder nenhum tipo de permissão, já que são dados públicos, porém a maioria irá necessitar, como é o caso das requisições feitas pelo Tiupar. Essas permissões, ao serem concedidas pelo usuário, geram um access token que é utilizado no request feito ao Facebook, e assim liberando as informações requisitadas. Existem duas formas de realizar requisições ao Facebook, através do FQL (Facebook Query Language) e Graph API (API baseada em HTTP). O FQL basicamente permite a realização de queries, sendo bastante similar ao SQL, porém com grandes limitações, como a inexistência da função Count, a qual retorna o número de linhas do resultado de uma consulta. O Facebook já anunciou, em sua área de desenvolvedores [1], que irá eliminar o FQL dentro de um ano, portanto este não foi utilizado para esse trabalho. O Graph API é a forma primária de se obter dados, utilizando o simples método HTTP-GET (Ver 2.3.1), e será mais bem explicado no tópico O Facebook também disponibiliza SDK s para diversos ambientes de desenvolvimento como PHP, JavaScript, Android e ios. No Tiupar foi utilizado apenas o Android SDK, que foi usado para autenticar o sistema com o Facebook através do Dispositivo Móvel Android do usuário e obter o seu uid e access token com as permissões concedidas necessárias para o funcionamento do sistema. Para realização de consultas no servidor com o ambiente PHP, haviam duas possibilidades: simples 5

17 chamadas via HTTP ou via PHP SDK. Optou-se pelo HTTP, pois a autenticação é realizada pelo Android, já trazendo os parâmetros necessários para fazer as consultas ao Graph API, o uso é mais simples, podem-se testar as consultas facilmente, apenas transcrevendo direto no browser, além de ser mais simples de migrar para qualquer linguagem no servidor capaz de realizar HTTP-GET e extrair os dados gerados. Mais detalhes sobre a extração de dados no servidor pode ser vista no tópico Graph API Como explicado anteriormente, é a API fornecida pelo Facebook para realização de leituras e escritas no Facebook, baseado em HTTP, o que quer dizer que funciona com qualquer linguagem que possua uma biblioteca HTTP. O nome Graph API vem da ideia de social graph, ou seja, uma representação da informação proveniente da rede social Facebook, a qual é composta por: nodes, edges e fields. Os nodes são os objetos principais, como usuários, eventos, páginas, comentários, fotos do Facebook. Edges são as conexões entre eles, como a foto de um evento, comentários em uma foto. Fields são as informações acerca desses objetos, como o nome de um evento e sua data de início. Para esse sistema, duas consultas são necessárias, uma para extrair os eventos que estejam por vir do usuário em questão e outra para extrair todos os participantes desses eventos. Para se obter acesso a essas informações, deve-se ter um access token válido além do id dos nodes User e Events, respectivamente. Figura 2.1 Graph API Explorer. Fonte: Graph API Explorer [2]. 6

18 O Facebook oferece uma ferramenta online, que pode ser acessada via browser, chamada Graph API Explorer [2], visto na Figura 2.1, na qual é possível obter um access token com as permissões desejadas e realizar as consultas ao Graph API. É uma ferramenta para se testar e validar consultas Facebook SDK O Facebook fornece SDK s para diferentes ambientes de desenvolvimento. Para este aplicativo, utilizou-se apenas a Android SDK. Uma SDK fornece classes e métodos que são necessários para realizar determinadas tarefas. Neste caso, fornece ferramentas que permitem realizar autenticação com os servidores do Facebook, criando uma sessão no ambiente do próprio aplicativo, além de se poderem realizar consultas via Graph API. No desenvolvimento do Tiupar, utilizou-se a SDK somente para autenticar o usuário com o Facebook, como pode ser visto no tópico 2.2.1, abrindo uma sessão com o ambiente da rede social. Através dela, é possível requisitar as permissões necessárias ao usuário, gerando-se um access token que, ao ser usado na consulta via Graph API, possibilita a extração de dados privados do usuário no Facebook. 2.2 Desenvolvimento Android O sistema operacional Android foi desenvolvido em um ambiente em camadas (ver Figura 2.2) baseado em kernel Linux. Possui suporte a diversos serviços, como acelerômetro, GPS, WiFi, bluetooth, entre outros. 7

19 Figura 2.2 Camadas da plataforma Android. Fonte: IBM developerworks[3]. Os aplicativos são programados na linguagem de programação JAVA, e executados em uma máquina virtual. No caso do Android, utiliza-se a Dalvik Virtual Machine atualmente. Cada aplicativo é executado em uma instância dessa VM. Para se desenvolver um aplicativo Android com UI, deve-se compreender minimamente o conceito de Atividades ou Activity. São as telas do aplicativo. Por exemplo, quando se seleciona um aplicativo na tela inicial do Dispositivo Android, uma atividade definida no AndroidManifest é iniciada. Existem também conceitos mais recentes, como Fragment, desenvolvido inicialmente para tablets, os quais possuem telas maiores. Criado pela necessidade de uma nova forma de programação para dispositivos móveis, adaptável aos diversos tamanhos de telas, permitindo-se ter telas dentro de telas, que na realidade seriam Fragments dentro de Activities. Para se utilizar os métodos das classes supracitadas e outras mais, deve-se utilizar o conceito de hereditariedade do JAVA, onde se define uma classe como extensão de outra classe pai, para se ter acesso aos métodos dessa classe pai. Como no exemplo a seguir, que a classe Setup é filha da classe Activity: 8

20 public class Setup extends Activity Autenticação com o Facebook A autenticação com o Facebook requer alguns passos para validar o APP Android a ser desenvolvido. Para que o acesso aos dados do Facebook seja concedido ao Tiupar, ele deve estar ligado a algum Aplicativo Facebook, que pode ser criado facilmente na página de desenvolvedores da rede social. Ao se criar um FacebookApp, um App ID e um AppSecret são gerados. O App ID é utilizado para se conectar o aplicativo Android ao Facebook. O AppSecret é usado para tornar mais segura as chamadas ao Graph API, ao utilizá-lo nas requisições. É necessário assinar também o Aplicativo Android usando uma keytool e openssl, gerando um código chamado keyhash. O seguinte comando deve ser executado: keytool -exportcert -alias <RELEASE_KEY_ALIAS> -keystore<release_key_path> openssl sha1 -binary openssl base64 A keyhash gerada deve ser associada ao FacebookApp, é uma forma de comprovar a autenticidade. As keyhashes normalmente são diferentes para Debug e para Release, o que justificaria a existência de várias para o mesmo FacebookApp, como é o caso deste projeto. Na Figura 2.2, é possível ver a página de configurações, onde se pode definir a plataforma Android, a Classe em que é realizada a autenticação com o Facebook e as keyhashes. 9

21 Figura 2.3 Aplicativo no Facebook. Fonte: FacebookDevelopers [1]. Após realizar os passos anteriores, permitindo a conexão segura com o Facebook, pode-se então desenvolver a autenticação em si no Android. Após importar a Facebook SDK e definir como biblioteca do projeto, o AndroidManifest deve ser preenchido com a Application Id para a Activity de Login presente na SDK, como pode ser visto a seguir: <activity android:name="com.facebook.loginactivity" android:theme="@android:style/theme.translucent.notitlebar" android:label="@string/app_name"/> <meta-data android:name="com.facebook.sdk.applicationid" android:value="@string/app_id"/> Isto sendo feito, finalmente pode-se realizar qualquer requisição com as funções e classes disponibilizadas pela Facebook SDK. Para se criar uma sessão com o Facebook pedindo as permissões necessárias para o funcionamento do App, basta escrever as linhas de código a seguir: if((session.openactivesession(this, false, statuscallback))==null){ 10

22 session.closeandcleartokeninformation(); session = new Session(this); Session.setActiveSession(session); if (!session.isopened() &&!session.isclosed()) { session.openforread(newsession.openrequest(this).setcallback(statuscallback).setpermissions(arrays.aslist("basic_info", "user_events"))); }}else{ Session.openActiveSession(this, true, statuscallback); } Com a sessão aberta, é possível realizar as requisições necessárias para se obter o access token do usuário, seu uid e seu sexo, como visto na figura 2.4, usados posteriormente para extrair os dados de eventos e seus participantes do Facebook, via Servidor, como descrito no tópico Figura 2.4 Comunicação Dispositivo Mobile Servidor Facebook AndroidManifest O AndroidManifest é onde são apresentadas informações essenciais sobre o aplicativo criado para o Sistema Operacional, as quais são necessárias anteriormente à execução do código. Elas são gravadas em um arquivo XML, chamado 11

23 AndroidManifest.xml. Ele inclui os nomes de classes necessários e os tipos de eventos que o aplicativo está pronto para processar, além das permissões necessárias que o aplicativo precisa para execução. Por exemplo, se um aplicativo exigir acesso à rede no caso do Tiupar, essencial para se conectar com o Facebook e com o Servidor do Sistema essa permissão deve ser declarada explicitamente neste arquivo. Define-se qual classe será chamada ao iniciar o aplicativo e, para este projeto, o Application Id para a conexão com o Facebook, como explicado no tópico anterior Classe Activity Uma Activity é um componente de uma aplicação Android, que fornece uma tela para que os usuários interajam e façam alguma coisa, como tirar uma foto, mandar um , ver um mapa, etc. Toda Activity possui um Ciclo de Vida (ver Figura 2.4), ou seja, passam pelas fases de criação, início, pausa, término, dentre outros. Em cada uma dessas fases é possível implementar código para que algo seja realizado na parte do fluxo desejada, através dos métodos chamados de callback methods. Figura 2.5 Ciclo de vida de uma Activity Fonte: AndroidDevelopers [1]. 12

24 Não é necessário implementar todos os callback methods, a não ser o oncreate(), primeiro a ser chamado e responsável por preparar a página, onde se chama o arquivo XML, contendo a parte visual da página, entre outros. Porém, é importante saber o que cada um faz e usá-los de forma que a interação com o usuário ocorra de forma esperada. Um resumo de quando cada método é chamado pode ser visto na Tabela 2.1. Tabela 2.1 Métodos Callback de uma Activity Callback oncreate() onstart() onresume() onpause() onstop() ondestroy() onrestart() Description É o primeiro callback e é chamado quando a atividade é criada pela primeira vez. Este callback é chamado quando a atividade fica visível para o usuário. Este callback é chamado quando o usuário começa a interagir com a aplicação. A atividade em pausa não recebe input do usuário e não pode executar nenhum código. É chamada quando a atividade atual está sendo pausada e a atividade anterior está sendo retomada. Este callback é chamado quando a atividade não está mais visivel. Este callback é chamado antes da atividade ser destruída pelo Sistema. Este callback é chamado quando a atividade é reiniciada após ter sido parada. No caso deste projeto, foram usadas Activity e alguns derivados, para a realização do FacebookLogin já explicada anteriormente - e do Setup. O Setup é onde as requisições são enviadas com as informações do usuário para o Servidor via HTTP- POST, o qual as utiliza para extrair os eventos e seus participantes e gravá-los no Banco de Dados do Sistema. Durante a execução dessas requisições, um vídeo de introdução é 13

25 exibido ao usuário, até que elas sejam concluídas, a Activity seja destruída pelo sistema, e então, chama-se a FragmentActivity, detalhada a seguir Classe Fragment É um pedaço de interface com o usuário ou comportamento de uma aplicação que pode ser colocado em uma Activity, como uma espécie de subatividade, permitindo um design mais modular e flexível. Por exemplo, é possível remover ou adicionar um Fragment em uma Activity enquanto a mesma está rodando. Como uma Activity, o Fragment também possui um Ciclo de Vida próprio (Ver Figura 2.5), porém, estritamente ligado ao Ciclo de Vida da sua Activity, o que significa que, se, por exemplo, a última for parada por algum motivo, os Fragments ligados a ela serão parados também, independentes de que estado eles estejam no momento. Figura 2.6 Ciclo de vida de um Fragment Fonte: AndroidFragments [5]. 14

26 Fragments possuem callback methods também, havendo os métodos básicos presentes em uma Activity, mas existindo outros métodos relacionados a interações com sua Activity e geração de UI. Detalhes sobre esses métodos podem ser visualizados na Tabela 2.2. Tabela 2.2 Métodos Callback de um Fragment Callback onattach(activity) oncreate(bundle) oncreateview(layoutinflater, ViewGroup, Bundle) onactivitycreated(bundle) onstart() onresume() onpause() onstop() ondestroyview() ondestroy() ondetach() Description Chamado assim que o Fragment é associado com a sua Activity. Chamado para realizar a criação inicial do Fragment. Cria e retorna a hierarquia de views associada ao Fragment. Avisa ao Fragment que sua Activity completou seu método oncreate(). Torna o Fragment visível para o usuário. Permite o usuário comece a interagir com o Fragment. Não ocorre mais interação com o usuário, seja porque sua Activity esteja sendo pausada ou o Fragment esteja sendo modificado. Fragment não está mais visível ao usuário, seja porque sua Activity esteja sendo parada ou o Fragment esteja sendo modificado. Permite a limpeza dos recursos associados a View do Fragment. Chamado para fazer a limpeza final do estado do Fragment. Chamado logo antes do Fragment ser desassociado de 15

27 sua Activity. No caso deste projeto, foram usados Fragments e alguns derivados, como o ListFragment (responsável pela criação de listas Fragment no Android), para a criação de todas as 5 telas com a qual o usuário interage e checa as informações de seus eventos. Todos eles estão associados a uma FragmentActivity, detalhada no tópico a seguir, responsável por gerenciar e organizar como serão exibidos esses Fragments Classe FragmentActivity Subclasse da classe Activity, possuindo acesso às APIs de Fragment e Loader com suporte à versões antigas do SO Android, anteriores à criação da classe Fragment(inserida na versão 3.0 do Android) e, portanto, sem suporte à gerenciadores de Fragment. Desta forma, é possível utilizar o aplicativo mesmo em versões do Android 1.6. Se não houvesse interesse em suportar versões anteriores à introdução de Fragment, bastaria utilizar a classe Activity, que teria papel similar no sistema, porém optou-se por dar abrangência ao maior numero possível de dispositivos, sem perder as características de desenvolvimento dos aplicativos mais recentes. A classe FragmentActivity é fornecida em um pacote chamado android.support.v4.app, o qual possui classes que ajudam no desenvolvimento de aplicativos com android API level 4 equivalente ao Android ou posterior. Basta importar esse pacote - como qualquer outra biblioteca - e a classe FragmentActivity já pode ser utilizada. A classe Fragment necessita de uma Activity para sua existência, como explicado no tópico anterior, e a FragmentActivity possui esse papel neste APP. Ele se utiliza do método getsupportfragmentmanager() para poder interagir com os Fragments ligados à ele, definindo uma actionbar, contendo a forma como as páginas são ordenadas, os nomes e os ícones de referência para cada uma delas. Ele também possui os dados do usuário, como seu uid e Access token, que podem ser acessados pelos Fragments para que as chamadas ao Servidor sejam feitas em cada um deles. 16

28 2.3 Desenvolvimento Servidor Amazon Para o Servidor, fez-se necessário a configuração de um ambiente, em uma máquina, que incluiria uma linguagem de script, um banco de dados e um web server. O primeiro permite os tratamentos dos dados enviados pelo cliente e a conexão com o banco de dados, assim como a extração de dados do Facebook baseados nas informações enviadas pelo dispositivo Mobile, a qual é descrita no tópico O banco de dados tem o papel de armazenar os dados dos clientes. E o web server é o que permite essa conexão via HTTP, através dos métodos descritos no tópico A Amazon, empresa de comércio eletrônico, foi a pioneira no serviço de fornecimento de servidores na nuvem. O motivo desse pioneirismo é devido a altas demandas de acesso em seu web site em períodos específicos de compra no ano, como o natal ou a blackfriday nos EUA, exigindo a existência de grandes redes de computadores para suprir essa demanda. Porém, muitas dessas máquinas ficavam ociosas fora das épocas de pico, as quais acabaram sendo alugadas através deste serviço de nuvem. Optou-se por utilizar os serviços da Amazon pelo custo ser muito inferior ao de usar uma máquina pessoal como Servidor, o interesse pelo aprendizado da computação em nuvem, a simplicidade em se configurar ambiente, dentre outros. Obviamente, existem outras empresas que fornecem serviços similares, porém a Amazon foi escolhida por ser a pioneira e mais utilizada por desenvolvedores. O serviço utilizado chama-se EC2, ou Elastic Compute Cloud, sendo chamado assim por ter a característica de se adequar à demanda, ou seja, caso haja necessidade um poder de processamento maior em determinado período, ou algo do gênero, o servidor irá suprir essa demanda, convertendo isso em custo para o cliente. Claro que existe a opção de se bloquear essa elasticidade, porém não é recomendável. Uma máquina pessoal foi utilizada para o desenvolvimento, enquanto uma t1.micro da Amazon para produção. A t1.micro com Sistema Operacional Linux é a configuração mais simples e também mais barata de servidor da Amazon, escolhida para esse projeto inicialmente para uma fase de testes com poucos usuários, pretendendo-se migrar para versões mais robustas de acordo com o crescimento de usuários e a divulgação do produto. 17

29 2.3.1 Métodos HTTP-POST e HTTP-GET O HTTP possibilita comunicação entre clientes e servidores, funcionando como um protocolo de requisição-resposta entre eles. O cliente pode ser um browser ou até mesmo um Aplicativo em um Dispositivo Mobile, enquanto o servidor poderia ser uma aplicação em um computador hospedando um website. Para a realização dessa comunicação, existem os métodos HTTP-POST e HTTP- GET. O primeiro é usado quando se deseja enviar dados a serem processados pelo servidor, enquanto o segundo requisita dados ao servidor. Utilizou-se o método GET para requisitar os dados do Servidor do Facebook via Graph API, enquanto o POST fora utilizado para enviar dados ao Servidor do Sistema, os quais são tratados no Tiupar CORE e enviados ao cliente Extraindo dados do Facebook Através do método GET, citado no tópico anterior, é possível requisitar dados diretamente do Facebook via Graph API. Com as informações de access token e uid fornecidos pelo cliente, obtém-se dados privados de eventos e seus participantes deste usuário. Os dados provenientes do Facebook vêm na sintaxe JSON, um formato leve para troca de dados e de uso e entendimento mais simples que XML. Portanto, faz-se necessária uma leitura desses dados neste formato para que sejam gravados no Banco de Dados do sistema, sendo independente da linguagem, apesar de ter embasamento na sintaxe do JavaScript. Figura 2.7 Exemple de leitura via Graph API em sintaxe JSON Fonte: FacebookDevelopers [1]. 18

30 Utilizou-se PHP para tal, através do método file_get_contents(), passando-se como argumento o link da query no Graph API. Este método faz a leitura de um arquivo e o transforma em string. Depois, usou-se o método json_decode(), responsável por decodificar uma string codificada em JSON e transformá-lo em um array, o qual pode ser mais facilmente manipulado e, enfim, gravar esses dados no banco. Esse processo de extração foi feito em dois ciclos, ou seja, duas queries diferentes para o Graph API. A primeira para a obtenção dos eventos do usuário, assim como quantidade de pessoas confirmadas, privacidade do evento e horário de inicio. A segunda, baseada nos eventos extraídos anteriormente, usados para se conseguir cada participante desses eventos e o sexo de cada um. 19

31 Capítulo 3 Modelagem do Sistema 3.1 Materiais e Métodos Para se desenvolver um aplicativo para o dispositivo Android, é necessária a utilização da linguagem JAVA e do Android SDK, para qual existem diversas ferramentas disponíveis que ajudam no trabalho de desenvolvedores. Uma delas, recomendada pela Google, criadora do Sistema Operacional Android, é a IDE Eclipse + ADT Bundle. É possível baixar diretamente do site oficial de desenvolvedores Android o pacote[6] que inclui a IDE Eclipse com o plugin ADT, Android SDK Tools, AndroidPlatfrom-Tools, uma versão da plataforma Android e uma versão de imagem do sistema Android para emuladores. Para realizar a autenticação com o Facebook via Android, é obrigatória a utilização do Facebook SDK para Android[7], o qual possui alguns exemplos práticos e biblioteca contendo métodos essenciais para realizar essa conexão com o Servidor do Facebook e criar uma sessão autenticada para o usuário. Outro material necessário é o Servidor, onde são extraídos e gravados os dados extraídos do Facebook e as avaliações de usuários. O servidor é um EC2 proveniente da empresa Amazon, e está localizado na cidade de São Paulo. A máquina utilizada é a t1.micro, que possui 0,613 GiB (Gibibyte, com valor idêntico ao GB em termos de bytes) de Memória RAM. Seu sistema operacional é o Linux e alguns softwares tiveram que ser instalados para o funcionamento do sistema, como o MySQL, o APACHE e o PHP. Neste servidor, são armazenados os dados num Banco de Dados MySQL e utiliza-se a linguagem PHP para se extrair dados do Facebook. O Facebook fornece suporte através de sua SDK somente a essa linguagem e a JavaScript. A escolha do PHP se deve ao fato de os desenvolvedores já terem intimidade com a linguagem, além da grande comunidade programadora e a quantidade de informações sobre ela que podem ser encontradas na Internet. 20

32 Mais detalhes sobre a implementação do Banco de Dados e definição de sua estrutura e entidades podem ser vistas no tópico Modelo de Dados A definição do modelo de dados se deu a partir das três entidades definidas para o sistema. São elas: Participantes, Usuários e Eventos. Participantes são todos os participantes de eventos no Facebook, sendo esses eventos provenientes dos usuários do Aplicativo, o que quer dizer que serão extraídos somente participantes que condizem com os utilizadores do Tiupar. São representados pelos seus uid s, identificadores de usuário do Facebook, ou, user id. Todo participante deve possuir um sexo e uma nota. Um ajuste de peso se faz necessário para o cálculo da nota média e também para auxiliar no algoritmo de exibição de participantes, o qual evita mostrar pessoas repetidas, como é explicado no tópico Eventos são representados pelos seus eid s, os identificadores de eventos do Facebook, ou, event id. Os eventos que estejam por vir dos usuários do Aplicativo são extraídos do Facebook e gravados no Banco de Dados. Cada evento possui nome, lugar, horário de início, nota para mulheres e para homens, nota para local, nota para custo, nota para diversão, nota total considerando a nota dos homens, nota total considerando a nota das mulheres, porcentagem de homens, porcentagem de mulheres e número total de participantes. Os pesos são utilizados para o cálculo das notas médias, sendo desnecessários para a notahomem e notamulher, já que ambos são apenas extraídos da tabela participantes, que possui seus próprios pesos, como dito no paragrafo anterior. As notas totais também não precisam de peso, pois são obtidas realizando-se a média das outras notas, sendo o cálculo da notatotalmulher feita com a notamulher e ignorando a notahomem, e vice-versa para notatotalhomem. Usuários são representados por uma chave composta de uid e eid, ambas as chaves estrangeiras provenientes das Entidades superiores Eventos e Participantes. O nome usuarios é por ser onde se define quais participantes de eventos são usuários do sistema e de qual tipo são. Os tipos são apenas relacionados a preferência sexual do usuário, existindo as opções de se preferir sexo feminino, masculino ou ambos. Os dados dessa tabela representam cada relação entre participantes e eventos, ou seja, guarda-se quem foi ou vai a cada evento especificamente, além de possuir o flag contendo o tipo de usuário e o flag para indicar preenchimento de formulário. 21

33 O modelo relacional do Banco de Dados é baseado em 2 relações 1:N, da tabela participantes para usuarios e da eventos para usuarios. Essa relação é explicada por um participante poder possuir mais de um evento e um evento poder possuir mais de um participante. Como pode ser visto na Figura 3.1. Figura 3.1 Estrutura de Dados. É importante ressaltar que a estrutura de dados poderia ter sido montada de outra forma, como fora inicialmente um relacionamento N:N, apenas entre participantes e eventos. Porém, por motivos de desempenho, criou-se essa nova entidade usuarios. Dessa forma evitando o uso de joins que poderiam aumentar o tempo de execução de determinadas consultas ou queries. Anteriormente, era necessário relacionar os dados de eventos com os de participantes todas as vezes que se desejasse realizar uma consulta para identificar que participantes estão em que eventos. Criando-se essa nova entidade, essa relação evento-participante é definida no momento de inserção no banco, permitindo consultas mais rápidas Na tabela a seguir, é possível verificar o dicionário de dados, o qual descreve, com mais detalhes, as colunas geradas ao se criar as tabelas exibidas na Figura

34 Tabela 3.1 Dicionário de Dados Campo Descrição Informações participantes Contém os atributos da tabela participantes id Índice Identificador único usado para obtenção mais rápida de participantes uid Id de usuário do facebook Identificador único e chave primária sex Sexo do usuário do facebook Existem pessoas que não definem seu sexo no Facebook, essas pessoas ficam como NULL notahomem Nota de empatia para pessoa do sexo masculino notamulher Nota de empatia para pessoa do sexo feminino pesohomem Peso para a notahomem Utilizado para calcular a média de notahomem pesomulher Peso para a notamulher Utilizado para calcular a média de notamulher usuarios Contém os atributos para a tabela usuarios uid Id de usuário do facebook Identificador único e chave estrangeira eid Id de evento do facebook Identificador único e chave estrangeira isuser Flag para indicar tipo de usuário 0 Não é usuário do sistema 1 Usuário com preferência pelo sexo feminino 2 Usuário com preferência pelo sexo masculino 3 Usuário com preferência por ambos os sexos preencheuformulario Flag para indicar preenchimento de 0 Usuário não 23

35 eid name lugar t notahomem notamulher notalocal pesolocal notacusto pesocusto notadiversao pesodiversao notatotalhomem notatotalmulher porcentagemdehome ns porcentagemdemulhe res numerototal formulário preencheu formulário 1 Usuário preencheu formulário eventos Contém os atributos para a tabela eventos Identificador único e Id de evento do facebook chave primária Nome do evento Lugar do evento Horário de inicio do evento Nota de empatia para pessoa do sexo masculino Nota de empatia para pessoa do sexo feminino Nota para o local do evento Utilizado para Peso para notalocal calcular a média de notalocal Nota para o custo do evento Utilizado para Peso para notacusto calcular a média de notacusto Nota para a diversão do evento Utilizado para Peso para notadiversao calcular a média de notadiversao Nota final baseada na notahomem Nota final baseada na notamulher Porcentagem de homens com presença confirmada no evento Porcentagem de mulheres com presença confirmada no evento Numero total de pessoas com presença confirmada no evento 3.3 Diagrama de Componentes e de Distribuição O Diagrama de Componentes é responsável por exibir os elementos reutilizáveis de software e sua interdependência. Um componente é definido por um conjunto de classes implementadas nele, o qual, assim como suas classes, depende de outras classes contidas em outros componentes. 24

36 O Diagrama de Distribuição exibe a distribuição de Hardware do sistema, sendo os blocos representantes de máquinas computacionais e são chamados de nós. Os componentes de Software ficam mapeados nesses nós. A arquitetura do sistema representada por esse diagrama, contendo componentes de Software e Hardware e as suas relações, podem ser vistas na Figura 3.2. Figura 3.2 Diagrama de Distribuição. As setas entre os componentes indicam acionamento na direção a qual estão apontando. Por exemplo, Facebook SDK, contido em Dispositivo Móvel, aciona Graph API, contido em Facebook. O nó Dispositivo Móvel representa a interface que o usuário tem com o sistema, é de onde o sistema será acessado por ele e de onde se farão necessárias a autenticação, assim como a comunicação e troca de dados entre os outros nós. Ele possui os componentes Tiupar GUI, Autenticador e Facebook SDK. O Tiupar GUI é a interface em que o usuário poderá navegar após ter realizado o passo inicial de autenticação e os dados terem sido extraídos. Caso seja o primeiro acesso dele, ele possibilitará ao usuário clicar em Entrar com o Facebook e acionar o Autenticador, que, por sua vez, acionará a Facebook SDK, através da aceitação de permissões de acesso do Facebook, como pode ser observado no fluxo de Autenticação no Sistema, tópico 4.1. Caso o usuário já tenha acessado o sistema anteriormente, o processo de 25

37 autenticação continuará ocorrendo, porém de forma automática. O Autenticador utiliza classes implementadas na biblioteca Facebook SDK, realizando a comunicação com o Graph API, que permite a extração de dados do Facebook. Após a validação com o Facebook, ocorre o acionamento do Tiupar Core pelo método HTTP-POST, possibilitando a gravação dos dados extraídos do Facebook no Servidor e o acesso à essas informações úteis ao usuário. O nó Facebook é a Rede de Servidores de onde são retiradas todas as informações de participantes e eventos. Ele possui o componente Graph API que é acionado em duas etapas, primeiramente pelo Dispositivo Mobile, através da autenticação e do Facebook SDK, explicada no paragrafo anterior, e depois pelo Servidor e seu componente Adaptador Facebook. O usuário, ao abrir o aplicativo em seu Smartphone, irá acionar um método de autenticação com o sistema. Essa autenticação realiza comunicação direta com os servidores do Facebook, e valida as permissões necessárias, como acesso aos eventos do usuário, para que os processos de extração e gravação de dados do Facebook para o Servidor" possam ocorrer. Após o acionamento do Tiupar CORE, o Adaptador Facebook é acionado em sequência e realiza o método HTTP-GET para extrair os dados do Facebook, através do Graph API. Enfim, o nó Servidor, responsável por armazenar todos os dados úteis ao sistema e ao usuário, além de fazer os tratamentos e regras de negócios, os processando para que sejam enviados aos usuários de forma agradável e intuitiva. Ele possui três componentes fundamentais ao sistema: Tiupar CORE, Adaptador Facebook e Banco de Dados. O Tiupar CORE controla todas as funcionalidades do Servidor, ele que irá acionar a gravação e a extração de dados do Banco de Dados ou a conexão com o Facebook, através do Adaptador. O Adaptador Facebook é apenas uma forma de comunicação com os servidores do Facebook, acionando a Graph API através do método HTTP-GET, e permitindo ao CORE extrair os dados que são posteriormente gravados. O Banco de Dados é onde se gravam os dados extraídos do Facebook, os atualizam e de onde se realizam consultas para exibi-los aos usuários, devidamente tratados. O fluxo normal do Servidor ocorre com o acionamento do Tiupar CORE, o qual aciona o Adaptador Facebook para que ocorra a extração de dados e, em paralelo, aciona o Banco de Dados para que o que for extraído seja gravado ou atualizado. Então, o Banco é acionado novamente para a realização de diversas consultas, proporcionando a exibição dos dados ao usuário nas páginas do Tiupar. Como esses dados são exibidos está exemplificado no Capitulo 4. É importante salientar 26

38 que, após a extração realizada pelo Adaptador Facebook, o Servidor não realiza mais contato direto com o Facebook, utilizando-se somente das informações recémguardadas no Banco do sistema. Para que os dados extraídos sejam mais recentes, devese reabrir o aplicativo, para que se realize o setup, ou seja, o fluxo se repita. 27

39 Capítulo 4 Fluxo do Sistema 4.1 Autenticação no Sistema Ao iniciar o aplicativo pela primeira vez, serão exibidas as seguintes telas de introdução, deslizáveis, contendo um botão para realizar a autenticação com o Facebook, de nome Entrar com o Facebook. Figura 4.1 Telas de Introdução. Ao clicar nesse botão o sistema irá exibir uma mensagem requisitando as permissões perfil público, lista de amigos e eventos do Facebook para o usuário. 28

40 Figura 4.2 Autenticação com o Facebook. Caso o usuário pressione OK, a autenticação estará concluída e o vídeo de entrada apresentando uma animação com a logo do Tiupar será exibido. Vale ressaltar que o procedimento de autenticação torna-se automático após o primeiro uso, não havendo mais necessidade de acessar as telas de introdução exibidas na Figura 3.3, e consequentemente clicar no botão Entrar com o Facebook. O usuário é direcionado diretamente ao vídeo de entrada, quando inicializa o aplicativo. Ao término da autenticação, o sistema irá carregar os dados de eventos e de seus participantes do Facebook, a fim de prepará-los para exibição nas diversas telas disponíveis. Durante esse processo, a mensagem Carregando... é exibida. As telas são agrupadas segundo cinco ambientes de trabalho: Evento, Histórico, Avaliar, Formulários e Configurações. Estes ambientes são materializados através de cinco abas, sendo a primeira delas a de Eventos. 4.2 Ambiente de Eventos Neste ambiente são exibidos os eventos que estejam por vir e que o usuário tenha confirmado presença no Facebook. 29

41 Figura 4.3 Ambiente de Eventos. Serão exibidas, para cada evento, as porcentagens de homens e mulheres presentes nesta atividade, a nota de empatia e o total de usuários. A exibição é feita por ordem cronológica crescente. Se o usuário possuir mais de 10 eventos a serem listados, somente os 10 mais próximos serão listados e haverá o botão Carregar Mais ao fim da lista. Ao clicar nesse botão, serão carregados mais 10 eventos e assim sucessivamente, até que haja menos de 10 eventos a serem carregados. Outra funcionalidade é a possibilidade de acesso a página do evento no Facebook para checar mais informações. Quando o usuário clicar em um evento na lista, ele será redirecionado para sua página no aplicativo do Facebook. Caso o usuário não possua o aplicativo do Facebook instalado em seu dispositivo Mobile, então será redirecionado ao aplicativo de browser padrão, contendo a página do evento no Facebook. Caso o usuário não possua eventos a serem listados, o sistema exibe tela padrão pedindo para que ele confirme eventos futuros no Facebook e volte a tentar novamente. 4.3 Tela Histórico Caso o usuário deseje visualizar seu histórico de eventos, desde que começou a utilizar o aplicativo, ele poderá selecionar a segunda aba. 30

42 Figura 4.4 Tela Histórico. Nesta tela, serão exibidos os eventos que já passaram e que o usuário confirmou presença desde que começou a utilizar o sistema. A exibição é feita por ordem cronológica decrescente. Como na aba Eventos, se o usuário possuir mais de 10 eventos a serem listados, o procedimento seguido será o mesmo que o citado no tópico anterior. Caso ainda não existam registros de eventos no histórico para o usuário, o sistema exibe tela padrão pedindo que retorne mais tarde, quando o histórico possuir eventos. Também é possível expandir os eventos ao clicar, exibindo informações detalhadas de notas sobre ele: nota para local, nota para custo, nota para empatia, nota para diversão e a nota final para o evento. Como pode ser visto na Figura 4.5: 31

43 Figura 4.5 Tela Histórico com item expandido. 4.4 Tela Avaliar Caso o usuário deseje avaliar os participantes de eventos que estejam por vir e que ele tenha confirmado presença no Facebook, ele poderá selecionar a terceira aba. Figura 4.6 Tela Avaliar. Aqui, serão exibidas aleatoriamente pessoas que confirmaram presença em um ou mais eventos por vir, e que o usuário também confirmou presença, no Facebook. 32

44 A ordem que as pessoas são exibidas é da menor quantidade de avaliações recebidas para a maior, ou seja, pessoas que já foram avaliadas vão para o final da fila até que todos os outros participantes de eventos sejam votados. Isso é feito para que se evite a repetição de pessoas constantemente, já que o algoritmo de aleatoriedade possui a possibilidade de exibir pessoas repetidas, principalmente quando se tem poucos participantes a serem votados. Dessa forma, todos os usuários sempre irão avaliar pessoas não avaliadas ou menos avaliadas, sendo esperado que todos os participantes de seus eventos sejam avaliados, e então se possa calcular uma média mais precisa para os eventos. Esses participantes são carregados em uma pilha de pessoas, que são exibidos em sequência para o usuário, à medida que ele atribui uma face equivalente a uma nota - à pessoa. Quando essa pilha acaba, é exibida a mensagem Carregando... e uma nova pilha é carregada para ser exibida, repetindo-se o processo. Como na tela Eventos, caso o usuário não possua eventos por vir e que ele esteja confirmado no Facebook, o sistema exibe tela padrão pedindo para que ele confirme eventos futuros no Facebook e volte a tentar novamente. 4.5 Tela Formulários Caso o usuário deseje avaliar os eventos que já passaram, desde que ele utilizou o aplicativo, ele poderá selecionar a quarta aba. 33

45 Figura 4.7 Tela Formulários. Nesta tela, serão exibidos os eventos do Histórico, porém, somente os que o usuário ainda não preencheu o formulário correspondente, ou seja, não avaliou ou informou que não compareceu. Comparando a imagem da Figura 4.7com a da tela Histórico (Figura 4.4), é possível observar que não existe boa parte dos eventos. Isso ocorre porque esses eventos já foram avaliados anteriormente pelo atual usuário. A exibição dos eventos não avaliados é feita por ordem cronológica decrescente. Como na aba Eventos, se o usuário possuir mais de 10 itens a serem listados, o procedimento seguido será o mesmo que o citado no tópico Caso não existam formulários para preencher, o sistema exibe tela padrão pedindo que retorne mais tarde, quando o histórico possuir eventos. Para se preencher um formulário, deve-se expandir os eventos com um clique, exibindo opção de avaliar local, custo e diversão do evento. Como pode ser observado na Figura

46 Figura 4.8 Tela Formulários com item expandido. Ao pressionar o botão Fui!, o sistema irá remover o evento avaliado da lista, gravar as notas dadas e registrar que o formulário foi preenchido. Ao pressionar o botão Não fui!, o sistema irá remover o evento da lista, porém sem gravar nenhuma nota, somente registrando que o formulário foi preenchido pelo usuário. 4.6 Tela Configurações Caso o usuário deseje trocar sua preferência sexual, contactar os desenvolvedores ou acessar a página do Facebook do aplicativo, ele poderá selecionar a quinta aba. 35

47 Figura 4.9 Tela Configurações. Nesta tela, o logo do sistema Tiupar é exibido, dá-se a opção de troca de preferência sexual ao usuário, assim como opções de contato via ou Facebook. Se o usuário decidir definir uma nova opção sexual, é possível selecionar os Checkboxes de que sexo procura e pressionar o botão Confirmar. O sistema irá recarregar as outras quatro telas, adequando, para a nova preferência, as notas, nas abas Eventos e Histórico, e participantes a serem exibidos, na aba Avaliar. O usuário também será redirecionado à aba Avaliar, para que possa verificar participantes, de acordo com sua nova preferência sexual. Quando o usuário clicar no texto contendo o , ele receberá uma mensagem perguntando qual aplicativo de ele deseja usar. Ao escolher uma opção, irá para o aplicativo de , já com o destinatário preenchido com o dos desenvolvedores. Quando o usuário clicar no texto contendo o endereço para o Facebook, ele será redirecionado para sua página no aplicativo do Facebook. Caso o usuário não possua o aplicativo do Facebook instalado em seu dispositivo Mobile, então será redirecionado ao aplicativo de browser padrão, contendo a página do evento no Facebook. 36

48 Capítulo 5 Avaliação do Sistema Para avaliar o feedback dos primeiros usuários e realizar testes, foi enviado um para a lista de alunos da Escola Politécnica da UFRJ, contendo o link para download na Google Play, um texto explicativo sobre o APP e o Google Form exibido na Figura 5.1. Figura 5.1 Formulário de avaliação do sistema. 37

49 É importante informar que a análise dos feedbacks dos usuários, realizada nos próximos parágrafos, exige algumas suposições e subjetividades inerentes a esse tipo de pesquisa, já que não é possível determinar de forma simples e científica o pensamento subjetivo de cada indivíduo ao interpretar e avaliar as funcionalidades do Tiupar. Durante uma semana, 51 pessoas preencheram o formulário e cerca de 100 instalações do aplicativo foram realizadas, nota-se na Figura 5.2 que ocorrera um crescimento nas instalações do APP exatamente quando este fora divulgado. Muitas delas foram extremamente contrárias à ideia, não testando o APP e mesmo assim avaliando negativamente as outras opções. Enquanto outras ficaram muito excitadas com a ideia, ainda sugerindo melhorias e realizando críticas construtivas. Figura 5.2 Instalações do aplicativo. A reação negativa dessas pessoas se deve ao fato de que o assunto avaliação de beleza é bastante polêmico. Criou-se uma grande discussão ao redor disso na lista de e- mails dos alunos das diversas engenharias da UFRJ, alguns a favor e outros contra. Alguns interpretaram que o APP seria machista, o que não é verdade, já que existe a opção de troca de preferência sexual, permitindo o uso para ambos os sexos, e também, para indivíduos homossexuais e bissexuais. Outros falaram que beleza é algo subjetivo, e que não resumiria-se somente aos atributos físicos exibidos em uma foto de perfil do Facebook de outra pessoa, porém, o único tipo de dado possível de se extrair e mostrar ao usuário de forma simples e direta é a sua foto de perfil. Qualidades inerentes à pessoa podem ser conhecidas através de convívio com ela. E é claro que o que é agradável para um pode ser desagradável para outro e vice-versa, porém a ideia do aplicativo é obter uma média dessas avaliações subjetivas e consolidar uma nota de empatia final para cada evento, auxiliando o usuário a decidir em qual evento ir, e não determinar qual será esse evento. 38

50 O modo como o texto explicativo sobre o APP enviado por também pode ter influenciado às pessoas, pois fora escrito de forma simples e direta, sem entrar em muitos detalhes, permitindo diversos entendimentos diferentes sobre a utilização do Tiupar pelos alunos. Inclusive, foi interessante avaliar a reação das pessoas e também acabou por ajudar a impulsionar os downloads do aplicativo, atraindo muitos curiosos para testá-lo, já que gerou tanta discussão. Portanto, devido às interpretações ao redor deste assunto polêmico, pode-se dividir a pesquisa de opinião em dois grupos: os que não gostaram da ideia e os que gostaram. Os que não gostaram são os que classificaram a ideia, ou seja, a primeira pergunta do Google Form, com a nota 2 ou menor. Enquanto os que gostaram, são os que classificaram com a nota 3 ou superior. A distribuição dos que gostaram e não gostaram do APP é exibida abaixo: Figura 5.3 Empatia pelo APP. Nota-se, pelo gráfico acima, que 55% dos que preencheram o formulário não gostaram da ideia do aplicativo. Ainda que não haja condições de realizar uma análise estatística mais aprofundada, pode-se considerar a diferença de 5% um valor marginal, e assim afirmar que metade achou a ideia boa e a outra metade não. É interessante salientar que a maioria dos votos negativos ocorreu logo no início da divulgação, enquanto os votos positivos foram aparecendo nas horas seguintes. Atitude psicológica do ser humano é se manifestar rapidamente se não gostar de algo, 39

51 nesse caso, uma ideia. E os que gostam, querem testar e usar para ter uma opinião sólida do aplicativo, o que demanda mais tempo e justifica a demora na manifestação desses. Figura 5.4 Empatia pelo layout do APP. Figura 5.5 Avaliação do Desempenho do APP. Os gráficos nas figuras 5.4 e 5.5 demonstram dados não muito confiáveis devido às más interpretações do aplicativo. A maioria das notas 1 dadas ao layout e desempenho foi originada pela compreensão negativa que tiveram do aplicativo, como pôde ser observado pelos comentários no Google Form associados a essas notas, e surgiram sem as pessoas ao menos terem tempo para testar o Tiupar, já que, após 40

52 poucos minutos da divulgação, preencheram o Google Form. Para se responder essas questões seria mandatório ter testado o APP anteriormente, porém não havia como controlar o preenchimento do Google Form, filtrando os que não baixaram e utilizaram o Tiupar. Desconsiderando isso, é possível observar que a maioria das avaliações foi mediana, o que é bom para um protótipo ainda não comercial. As avaliações para o layout foram melhores em relação ao desempenho, possivelmente pelo layout ser moderno e condizer com o próprio esquema do Aplicativo Facebook, que possui as 5 abas deslizáveis, como o Tiupar. O desempenho também está atrelado à quantidade de eventos que o usuário possui e se esses eventos possuírem muitos participantes a serem extraídos, tendo-se muitos deles, o carregamento será mais lento. Outro motivo para o desempenho ter recebido votos negativos foi devido a bugs que ocorreram, travando o aplicativo para algumas pessoas, os quais foram corrigidos e estavam, em maioria, relacionados ao fato de serem novos usuários sendo cadastrados de forma inconsistente no banco, sem acionar o flag isuser. Essa falha se originou devido a algumas melhorias no desempenho na parte de requisições ao Servidor, sendo algumas delas feitas desnecessariamente e prejudicando a usabilidade, porém, ao se remover algumas delas, acabou-se por eliminar também o acionamento do flag isuser para alguns usuários novos. Assim que se detectou o erro, as correções foram feitas rapidamente pelos desenvolvedores. Figura 5.6 Frequência de uso do APP. 41

53 Figura 5.7 Frequência de avaliação de participantes. Nas figuras 5.6 e 5.7, que remetem à frequência de uso do aplicativo, podem-se ver claramente as evidencias das avaliações negativas sobre o Tiupar. Os que não gostaram, vide Figura 5.3, obviamente nunca utilizarão o aplicativo. A segunda opção mais votada foi a de utilizá-lo de 1 a 2 dias da semana, o que se justifica devido à maioria procurar eventos para se divertir durante o fim de semana. Já os outros votos remetem aos usuários que realmente aprovaram a ideia. Um dado curioso foi que nenhuma pessoa utilizaria de 5 a 6 dias da semana, provavelmente por que, se gostaram tanto ao ponto de usar mais de 4 dias, poderiam usar todos os dias da semana. Enfim, as críticas e sugestões foram muito importantes para que a equipe Tiupar pudesse entender o que os usuários querem e direcionar ao desenvolvimento de novas funcionalidades, como possibilidade de avaliar música ou saber a quantidade de amigos que irão ao evento. Também ajudaram a perceber que avaliar beleza é algo muito polêmico, o que pode ser ruim ou bom, já que, apesar de muitas avaliações negativas, ajudou a popularizar o APP rapidamente, algo similar ao que o ocorreu com o aplicativo Lulu[8], há algum tempo atrás. 42

54 Capítulo 6 Conclusão Ao se realizar uma análise crítica do trabalho, pode-se concluir que os objetivos traçados inicialmente foram cumpridos. Isto é, foi possível adquirir conhecimento e desenvolver o sistema passando pelas três partes envolvidas: Facebook, Servidor e Android. Em relação ao Facebook, aprendeu-se a forma como os dados são tratados e disponibilizados pela rede social. As ferramentas liberadas para o uso, incluindo as SDK s para dispositivos mobiles e servidores. No Servidor, pode-se acrescentar conhecimento ao pouco que já havia sobre web services e computação em nuvem, além de aprofundar-se em PHP e MySQL. Os maiores desafios de desenvolvimento se encontraram no Android, pois a quantidade de conceitos novos a serem aprendidos era muito grande. O pouco conhecimento em JAVA também dificultou, como o entendimento de threads e AsyncTasks. Importante salientar as dificuldades que surgiram à medida que a base de dados aumentou com o crescimento de usuários, exigindo um tratamento melhor nas consultas, de forma que aumentasse o desempenho. Por exemplo, inicialmente fazia-se uma consulta para cada participante exibido na tela Avaliar, o que leva bastante tempo, já que exige uma consulta contendo todas as tabelas do banco de dados. A solução encontrada foi buscar uma quantidade grande de participantes de uma vez, e gravar em um array no código feito para o Android. Interessante fora observar a reação das pessoas e obter o feedback delas através da avalição do sistema, realizada no capitulo 5. Puderam-se absorver sugestões e críticas para que se apliquem algumas atualizações no APP futuramente, como avaliar música, saber a quantidade de amigos que irão a algum evento e permitir que o usuário não seja avaliado caso não o deseje, e para se ter uma ideia de como ele seria encarado pela sociedade fora da Escola Politécnica da UFRJ. Um grande desafio de se trabalhar com dados de uma rede social enorme como o Facebook é a alta escalabilidade que ela possui. Neste sistema, são extraídos todos os 43

55 eventos e seus participantes de todos os usuários e gravados no Banco de Dados local. Com o aumento do número de usuários, a tendência é um crescimento enorme da base de dados rapidamente, necessitando mais espaço em disco, memória, além de tornar as consultas mais lentas. Para solucionar esse problema, existem algumas soluções possíveis, como utilizar NoSQL (os quais têm sido bastante usados em Big Data), que poderia melhorar o desempenho de algumas consultas e ter a opção de horizontalizar a escalabilidade, o que significa adicionar mais nós ao sistema na nuvem. 44

56 Bibliografia [1]Facebook Developers, , (Acesso em 27 Julho 2014). [2]Graph API Explorer, , (Acesso em 27 Julho 2014). [3] IBM developerworks, Introdução ao Desenvolvimento do Android, , (Acesso em 28 Julho 2014). [4]Android Developers, Activity, , (Acesso em 29 Julho 2014). [5]Tutorialspoint, AndroidFragments, , (Acesso em 30 Julho 2014). [6] Eclipse + ADT Plugin, GettheAndroid SDK, , (Acesso em 22 Julho 2014). [7] Facebook, Facebook SDK for Android, 2014, (Acesso em 22Julho 2014). [8]LuluApp, , (Acesso em 23 Julho 2014). 45

57 Apêndice A Especificação de Requisitos 1 - Introdução Descrição O Sistema é baseado no sistema de eventos do Facebook, sendo desenvolvido para plataforma Mobile Android. Todos os dados de eventos serão extraídos dele e gravados em um Servidor na Nuvem, para que novas funcionalidades sejam atribuídas ao que é latente no Facebook. O objetivo é complementar a rede social com avaliações feitas pelos usuários, visando o gerenciamento de seus eventos e, consequentemente, uma facilitação na escolha de qual comparecer Escopo Esse documento apresenta os requisitos do Tiupar. Esse sistema tem o objetivo: Realizar autenticação via Facebook. Extrair dados de todos os eventos que estejam por vir e que o usuário esteja confirmado Visualizar dados de todos os eventos que estejam por vir e que o usuário esteja confirmado. Visualizar dados de todos os eventos que passaram e que o usuário estava confirmado desde o início da utilização do sistema. Permitir visualizar a página no Facebook dos eventos. Inserir no banco os dados de eventos e seus participantes extraídos do Facebook. Permitir que o usuário avalie aspectos de eventos que já passaram e/ou informe o seu não comparecimento. Permitir que o usuário avalie os participantes de eventos que estejam por vir e que o usuário esteja confirmado, sendo eles ordenados de forma aleatória. Permitir visualizar o perfil no Facebook dos participantes. Inserir no banco as avaliações atribuídas para eventos e participantes pelo 46

58 usuário. Permitir troca de opção sexual pelo usuário. 1.3-Detalhamento do Produto O Sistema deve possuir as características apresentadas na Tabela 1. Tabela 1: Características do item patrimonial. Característica Descrição Autenticação Autenticar o usuário via API do Facebook. Exibição de dados e Informar dados e avaliações sobre eventos que estejam por vir e avaliações de que já passaram do usuário. eventos Avaliação de eventos Permitir ao usuário avaliar diferentes aspectos de eventos. Avaliação de Permitir ao usuário avaliar os participantes de eventos que participantes estejam por vir do usuário. Troca de preferência Permitir ao usuário trocar sua preferência sexual, adaptando o sexual sistema a essa opção. Ordenação de Listar eventos por proximidade cronológica. Ascendente para os eventos por data que estejam por vir e descendente para os que já passaram. 2 - Requisitos Requisitos Não-Funcionais Segurança Disponibilidade RNF1: O software deve estar disponível 24hs por dia, 7 dias por semana (24x7). Robustez Tecnológicos RNF2: O software deve utilizar base de dados MySQL em um Servidor na nuvem. Usabilidade Desempenho RNF3: O carregamento de todas as páginas do software não deve demorar mais de 25 segundos Requisitos Funcionais RF1: RF2: O software deve permitir realizar a autenticação do usuário via Facebook. O software deve permitir a requisição de informações referentes aos eventos que 47

59 RF3: RF4: RF5: RF6: RF7: RF8: RF9: RF10: RF11: RF12: RF13: RF14: estejam por vir e que o usuário tenha confirmado presença no Facebook. O sistema deve permitir ao usuário visualizar informações de eventos que estejam por vir. O sistema deve permitir ao usuário avaliar os participantes de eventos que estejam por vir. O sistema deve permitir ao usuário visualizar eventos que já tenham passado e que ele tenha confirmado presença desde que começou a usar o Sistema. O sistema deve permitir ao usuário avaliar eventos que já tenham passado e que ele tenha confirmado presença desde que começou a usar o Sistema. O sistema não deve permitir ao usuário avaliar eventos que já tenham passado, que ele tenha confirmado presença desde que começou a usar o Sistema e já o tenha avaliado anteriormente. O sistema deve permitir troca de preferência sexual e adequar notas de eventos e participantes a serem avaliados para a nova preferência. O sistema deve permitir visualizar o perfil dos participantes no Facebook. O sistema deve permitir visualizar a página dos eventos que estão por vir no Facebook. O sistema deve armazenar as informações de eventos no Banco de Dados. O sistema deve armazenar as notas para cada evento no Banco de Dados. O sistema deve armazenar as notas para cada participante no Banco de Dados. O sistema deve permitir navegar pelas diversas telas disponíveis. 48

60 Apêndice B Casos de Uso 1 Descrição dos Atores Tabela 2: Descrição de atores Nome Usuário Facebook Descrição Indivíduo que interage com o Sistema. Responsável por fornecer dados sobre o usuário e seus eventos para o Sistema. 2 Diagrama de Casos de Uso Figura 1. Diagrama de Casos de Uso 49