construindo um aplicativo android para vídeo sob
Propaganda
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO ESCOLA POLITÉCNICA Construindo um Aplicativo Android para Vídeo SobDemanda com SOA-MC Autor: Orientador: Examinador: Examinador: _________________________________________________ Filipe Hiroshi Tenorio Yamamoto _________________________________________________ Heraldo Luis Silveira de Almeida, D.Sc. _________________________________________________ Aloysio de Castro Pinto Pedroza, Dr. _________________________________________________ Flávio Luis de Mello, D.Sc. Poli Junho de 2016 Data da Defesa: 16 de Junho de 2016 Curso: Engenharia da Computação e Informação (ECI) DRE 105036308 | [email protected] 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 21949-900 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) e do(s) orientador(es). ii Yamamoto, Filipe Hiroshi Tenorio Construindo um Aplicativo Android para Vídeo Sob- Demanda com SOA-MC / Filipe Hiroshi Tenorio Yamamoto. – Rio de Janeiro: UFRJ/POLI, 2016. XI, 62 p.: il.; 29,7cm. Orientador: Heraldo Luis Silveira de Almeida, D.Sc. Projeto (graduação) – UFRJ/POLI, 2016. Referências Bibliográficas: p. 50. 1. Aplicativo Android. 2. Vídeo Sob-Demanda. 3. SOA-MC. I. Almeida, Heraldo Luis. II. Universidade Federal do Rio de Janeiro. III.Construindo um Aplicativo Android para Video Sob-Demanda. iii A Deus, à minha família e aos meus amigos, que nunca desistiram. AGRADECIMENTOS iv Agradeço a Deus por me dar forças para concluir mais uma etapa da minha vida; aos meus pais, pelo carinho e pelo apoio que sempre me deram; aos meus irmãos, pelo apoio incondicional; aos meus mestres pela paciência, atenção e por sua generosidade ao compartilhar conhecimento; ao meus coordenadores, em especial pelo professor José Ferreira de Rezende e professor Jano Moreira de Souza, por terem sido prestativos; in memoriam ao meu orientador Sergio Villas-Boas por acreditar no meu trabalho e por aceitar se aprofundar nele comigo; ao meu orientador Heraldo Almeida, que mesmo diante das dificuldades, assumiu a orientação com muita presteza; aos membros da banca por aceitarem analisar e discutir este trabalho; aos colegas e amigos que fiz durante esses anos de curso. Resumo do Projeto de Graduação apresentado à Escola Politécnica//UFRJ como parte dos requisitos necessários para a obtenção do grau de Engenheiro de Computação e Informação. v CONSTRUINDO UM APLICATIVO ANDROID PARA VÍDEO SOB-DEMANDA COM SOA-MC Filipe Hiroshi Tenorio Yamamoto Junho/2016 Orientador: Heraldo Luis Silveira de Almeida Curso: Engenharia de Computação e Informação Este trabalho apresenta o desenvolvimento de um software visualizador de transmissão de vídeo sob-demanda para o sistema operacional Android. Sendo um sistema operacional para dispositivos móveis e com filosofia open source, o Android possui grande participação no mercado e o aplicativo construído aproveita seu potencial para visualizar conteúdo de multimídia através da Internet. A construção utiliza a linguagem Java e o ambiente de desenvolvimento Eclipse, além de utilizar a arquitetura de software SOA-MC. Palavras-Chave: Android, Vídeo Sob-Demanda, SOA-MC. Abstract of Undergraduate Project presented to POLI//UFRJ as a partial fulfillment of the requirements for the degree of Computer and Information Engineer. vi BUILDING AN ANDROID APP FOR VIDEO ON-DEMAND USING SOA-MC Filipe Hiroshi Tenorio Yamamoto June/2016 Advisors: Heraldo Luis Silveira de Almeida Course: Computer and Information Engineering This paper presents the development of a software with video on-demand streaming viewing capabilities for the Android operating system. As an operating system for mobile devices and open source philosophy, Android has a large market share and the app built uses its potential to allow viewing of multimedia content through the Internet. The app is constructed with Java programming language and Eclipse as the development environment, and uses the SOA-MC software architecture. Keywords: Android, Video On-Demand, SOA-MC. Sumário vii Conteúdo CAPÍTULO 1 CAPÍTULO 2 INTRODUÇÃO .............................................................................................................. 1 TECNOLOGIA UTILIZADA ...................................................................................... 3 2.1 SISTEMA OPERACIONAL ANDROID .................................................................................................. 3 2.1.1 Sobre o Android .................................................................................................................... 3 2.1.2 Arquitetura ........................................................................................................................... 4 2.1.3 Kernel ................................................................................................................................... 5 2.1.4 Bibliotecas ............................................................................................................................ 5 2.1.5 Android Runtime ................................................................................................................... 6 2.1.6 Framework ........................................................................................................................... 6 2.1.7 Aplicações............................................................................................................................. 7 2.1.8 Ciclo de Vida ........................................................................................................................ 7 2.2 AMBIENTE DE DESENVOLVIMENTO ................................................................................................. 9 2.2.1 Software Utilizado ................................................................................................................ 9 2.2.2 Requisitos de Hardware ....................................................................................................... 9 2.2.3 Configuração ...................................................................................................................... 10 2.2.4 Executando um Aplicativo .................................................................................................. 11 2.3 MAXMIND GEOIP ......................................................................................................................... 14 2.3.1 Características Gerais ........................................................................................................ 14 2.3.2 Implementação do GeoLite ................................................................................................. 14 2.4 VÍDEO ........................................................................................................................................... 16 2.4.1 Codec .................................................................................................................................. 16 2.4.2 Container ............................................................................................................................ 16 2.4.3 Moov Atoms ........................................................................................................................ 17 2.5 ARQUITETURA SOA-MC .............................................................................................................. 17 2.5.1 Camadas ............................................................................................................................. 17 2.5.2 Implementação ................................................................................................................... 18 2.5.3 JSON ................................................................................................................................... 18 2.5.4 Vantagens ........................................................................................................................... 19 2.6 BANCO DE DADOS......................................................................................................................... 19 CAPÍTULO 3 O APP PORTACURTAS ............................................................................................ 21 3.1 REQUISITOS .................................................................................................................................. 21 3.2 ARQUITETURA .............................................................................................................................. 22 3.3 SOFTWARE SERVER-SIDE .............................................................................................................. 23 3.3.1 Busca.asp ............................................................................................................................ 23 3.3.2 Cadastro.asp ....................................................................................................................... 26 3.3.3 Comentar.asp...................................................................................................................... 26 3.3.4 Comentarios.asp ................................................................................................................. 27 3.3.5 ConsultaIP.asp ................................................................................................................... 28 3.3.6 Destaque.asp ...................................................................................................................... 28 3.3.7 Filme.asp ............................................................................................................................ 30 3.3.8 FilmeDaSemana.asp ........................................................................................................... 32 3.3.9 GeoIP.asp ........................................................................................................................... 32 3.3.10 GeoIP.dat ....................................................................................................................... 32 3.3.11 GravaSessao.asp ............................................................................................................ 33 3.3.12 JSON.asp ....................................................................................................................... 33 3.3.13 JSON_UTIL.asp ............................................................................................................. 33 3.3.14 Login.asp ....................................................................................................................... 34 3.3.15 Premios.asp ................................................................................................................... 34 3.3.16 Votar.asp........................................................................................................................ 35 3.4 APP ANDROID ............................................................................................................................... 36 3.4.1 AndroidManifest.xml .......................................................................................................... 36 3.4.2 Layouts ............................................................................................................................... 37 3.4.3 Menu ................................................................................................................................... 38 3.4.4 Values ................................................................................................................................. 40 3.4.5 BancoDados.java................................................................................................................ 40 3.4.6 Busca.java .......................................................................................................................... 41 viii 3.4.7 Busca_Item.java ................................................................................................................. 41 3.4.8 Busca_Montador.java......................................................................................................... 41 3.4.9 Cadastro.java ..................................................................................................................... 42 3.4.10 Comentar.java ............................................................................................................... 42 3.4.11 Comentarios.java ........................................................................................................... 43 3.4.12 Config.java..................................................................................................................... 43 3.4.13 Destaques.java ............................................................................................................... 44 3.4.14 Filme.java ...................................................................................................................... 45 3.4.15 Login.java ...................................................................................................................... 45 3.4.16 Player.java ..................................................................................................................... 46 3.4.17 Principal.java ................................................................................................................ 47 3.4.18 Sobre.java ...................................................................................................................... 48 3.5 DEMONSTRAÇÃO .......................................................................................................................... 49 CAPÍTULO 4 CAPÍTULO 5 CONSIDERAÇÕES FINAIS ...................................................................................... 55 REVISÃO BIBLIOGRÁFICA ................................................................................... 56 ix Lista de Figuras Figura 1 - Arquitetura do Android.................................................................................... 4 Figura 2 - Ciclo de Vida de uma Activity ........................................................................ 8 Figura 3 - Android SDK Manager .................................................................................. 10 Figura 4 - Instalando ADT no Eclipse ............................................................................ 11 Figura 5 - Dispositivo AVD ........................................................................................... 11 Figura 6 - Novo projeto Android .................................................................................... 12 Figura 7 - AndroidManifest.xml..................................................................................... 13 Figura 8 - Implementação ASP do GeoIP com API ....................................................... 15 Figura 9 - Exemplo de uso do GeoIP ............................................................................. 16 Figura 10 - Arquitetura SOA-MC .................................................................................. 18 Figura 11 – Diagrama simplificado das tabelas e colunas utilizadas para retornar um Filme ............................................................................................................................... 20 Figura 12 - Cliente/Servidor ........................................................................................... 23 Figura 13 - Diagrama da consulta SQL para Busca.asp ................................................. 25 Figura 14 - Diagrama da consulta SQL para Cadastro.asp............................................. 26 Figura 15 - Diagrama da consulta SQL para Comentarios.asp ...................................... 28 Figura 16 - Diagrama da consulta SQL para Destaques.asp .......................................... 29 Figura 17 - Diagrama da consulta SQL para Filme.asp ................................................. 31 Figura 18 - Diagrama da consulta SQL para FilmeDaSemana.asp ................................ 32 Figura 19 - Diagrama da consulta SQL para Login.asp ................................................. 34 Figura 20 - Diagrama da consulta SQL para Premios.asp.............................................. 35 Figura 21 - AndroidManifest.xml do Portacurtas........................................................... 37 Figura 22 - Menu no Android ......................................................................................... 39 Figura 23 – Values .......................................................................................................... 40 Figura 24 - Splash Screen ............................................................................................... 49 Figura 25 - Destaques com análise do IP ....................................................................... 49 Figura 26 - Destaques da Semana .................................................................................. 50 Figura 27 - Busca............................................................................................................ 50 Figura 28 - Resultados de Busca .................................................................................... 51 Figura 29 - Ficha do Filme ............................................................................................. 51 Figura 30 - Comentarios do Filme.................................................................................. 52 Figura 31 - Login ............................................................................................................ 52 Figura 32 - Usuário registrando comentário ................................................................... 53 Figura 33 - Usuário registrando voto.............................................................................. 53 Figura 34 - Configurações .............................................................................................. 54 Figura 35 - Exibição do vídeo ........................................................................................ 54 SIGLAS API – Application Programming Interface SDK – Software Development Kit UI – User Interface IDE – Integrated Development Environment UFRJ – Universidade Federal do Rio de Janeiro ADT – Android Development Tools IP – Internet Protocol ii Capítulo 1 Introdução Desde 2005, com a popularização do compartilhamento de vídeos na Internet com o advento do YouTube, o conceito de Video Sob-Demanda (em inglês, Video On- Demand) tem se tornado mais comum e mais acessível à população em geral. O próprio serviço de estatística deste website informa que 100 horas de vídeos são enviadas a cada minuto. No entanto, antes mesmo que o YouTube despontasse no cenário mundial, a Synapse, uma distribuidora de vídeos especializada em acervo de curta-metragem brasileiro, já mantinha no ar um projeto de distribuição e transmissão de vídeo pela Internet em 2002. Esse projeto foi chamado de Porta Curtas. Apesar da banalidade com que se trata a visualização de vídeos hoje, esse projeto esteve na vanguarda do desenvolvimento de Video Sob-Demanda no Brasil e contava com uma parceria com a Locaweb que fornecia a infraestrutura necessária para a hospedagem e transmissão dos arquivos Windows Media Video da época. Com a evolução da velocidade de conexão à Internet e com a adoção de novas tecnologias de compressão e visualização de vídeo, houve a necessidade de evoluir também o software que rodava por trás do sistema do Porta Curtas. Desta forma, a base do software migrou para o uso do Adobe Flash Player, cuja estimativa de penetração nos computadores dos usuários chegou a ser de 99% em Dezembro de 2008. Se a popularização da visualização de vídeos na Internet foi devido ao YouTube, podemos dizer que o dispositivo de telefonia celular iPhone também teve grande parcela de contribuição para a popularização de aparelhos smartphone. Temos hoje diversos modelos de dispositivos móveis, entre celulares, tablets e e-books, e também temos alguns sistemas operacionais para tais dispositivos bem posicionados no mercado: iPhone OS (iOS), Blackberry, Windows Phone e Android. Em termos de comportamento, há uma grande tendência de que as pessoas passem a usar menos tempo com TV e computadores, favorecendo o uso de mais horas em dispositivos móveis. Portanto, havia o questionamento sobre qual sistema operacional deveria ser utilizado para o aplicativo móvel de video sob-demanda. Em 2011, a empresa 1 de consultoria Gartner já indicava que o Android já dominava o mercado com 52,5% de Market Share, contra os 16,9% do Symbian e 15% do iOS. A escolha por desenvolver para Android foi fácil depois dessa análise. Ainda podemos considerar que o desenvolvimento do sistema operacional é da Google, uma das maiores empresas de tecnologia da atualidade, que fornece diversos produtos, serviços e ferramentas relevantes para o usuário comum ou para o desenvolvedor. O Android é gratuito, com filosofia de código aberto e baseado em Linux. O desenvolvimento é facilitado pelo SDK fornecido pela empresa para a construção de aplicativos, usando linguagem de programação Java e plugin para os IDEs mais conhecidos do mercado, incluindo o Eclipse. Como cada celular porta uma versão diferente do Android, também era interessante analisar qual era a versão mais utilizada para maximizar a compatibilidade e aumentar o número de usuários do aplicativo. Celulares com as versões Froyo (2.2) e Gingerbread (2.3.X) dominavam o mercado com 85,9% de Market Share. Versões mais novas ainda não possuiam muita adesão. Tendo elucidado a versão-alvo para com que seria desenvolvido, restava apenas duas definições. A primeira diz respeito ao formato de vídeo, para que a transmissão de vídeo pudesse estar ao nível de visualização no celular, considerando tamanho de tela, resolução, bitrate, velocidade média de conexão à Internet no Brasil e tamanho do aplicativo em si. Foi utilizado vídeos codificados em H.264/MPEG4-Part10 para diminuir o tamanho dos arquivos dos vídeos, sem perder qualidade sensível. A segunda definição a ser feita era sobre o controle do conteúdo multimídia com licenciamento regional por endereço IP. Para isso, foi considerada a solução caixa-preta já utilizada no website Porta Curtas: GeoIP do MaxMind, que é um serviço de geolocalização através do endereço IP. Como este aplicativo Android tem características acadêmicas, foi selecionada a versão gratuita do GeoIP, que é mais leve, possui banco de dados menor, menos características e API mais simplificada e limitada. O aplicativo Android tem como objetivo disponibilizar um subconjunto funcionalidades básicas do Porta Curtas, tais como: navegar pelo acervo disponível, buscar conteúdo, visualizar vídeos e ficha técnica limitada do filme, fazer login no sistema, comentar como usuário registrado, avaliar filme e restringir acesso apenas a endereços IP brasileiros. 2 Capítulo 2 Tecnologia Utilizada 2.1 Sistema Operacional Android Algumas características do sistema operacional Android serão apresentadas a seguir. Elas compreendem o básico para que se possa entender o desenvolvimento do aplicativo Porta Curtas. Além disso, será abordada as configurações feitas no ambiente de desenvolvimento para que se possa rodar o aplicativo no próprio computador através do emulador ou mesmo num dispositivo móvel, externo ao ambiente de desenvolvimento. 2.1.1 Sobre o Android O Android é um sistema operacional desenvolvido primariamente para aparelhos de telefonia celular com funcionalidade touchscreen, mas hoje abrange também outros dispositivos móveis como é o caso dos tablets. Ele se baseia em Linux e nasceu com o objetivo de atender padrões abertos para a indústria de telecomunicações. O Google inicialmente financiava o projeto Android e em 2005 comprou o projeto, passando a ser responsável diretamente pelo desenvolvimento do sistema. Como foi falado anteriormente, o Android atende a filosofia de código aberto e permite que outros desenvolvedores modifiquem e distribuam livremente o software. Justamente por ser aberto e de acesso facilitado, há uma grande comunidade de desenvolvedores que constroem e publicam diversas aplicações, comumente chamadas de Apps. Tais softwares são programados em linguagem Java e, em 2013, já são quase 1 milhão de aplicativos disponíveis no mercado oficial do Google, o Google Play. Com a colaboração da comunidade, tanto no desenvolvimento do sistema, quanto no desenvolvimento dos apps, o Android desbancou facilmente os outros sistemas operacionais que dominavam o mercado anteriormente: Symbian e iOS. 3 2.1.2 Arquitetura O Android foi construido numa arquitetura em camadas da seguinte maneira: Kernel Linux. É a base do sistema, incluindo drivers de hardware, rede, Bibliotecas. Programas que rodam em background (daemons) e serviços, sistema de acesso a arquivos e comunicações entre processos. escritos em C ou C++. Framework de Serviços. Programas em Java que executam num Virtual Machine, que auxiliam o desenvolvimento de software provendo funcionalidades ou controles específicos. Aplicações. Programas em Java que executam no Dalvik Virtual Machine, e constituem as aplicações utilizadas pelo usuário final. Figura 1 - Arquitetura do Android 4 2.1.3 Kernel O Kernel, software que gerencia a comunicação do hardware com as outras camadas de software, utilizado pelo Android é o do Linux. No caso da versão-alvo em que estamos desenvolvendo, é utilizado o Kernel do Linux de versão 2.6. Basicamente, controlam o uso do Audio, Conectividade (WiFi, Bluetooth, redes móveis 3G), dispositivos USB, tela, camera, gerência de energia, gerência de memória RAM, controles de entrada (teclado, mouse), gerência de processos, entre outros. 2.1.4 Bibliotecas O Android possui coleções de implementações que atendem um determinado comportamento. Essas bibliotecas foram escritas em linguagem C/C++ e são utilizadas por várias partes do sistema, além de estarem disponíveis através dos frameworks. As principais bibliotecas são: libc. Biblioteca C padrão do sistema para Linux, customizado para não ter WebKit. Biblioteca de código aberto que renderiza páginas Web com problemas de licença, e para ser pequeno e rápido. suporte a CSS, Javascript, DOM, AJAX, fullscreen, e visualização adaptativa. Media Framework. Biblioteca baseada na plataforma PacketVideo OpenCORE, que suporta vários formatos de vídeo, audio, imagem, e codecs de hardware e de software, incluindo reprodução, transmissão, download e reprodução progressiva de containers 3GPP, MPEG-4, AAC e MP3. Além disso, suporta encoders e decoders de vídeo e imagem, que incluem: MPEG-4, H.263, AVC (H.264) e JPEG. Isto é relevante para o que será abordado posteriormente. SQLite. Biblioteca que serve de armazenamento leve de dados transacionais. Basicamente, um sistema de gerência de banco de dados relacionais. Surface Manager. Biblioteca que ajuda a compor “superfícies”, gerenciando toda renderização de superfícies 2D e 3D, de todas as 5 aplicações. Tais composições podem utilizar aceleração por hardware 2D e OpenGL ES. Audio Manager. Biblioteca que gerencia a rota de cada saída de áudio para cada dispositivo, além de processar múltiplos fluxos de áudio. SGL. Biblioteca construída em cima da OpenGL para implementar funcionalidades de gráficos 3D. FreeType. Biblioteca que ajuda a renderizar fontes e bitmaps. 2.1.5 Android Runtime O Android possui uma implementação de Virtual Machine chamada Dalvik. Isso permite rodar qualquer aplicativo Android independentemente do dispositivo, seja celular ou tablet. Por outro lado, o uso de uma Virtual Machine significa que a performance não será tão rápida quanto num aplicativo completamente compilado. Com isso, o código é interpretado e traduzido para uma representação intermediária, para então ser executado. Com a necessidade de melhorar a performance, o Android implementa, a partir da versão 2.2, o Dalvik com a compilação just-in-time (JIT), fazendo com que o programa fique armazenado na memória em bytecode, mas com um segmento do código que está rodando compilado na máquina física para rodar mais rápido. Os apps são escritos em Java e compilados em Bytecode. Depois é convertido de arquivo .class para um arquivo .dex compatível com o Dalvik. Esse arquivo .dex é chamado de Dalvik Executable e foi criado levando em conta restrições de memória e velocidade de processamento. Além disso, o Dalvik permite instanciação múltipla, ou seja, cada aplicativo pode rodar numa instância própria da Dalvik Virtual Machine, melhorando a eficiência. Deste modo, a execução do app fica otimizada. 2.1.6 Framework Há ainda alguns serviços essenciais para a plataforma Android que são disponibilizados na camada Application Framework. Nele existem abstrações que proveem funcionalidades específicas para o desenvolvedor e que permitem uma melhor reusabilidade de software. 6 Alguns itens relevantes desta camada são: Activity Manager. Gerencia as atividades, que compõe com que o usuário pode interagir, o que significa que acaba gerenciando o ciclo de vida da aplicação. Resource Manager. Gerencia recursos do aplicativo, tais como textos e objetos multimídia. Notification Manager. Gerencia a visualização de notificações na barra de status do dispositivo. View System. Provê vários objetos de UI que podem ser criados e utilizados. 2.1.7 Aplicações A camada de aplicações é onde entra a aplicação feita pelo desenvolvidor para Android. Aqui os apps são escritos em Java, utilizando o SDK do Google, e fazendo uso dos frameworks, bibliotecas e APIs disponibilizadas para o desenvolvimento. O próprio sistema Android já possui algumas aplicações por padrão: Home (app inicial), Contatos, Fone, Navegador, entre outros. 2.1.8 Ciclo de Vida O ciclo de vida de uma aplicação Android passa pelo entendimento de pelo menos dois dos componentes básicos com que se constrói o projeto: Activity e Intent. Activity representa uma tela de interface de usuário. Dentro deste projeto, por exemplo, uma Activity é a tela com informações de um filme. Cada uma dessas activities são únicas, servem um objetivo e representam uma parte da aplicação Android. Intent é uma mensagem assíncrona que ativa uma Activity, podendo até mesmo conectar a componentes de outros aplicativos Android. Assim como a palavra sugere, um Intent representa uma intenção de ação, podendo “ver” ou “enviar” alguma coisa. Em outras palavras, o Intent é o que permite navegar entre Activities diferentes. Quando há uma Intent de chamar uma Activity, o método onCreate() é chamado. Neste momento em que a Activity é criada, alguns objetos estáticos são definidos: views são criados, dados são conectados, etc. Ao final, é seguido de onStart(). 7 Caso a Activity estivesse parada, o método onRestart() é chamado antes de ser seguido por onStart(). No método onStart(), a Activity começa a ser visível ao usuário. Caso a Activity esteja entrando em primeiro plano, o método a seguir é o onResume(). Caso contrário, se estiver sendo escondida, o próximo método a ser chamado é o onStop(). Chegando em onResume(), a atividade começa a ficar disponível para interação com o usuário e fica no topo da pilha de atividades. Caso outra atividade se torne mais prioritária na pilha de atividades ou a atividade atual fique escondida, o próximo método a ser chamado é o onPause(). Em onPause(), a atividade é pausada para que utilize menos recursos disponíveis até que seja retomada com o onResume() ou tornando invisível ao usuário com onStop(). Caso onStop() seja chamado, então outra atividade pode ter sido chamada ou esta chamada está em processo de destruição. Caso esta atividade ainda volte a ser iniciada, é seguido pelo método onRestart(). Se a atividade está sendo destruída, é chamado onDestroy(). Ao chamar o método onDestroy, o sistema finaliza a atividade. Segue abaixo o diagrama do ciclo de vida de uma Activity: Figura 2 - Ciclo de Vida de uma Activity 8 As Activities e os Intents geralmente são registradas num arquivo do projeto chamado AndroidManifest.xml. Este recurso que serve para detalhar diversas configurações do projeto será detalhado mais à frente. 2.2 Ambiente de Desenvolvimento 2.2.1 Software Utilizado Para desenvolver um aplicativo Android foi utilizado um ambiente de desenvolvimento integrado (IDE) com capacidade de desenvolvimento Java, além do kit de desenvolvimento de software (SDK) oficial do Android para o IDE escolhido. Para este projeto, utilizamos o Eclipse como IDE. Apesar de, ao longo do tempo, várias versões do Eclipse terem sido utilizadas, vamos comentar a configuração do ambiente com o Eclipse Standard 4.4 para Windows 32-bit lançado em 25 de Junho de 2014, com suporte ao Java 7 JRE/JDK. Para desenvolver o aplicativo do servidor, foi utilizado o software Notepad++ em versão 6.6.9 para o desenvolvimento em ASP e VBScript. E para manipulação da base de dados SQL Server 2008 R2 foi utilizado o software Toad for SQL Server em versão 6.1.0. Utilizamos a versão gratuita do serviço de geolocalização por endereço IP da empresa MaxMind, o qual descreveremos mais à frente. 2.2.2 Requisitos de Hardware Todos os softwares descritos acima são de versão gratuitas e não possuem requerimentos específicos de hardware. O computador utilizado para o desenvolvimento dos aplicativos tem a seguinte configuração: Processador: Intel Core i5 2500k @ 4500MHz SSD: Crucial M500 512GB Memória RAM: Kingston DDR3 16GB 1600MHz Sistema Operacional: Windows 7 Ultimate x64 O servidor Windows Server é um recurso contratado à Locaweb e possui configurações desconhecidas neste momento. 9 2.2.3 Configuração Antes de começar a usar o Eclipse, é necessário instalar o Android SDK e, usando o Android SDK Manager, selecionar os pacotes referentes às versões do sistema operacional Android. Figura 3 - Android SDK Manager Tendo instalado os pacotes, é necessário instalar um plugin ao Eclipse chamado Android Development Tools (ADT). Há de se notar que já é possível baixar e instalar uma versão em que o Android SDK já venha com o ADT integrado ao Eclipse, mas descreveremos o processo de instalação do plugin à parte. Abrindo o Eclipse e selecionando “Help > Install New Software”, adicionamos o local de onde o plugin será obtido, conforme a imagem abaixo: 10 Figura 4 - Instalando ADT no Eclipse Antes de começar um novo projeto é necessário ainda criar um dispositivo virtual onde o aplicativo será emulado. Dentro do Eclipse, em “Window > Android Virtual Device Manager”, cria-se um dispositivo especificando atributos de hardware e versãoalvo do sistema operacional Android. Figura 5 - Dispositivo AVD 2.2.4 Executando um Aplicativo Um novo projeto de aplicativo Android é criado da seguinte maneira no Eclipse: “File > New > Other > Android > Android Application Project”. O projeto precisa especificar o nome da aplicação, o nome do projeto, o nome do pacote, as versões-alvo do sistema operacional Android às quais o projeto se destina e opções de compilação. 11 Figura 6 - Novo projeto Android Com o projeto criado, algumas pastas e arquivos foram adicionadas para que se possa rodar e exportar o arquivo APK, que é o arquivo final da aplicação. As pastas fazem parte do projeto são: src: onde ficam todos os arquivos-fonte .java do projeto, agrupados em gen: onde o código é gerado para todos os recursos definidos no diretório pacotes que ajudam a categorizar o código de forma lógica. “res”. Android 2.3.3 e outros diretórios Android: possuem todas as classes necessárias para a aplicação do projeto rodar na versão-alvo selecionada. assets: onde se armazena outros tipos de arquivos que precisam ser acessados pelo aplicativo. bin: onde o compilador coloca arquivos gerados a partir do código-fonte, contendo os arquivos .class e o arquivo final .apk. libs: onde outras bibliotecas são armazenadas res: onde a maioria dos recursos da aplicação é armazenada, e é organizada em categorias diferentes: o anim: para arquivos XML que são compilados em objetos de animação 12 o color: para arquivos XML que descrevem cores o drawable: para arquivos bitmap (PNG, JPEG ou GIF), arquivos de imagem e arquivos XML que descrevem formas desenháveis ou objetos que contem múltiplos estados (normal, pressionado, focado). o layout: para arquivos XML que são compilados em layouts de tela o menu: para arquivos XML que definem menus da aplicação o raw: para outros tipos de recursos, similarmente ao “assets” o values: para arquivos XML que são compilados em outros tipos de recursos o xml: para outros arquivos XML que a aplicação precisa acessar Há ainda o arquivo AndroidManifest.xml que provê metadados da aplicação do projeto que o sistema operacional Android vai precisar para a execução. Nesse arquivo há o nome da aplicação, o ícone da aplicação, as Activities da aplicação, as permissões que a aplicação necessita, informações sobre versão-alvo, suporte às telas diferentes, entre outras opções de configuração. Figura 7 - AndroidManifest.xml Com o projeto pronto para execução, basta selecionar “Run > Run” e selecionar o dispositivo AVD criado anteriormente para ver o aplicativo no emulador. 13 2.3 MaxMind GeoIP Uma tarefa importante quando abordamos a distribuição de conteúdo é a restrição geográfica. Para cada país ou região, a Synapse pode determinar qual empresa explorará uma modalidade de distribuição específica para um subconjunto de conteúdo. Por isso, é importante ressaltar que esta implementação no Android também deve possuir um controle sobre onde é possível visualizar os vídeos. Há outras empresas consolidadas no mercado que já fazem essa restrição: Hulu e YouTube. Em alguns casos, são episódios de seriados que são liberados para visualização nos Estados Unidos, mas não são liberados para outros países. A seguir descreveremos como esse controle é implementado. 2.3.1 Características Gerais Um A Synapse usa para o projeto Porta Curtas a solução de geolocalização através do IP com o serviço GeoIP da empresa MaxMind. Há várias categorias, entre localização mais precisas como cidades e até bairros, ou apenas países. O ciclo de atualização do banco de dados de IPs é mensal, e há a possibilidade de contratar a versão off-line, em que se recebe os arquivos em formato .dat ou CSV, ou a versão online, em que você consome um webservice fornecidos por eles. O MaxMind também disponibiliza algumas APIs gratuitas, para algumas linguagens, enquanto a própria comunidade possui algumas APIs não-oficiais para suportar outras linguagens. 2.3.2 Implementação do GeoLite Enquanto a Synapse comprou essa solução paga, há também a versão gratuita chamada GeoLite, que conta com um banco de dados limitado, menos atualizado e com APIs diferentes. Esta será a versão utilizada na implementação Android por ser mais leve, mais fácil de implementar e por se tratar de um trabalho acadêmico, e não comercial. A instalação ocorre da seguinte maneira: No site do MaxMind, baixa-se o arquivo de banco de dados GeoLite para países e a API para a linguagem em questão 14 Faz-se o deploy dos arquivos no servidor, configurando apenas o caminho Faz-se a consulta utilizando a API. do arquivo de GeoIP.dat. o Neste caso fizemos o uso de oGeoIP.lookupCountryName(IP) para recuperar o nome do país o E o uso de oGeoIP.lookupCountryCode(IP) para recuperar o código do país. Com a definição do caminho do arquivo e os devidos tratamentos de erro, fazemos, nesta implementação, retornar com um objeto JSON, uma vez que trataremos todos os webservices com JSON no Android. O resultado final da implementação em ASP do GeoIP fica assim: Figura 8 - Implementação ASP do GeoIP com API O software é considerado caixa-preta, mas o funcionamento com a API é simples: precisamos fornecer um endereço IP utilizando a interface fornecida, e o serviço nos devolve o código do país. E com esse código do país, podemos filtrar o conteúdo por país no Android. Por exemplo: 15 Figura 9 - Exemplo de uso do GeoIP Para esta implementação Android, colocamos a funcionalidade de restrição por IP através de um webservice fornecido pela nossa aplicação server-side. Dessa forma, permitimos que o aplicativo fique consideravelmente mais leve, pois o tamanho dos arquivos necessários para fazer a consulta GeoIP facilmente extrapolaria algumas unidades de megabyte na versão gratuita GeoLite ou até mesmo centenas de megabytes na versão paga. Desta forma, também otimizamos a performance do aplicativo Android, ao transferir esse trabalho da consulta para o servidor executar. 2.4 Vídeo Desde 2011 na Synapse, alguns filmes são convertidos para formatos mais atuais de distribuição para Internet e aplica-se uma compressão para deixar os arquivos pequenos, mas sem perder qualidade de imagem. A troca de arquivos de vídeo WMV para um formato mais recente foi devido ao surgimento do iPhone como um mercado a ser atingido. 2.4.1 Codec Um dos formatos de codec utilizados na nova solução foi o H.264 (também chamado de MPEG-4 Part 10). Esse padrão de software para codificar e decodificar fluxo de dados de vídeo é um dos mais utilizados pela indústria no momento, incluindo o uso em discos Blu-Ray, e serviços de transmissão de vídeo como o YouTube, Vímeo e iTunes. 2.4.2 Container O container utilizado é o MPEG-4 Part 14, conhecido como um arquivo de extensão .mp4. Apesar de ser um padrão desenvolvido pela International Organization 16 for Standardization (ISO), a Apple sempre incluiu grande suporte a este container desde as primeiras versões do seu visualizador multimídia Quicktime. Da mesma forma, os dispositivos criados pela Apple também possuía suporte aos arquivos .mp4 e isso foi determinante para que a Synapse acolhesse esse formato de metarquivo como a solução para o mercado de dispositivos móveis. 2.4.3 Moov Atoms Uma característica importante da transmissão de vídeo com o H.264 é a capacidade de adicionar o índice de frames que precede cada átomo de dados do filme, no início do arquivo. Esses metadados (duração, framerate, escala de tempo, entre outros...) são codificados no filme e são chamados de moov atoms. Quando se codifica o vídeo com o H.264, é possível colocar isso no início do arquivo, permitindo a transmissão progressiva do vídeo. Em outras palavras, significa que o usuário não precisa esperar o download do vídeo terminar para poder começar a assisti-lo. Além disso, isso permite que o protocolo HTTP seja utilizado normalmente, em detrimento de soluções mais específicas e mais caras, como o aluguel de servidores de mídia, que utilizam software proprietário (em sua maioria), como por exemplo o Adobe Media Server. Nem mesmo é necessário o uso de outros protocolos, como o RTMP, o que poderia criar uma dificuldade de implementação no Android. 2.5 Arquitetura SOA-MC A arquitetura SOA-MC significa Service Oriented Architecture – Multiple Client. O propósito é oferecer a aplicação como serviço, disponibilizando uma interface pela Internet, acessível por webservices. No caso do SOA-MC, lidamos com duas camadas que são interligadas pelo protocolo HTTP e utilizamos dados do tipo XML, JSON ou CSV. 2.5.1 Camadas A primeira camada é a que provê o serviço, desempenhando o papel de servidor, implementando as regras de negócio e disponibilizando como webservices. 17 A segunda camada compreende os clientes que irão consumir o serviço disponibilizado. Esses clientes podem ser de plataformas diferentes e por isso recebem a designação de Múltiplos Clientes. Figura 10 - Arquitetura SOA-MC 2.5.2 Implementação Nesta implementação, fica claro que o aplicativo Android rodando num aparelho celular é um dos clientes. Poderíamos utilizar o mesmo serviço para um cliente web, ou até mesmo outra plataforma móvel. No servidor, teremos uma aplicação ASP que fornecerá serviços básicos consultas ao banco de dados, inserção de comentários, entre outras ações, utilizando mensagens JSON. A escolha pela tecnologia ASP se deve ao fato da empresa Synapse possuir sistemas legados em ASP aos quais serão integrados, o que torna a escolha natural para a solução. 2.5.3 JSON 18 A JSON (JavaScript Object Notation) é um padrão aberto para troca de dados. Apesar de ter herdado do Javascript a forma de representar estruturas de dados, é independente de qualquer linguagem, ou seja, qualquer linguagem de programação poderá ler ou escrever neste formato. É um formato muito utilizado para serializar e transmitir dados estruturados pela rede e é alternativo ao XML, que geralmente é mais pesado. Um exemplo de objeto JSON de resposta para a consulta de um filme: [{"Ds_Filme_Titulo":"Ess\u00EAncia","Nm_Arquivo_Foto":"essencia- E.jpg","Ds_Sinopse":"Na busca por \u00E1gua em um mundo seco, um sobrevivente encontra sua ess\u00EAncia.","Genero":"Anima\u00E7\u00E3o","Diretor":"Daniel Raban\u00E9a","Ds_Bitola":"indispon\u00EDvel","Pais":"Brasil","LocalProducao":"Indefinido ","Nr_Duracao":3,"Nr_Ano_Lancamento":2011,"NumComentarios":2,"NumPremios":2,"Nm_ Arquivo_Video":"http:\/\/www.videosrelevantes.com.br\/mp4\/essencia.mp4","Nr_Voto":null," Qt_Voto":null}] 2.5.4 Vantagens Uma grande vantagem de usar o SOA-MC é ter a necessidade de escrever as regras apenas uma vez e fazer a manutenção em apenas um lugar. Além disso, há a separação entre a lógica e a apresentação, o que pode significar um investimento menor ou melhor controlado, uma vez que haverá a equipe que desenvolve a lógica de negócios e outras equipes desenvolvendo os clientes apropriados. Dessa forma, desenvolve-se os clientes de acordo com a necessidade ou capacidade de desenvolvimento da época. 2.6 Banco de Dados O banco de dados que a Synapse utiliza para todos os projetos, incluindo o do Porta Curtas, é o SQL Server 2008 R2 que possui uma compatibilidade natural com os sitemas ASP/VBScript e ASP.Net/C# mantidos pela a empresa. As bases de dados de cada projeto costumam ter mais de 300 tabelas e milhões de registros, e por esse motivo apenas algumas tabelas mais relevantes serão apresentadas neste documento. Nesta seção, no entanto, mostraremos apenas um exemplo e no próximo capítulo, mais detalhes sobre as tabelas e as consultas. Exemplo: 19 Figura 11 – Diagrama simplificado das tabelas e colunas utilizadas para retornar um Filme 20 Capítulo 3 O app PortaCurtas 3.1 Requisitos Para que o aplicativo seja corretamente construído e para que atenda a necessidade inicial da empresa Synapse, é importante que se identifique os requisitos. Muitas vezes não é possível imaginar os desafios de implementação ao conversar com o cliente. Tendo isto em mente, podemos ver, por exemplo, que o aplicativo do lado do servidor nunca seria imaginado num primeiro momento ao ler os requisitos a seguir. O aplicativo Android deve ter uma tela de splash pra mostrar a marca do O aplicativo Android deve mostrar os mesmos destaques que a versão projeto Portacurtas e do Patrocinador web, quando fizer menção à filmes – exclui canais e outras páginas terceiras O aplicativo Android deve permitir a busca por filmes, usando título do filme O aplicativo Android deve permitir a visualização das informações básicas do filme, incluindo um diretor, um artista do elenco (quando houver), gênero, duração e ano de lançamento. O aplicativo Android deve permitir a visualização do arquivo de vídeo (quando houver) O aplicativo Android deve registrar a visualição do arquivo de vídeo por usuário não-logado ou logado O aplicativo Android deve ser capaz de fazer o login do usuário O aplicativo Android deve usar mesmo esquema de cores que o tema utilizado na versão web O aplicativo Android deve permitir que o usuário leia e faça comentários sobre os filmes O aplicativo Android deve permitir que o usuário vote num filme, atribuindo nota de 0 a 5. 21 3.2 O aplicativo Android deve fazer a verificação geográfica do endereço IP e impedir a visualização do arquivo de vídeo quando o país for diferente de “Brasil” O aplicativo Android deve ser menor que 1MB em tamanho de arquivo O aplicativo deve utilizar a estrutura e outros recursos já contratados pela a empresa Synapse, incluindo servidores, bancos de dados, imagens, vídeos e outros serviços contratados. O aplicativo deve ser construído mantendo a arquitetura já utilizada nos projetos ASP existentes, quando for possível. Arquitetura A Synapse sempre manteve projetos web desde 2001, trabalhando com ASP e outras linguagens procedurais. Isso levou a adoção de uma arquitetura modular, onde cada componente contém tudo que é necessário para executar e cobrir uma funcionalidade. A separação de conceitos foi uma preocupação que levou à modelagem de componentes distintos: Filme, Comentario, Voto, Destaque, entre outros. Preocupada com a manutenabilidade do código com uma equipe in-house de T.I. reduzida, a arquitetura do app do Portacurtas se assemelha ao do projeto web pré-existente. Além disso, com a limitação da conexão nativa ao banco de dados por parte do sistema operacional Android, foi necessário modelar um sistema Cliente-Servidor, em que uma aplicação ASP pudesse desempenhar a aquisição de dados junto ao banco de dados, fornecendo à aplicação Android um webservice em JSON. O fato de não existir um suporte para Android e existir para ASP, e pelo requisito de deixar o aplicativo Android leve, também foi implementado no servidor a resolução do endereço IP para código de país. 22 Figura 12 - Cliente/Servidor 3.3 Software Server-Side A aplicação implementada no servidor serve principalmente a dois propósitos: 1. Fazer a comunicação entre a aplicação Android e o banco de dados SQL Server, provendo um Webservice com output em JSON para que seja consumido pela aplicativo móvel. 2. Resolução e Processamento do endereço IP em países válidos com o GeoLite. Cada arquivo .ASP atinge uma das duas propostas acima e o deploy dessa aplicação é feita no servidor Windows na qual reside outras aplicações ASP e ASP.NET da empresa Synapse. Isso inclui a configuração do Internet Information Services (IIS) e o uso do Global.asa para determinar o local onde se executa tal aplicativo no servidor, cujas configurações são mantidas fechadas pela empresa de hospedagem Locaweb e não fazem parte do escopo deste trabalho. Segue abaixo a descrição de cada componente da aplicação ASP. 3.3.1 Busca.asp Este arquivo serve para buscar filmes que contenham no título do filme os termos especificados pelo o usuário. 23 Inicialmente, verifica se não há uma tentativa de SQL Injection antes de prosseguir. Tendo validado a string “strBuscar” via querystring, ele inclui a biblioteca para exportação em JSON no ASP, e faz a conexão ao banco de dados SQL Server. Ao prosseguir, remove preposições, remove espaços no início no fim da string. Caso a string não seja vazia, ela itera o contador de estatísticas de busca, e para cada palavra dentro da string, é verificado no banco se há uma incidência de um filme ativo que contenha aquela palavra no título do filme. Existindo um ou mais registros de filmes com as palavras da string, é retornado em formato JSON as 20 primeiras ocorrências com os dados: Id do Filme Arquivo da Foto do Filme Titulo do Filme Duração do Filme em minutos Ano de Lançamento do Filme Gênero do Filme Diretor do Filme (apenas o primeiro) Artista do Filme (apenas o primeiro) Sinopse do Filme, em português 24 Figura 13 - Diagrama da consulta SQL para Busca.asp 25 3.3.2 Cadastro.asp Este arquivo serve para cadastrar novos usuários de perfil “Usuário” no sistema do Portacurtas. Inicialmente, verifica se não há uma tentativa de SQL Injection antes de prosseguir. Tendo validado as strings “username”, “email” e “password” via querystring, ele inclui a biblioteca para exportação em JSON no ASP, e faz a conexão ao banco de dados SQL Server. Ao prosseguir, remove aspas das strings e transforma tudo em lowercase. Caso as três strings não sejam vazias, verifica-se se o email a ser cadastrado já está cadastrado no banco de dados na tabela Usuario. Se for este o caso, ele retorna em JSON a mensagem “EmailExistente”, indicando que o cadastro não foi realizado por já existir um outro cadastro com o mesmo email. Caso contrário, ele insere o novo usuário com o nome de usuário, email e senha que o usuário digitou, registrando a data do processamento deste cadastro e ativando o usuário com o perfil comum (“Usuario”). Conseguindo cadastrar o usuário no banco de dados, o arquivo retorna em JSON o status “OK”, indicando o sucesso da operação. Caso contrário, ele retorna em JSON o status “FALHA”, indicando a falha da operação de cadastro do usuário. Figura 14 - Diagrama da consulta SQL para Cadastro.asp 3.3.3 Comentar.asp Este arquivo serve para um usuário registrado e logado conseguir cadastrar um comentário sobre um determinado filme. 26 Inicialmente, verifica se não há uma tentativa de SQL Injection antes de prosseguir. Tendo validado a string “comentario”, e os inteiros “idUsuario” e “idFilme” via querystring, ele inclui a biblioteca para exportação em JSON no ASP, e faz a conexão ao banco de dados SQL Server. Ao prosseguir, remove aspas do comentário para evitar que a consulta SQL se quebre. Caso as três variáveis não sejam nulas ou vazias, verifica-se se os Ids do Filme e do Usuario são válidos, ou seja, se existe no banco de dados um filme com o ID Informado e se existe um Usuario com o ID informado. Se ambos forem válidos, ele retorna em JSON a mensagem “OK”, indicando que o comentário foi registrado. Caso contrário, ele retorna em JSON o status “FALHA”, indicando a falha da operação de cadastro do comentário de um usuário a um filme. 3.3.4 Comentarios.asp Este arquivo serve para obter os últimos vinte comentários de todos os usuários acerca de um determinado filme. Como apenas uma variável integer “ID” é passada via querysting, só é necessário verificar se a variável é de fato um número inteiro. Sendo este o caso, faz-se a conexão ao banco de dados e carrega os últimos 20 comentários liberados do filme de mesma ID. Tendo carregado com sucesso, o arquivo retorna em JSON: Nome do Usuário que fez o comentário Data que o Comentário foi feito Texto do Comentário do Usuário 27 Figura 15 - Diagrama da consulta SQL para Comentarios.asp 3.3.5 ConsultaIP.asp Este arquivo serve para resolver um endereço IP para um código de país, usando a biblioteca do GeoIP. Inicialmente, inclui a biblioteca gratuita do GeoIP e indica o local de rede, no servidor, onde se encontra o arquivo de dados caixa-preta “GeoIP.dat”. Caso o serviço do GeoIP não consiga abrir o arquivo informado, ele informa um erro. Caso contrário, o arquivo passa o endereço IP advindo da variável “IP” passada via querystring. No fim, exporta em JSON o código do país para o IP fornecido. 3.3.6 Destaque.asp Curtas. Este arquivo serve para obter os quatro últimos destaques da Home Page do Porta Não há nenhum input para este arquivo. Faz-se a conexão ao banco de dados e carrega os últimos 4 destaques que façam referência a algum filme do Portacurtas, ordenados por posição. Tendo carregado com sucesso, o arquivo retorna em JSON: 28 Título do Destaque URL da Foto do Destaque Texto do Destaque URL do Destino do Destaque Número da Posição do Destaque ID do Filme do Destaque Figura 16 - Diagrama da consulta SQL para Destaques.asp 29 3.3.7 Filme.asp Este arquivo serve para obter os dados básicos de um determinado filme. Como apenas uma variável integer “ID” é passada via querysting, só é necessário verificar se a variável é de fato um número inteiro. Sendo este o caso, faz-se a conexão ao banco de dados e carrega os dados do filme ativo de mesma ID. Tendo carregado com sucesso, o arquivo retorna em JSON: Título do Filme, em Português Gênero do Filme Sinopse do Filme, em Português Diretor do Filme (apenas o primeiro) Bitola do Filme País de Produção do Filme Duração do Filme, em Minutos Ano de Lançamento do Filme Número de Comentários do Filme Número de Prêmios do Filme URL do Arquivo de Vídeo Número de Votos Valores da Votação 30 Figura 17 - Diagrama da consulta SQL para Filme.asp 31 3.3.8 FilmeDaSemana.asp Este arquivo serve para obter o destaque, uma escolha editorial, da Home Page do Porta Curtas conhecido como “Filme da Semana”. Não há nenhum input para este arquivo. Faz-se a conexão ao banco de dados e carrega o último filme definido como “filme da semana”. Tendo carregado com sucesso, o arquivo retorna em JSON: Título do Filme, em Português URL do Arquivo de Vídeo do Filme URL da Foto do Filme Figura 18 - Diagrama da consulta SQL para FilmeDaSemana.asp 3.3.9 GeoIP.asp Este arquivo serve como biblioteca para resolver IP em país. Feito pela MaxMind. 3.3.10 GeoIP.dat Este arquivo binário serve como repositório de dados local que relaciona endereços IP a um país. Caixa-preta. Feito pela MaxMind. 32 3.3.11 GravaSessao.asp Este arquivo serve para registrar uma visualização de filme de um usuário registrado ou não. A estatística de visualização de filme por plataforma é essencial para o relatório apresentado ao patrocinador do projeto Porta Curtas. Inicialmente, verifica se não há uma tentativa de SQL Injection antes de prosseguir. Tendo validado a variáveis “idUsuario”, “idFilme”, “IP” e “tempo” via querystring, ele inclui a biblioteca para exportação em JSON no ASP, e faz a conexão ao banco de dados SQL Server. Ao prosseguir, ele verifica se o tempo de visualização foi corretamente detectado pelo player usado no Android. Caso contrário, ele define o tempo como 1 segundo. Caso o IP não tenha sido detectado corretamente também, ele deixa em branco. Como o ID do filme é um ID válido que já foi passado do ASP para o Android, não há necessidade de verificar a validade do ID. Se o ID do Filme estiver definido e o Id do Usuário também, ele insere a visualização de filme na plataforma Android com o IP e tempo definidos. Caso o Id do Usuário não esteja definido, ele registrar uma visualização de usuário não-logado. Em caso de sucesso ao executar a inserção no banco de dados, o arquivo retorna em JSON um status “OK” para indicar o sucesso da operação. Caso contrário, o arquivo retorna em JSON um status “FALHA” para indicar a falha da operação de registrar uma visualização de Filme na plataforma Android. 3.3.12 JSON.asp Este arquivo serve para adicionar a manipulação de objetos JSON, uma vez que o VBScript não possui nativamente esse suporte. Esta biblioteca foi feita e tornada disponível publicamente por Tuðrul Topuz. 3.3.13 JSON_UTIL.asp Este arquivo serve para adicionar a função “QueryToJSON()”, que exporta o resultado de uma consulta SQL para um objeto JSON. 33 3.3.14 Login.asp Este arquivo serve para autenticar um usuário ao sistema do Porta Curtas, fornecidos o email e a senha. Inicialmente, verifica se não há uma tentativa de SQL Injection antes de prosseguir. Tendo validado as strings “email” e “password” via querystring, ele inclui a biblioteca para exportação em JSON no ASP, e faz a conexão ao banco de dados SQL Server. Ao prosseguir, substitui caracteres especiais em caracteres “amigáveis” para a consulta SQL, remove as aspas das strings, remove espaços no início no fim da string e transforma tudo em lowercase. Caso as strings não sejam vazias, ele consulta o banco de dados para ver se o usuário existe. Em caso positivo, ele retorna em JSON o status “OK” indicando o sucesso da autenticação, juntamente com o Id do Usuario em questão. Em caso negativo, retorna o status “FALHA” indicando a falha na operação de autenticação (login) do usuário. Figura 19 - Diagrama da consulta SQL para Login.asp 3.3.15 Premios.asp Este arquivo serve para obter os prêmios de um determinado filme. Como apenas uma variável integer “ID” é passada via querysting, só é necessário verificar se a variável é de fato um número inteiro. Sendo este o caso, faz-se a conexão ao banco de dados e carrega os prêmios do filme de mesma ID. 34 Tendo carregado com sucesso, o arquivo retorna em JSON: Nome do Prêmio Ano do Prêmio Nome do Festival em que foi concedido o Prêmio Figura 20 - Diagrama da consulta SQL para Premios.asp 3.3.16 Votar.asp Este arquivo serve para um usuário registrado e logado conseguir cadastrar um voto sobre um determinado filme. Inicialmente, verifica se não há uma tentativa de SQL Injection antes de prosseguir. Tendo validado as variáveis “idUsuario”, “idFilme” e “voto” via querystring, ele inclui a biblioteca para exportação em JSON no ASP, e faz a conexão ao banco de dados SQL Server. Ao prosseguir, verifica-se se todas as variáveis são números inteiros, e se “voto” é um valor entre 0 e 5. Como o ID de Filme e ID de Usuário já foram enviados do ASP para o Android, não é necessário checar a validade destes. Se todas as variáveis estiverem definidas e validadas, ele insere o voto do usuário ao filme no banco de dados e retorna 35 em JSON a mensagem “OK”, indicando que o comentário foi registrado. Caso contrário, ele retorna em JSON o status “FALHA”, indicando a falha da operação de cadastro do voto de um usuário a um filme. 3.4 App Android A aplicação implementada no dispositivo móvel atende aos seguintes propósitos: 1. Exibir o conteúdo multimídia dos filmes contratados do Portacurtas na plataforma móvel. 2. Permitir que o usuário consiga achar os filmes, comentar e votar. 3. Fazer a transmissão de vídeo dos filmes para a plataforma móvel, verificando a restrição da execução somente em território brasileiro, através da verificação do endereço IP. Os arquivos do projeto atendem às necessidades levantadas e a versão-alvo mínima escolhida foi a API #7 (Android 2.2) ou superior, englobando mais de 90% dos dispositivos disponíveis neste momento. Segue abaixo a descrição de cada componente da aplicação ASP. 3.4.1 AndroidManifest.xml Conforme já falamos na seção 2.2, o arquivo AndroidManifest.xml é essencial para o aplicativo Android, uma vez que ele apresenta os metadados relativos ao projeto. Essencialmente, é um arquivo XML que ajuda a definir os seguintes itens: Schema Versão do Aplicativo Pacote Versão-Alvo do sistema operacional Android Permissões necessárias para o uso ou execução do aplicativo no sistema operacional Android Nome e Ícone do Aplicativo 36 Activities (telas de interface com o Usuário) e Intents Figura 21 - AndroidManifest.xml do Portacurtas No aplicativo Portacurtas, definimos a versão como “1” e puxamos o nome da versão do Value string “credito_versao”. Usamos como alvo-mínimo a versão “7” do SDK, o que significa que o aplicativo será compatível com a versão Android 2.1 Eclair (API 7) ou superior, atingindo mais de 90% do mercado Android. As permissões utilizadas são: “INTERNET”: para que seja possível fazer uma conexão à Internet e “ACCESS_NETWORK_STATE”: para que seja possível verificar o acessar o conteúdo remotamente. status de conexão, incluindo a informação do endereço IP. O ícone e o nome do aplicativo são definidos também por Values, e em todas as atividades aplicamos o tema “NoTitleBar.Fullscreen” para que o aplicativo rode em tela cheia e sem a barra do título. 3.4.2 Layouts Dentro do diretório “res/layout/” se encontram os layouts que definem o padrão da distribuição dos elementos gráficos de interface para cada Activity. De uma forma geral, o LinearLayout foi o Layout básico utilizado em todos os layouts, pois disponibiliza 37 ao usuário uma navegação em uma única coluna ou linha. Os nós-filhos consistem em Views ou botões: TextView: área para texto EditText: área para texto editável ImageView: área para imagem Button: botão Na necessidade de organizar os nós-filhos em linha, utilizou-se de outros LinearLayout com orientação horizontal ou TableRow. Para áreas com necessidade de rolagem do conteúdo, foi utilizado o ScrollView, que permite trabalhar com uma área maior que a dimensão física do display utilizado. 3.4.3 Menu Menus são opções comuns de interface ao usuário, para prover navegabilidade ou customização de experiência. No Android, a forma de implementar o menu é 38 padronizada. Ao escrever um arquivo XML “menu.xml” no padrão requerido em “res/menu/”, o usuário poderá usá-lo no aplicativo ao apertar o botão “menu” correspondente em seu dispositivo móvel. Figura 22 - Menu no Android As opções disponíveis no menu do aplicativo Portacurtas são: Opções: configurar informações de login (endereço de email e senha) e uso de player de vídeo. 39 Comentar: quando na Activity de um filme, é possível registrar um Sobre: abre a Activity com informações do aplicativo comentário 3.4.4 Values O Android permite que o desenvolvedor possa guardar valores comumente utilizados pelo aplicativo num diretório “res/values/”. É possível definir e guardar recursos como strings, arrays, plurals, estilos, booleanos, inteiros, dimensões, cores e outros recursos. Figura 23 – Values No aplicativo Portacurtas, definimos alguns valores que usamos como constantes, como é o caso do título do Aplicativo ou as cores utilizadas. 3.4.5 BancoDados.java Este arquivo serve para definir a classe BancoDados que consome o serviço em JSON do servidor e pré-processa os dados de acordo com o objeto JSON lido para que o próximo componente possa receber os dados de forma limpa e correta. 40 A classe mantém um array JSON de colunas (keys) e valores (values). Dependendo da classe que a invoque, BancoDados busca o JSON de acordo com os dados pedidos. Se é necessário pegar os dados relativos à ficha de um filme, então BancoDados analisa o JSON vindo da URL relativa ao “FILME”, lê como uma cadeia de strings e processa num arquivo JSON válido, para que a classe requerente possa receber os dados corretamente. 3.4.6 Busca.java Este arquivo serve para definir a classe Busca que recebe os termos buscados e mantém uma tela (Activity) com os resultados de busca. Pela classe ser uma extensão de uma Activity, ela segue o ciclo de vida mencionado num capítulo anterior desde documento. Além disso, ao ser criada, ela define e reinicia variáveis e publica o conteúdo no layout “busca”. Ao pedir à classe BancoDados a consumação do webservice correspondente à busca, a classe Busca recebe o objeto JSON e faz o parsing do objeto a fim de separar os dados que serão utilizados. Tendo recebido e separado os dados sem problemas, ele atualiza o layout para adicionar os resultados de busca na tela, utilizando a classe Busca_Montador e a classe Busca_Item. 3.4.7 Busca_Item.java Este arquivo serve para definir a classe Busca_Item, que define as variáveis e métodos get e set para cada dado que deve ser apresentado no resultado de busca. 3.4.8 Busca_Montador.java Este arquivo serve para definir a classe Busca_Montador, que monta dinamicamente os itens de resultado de busca num determinado layout, de acordo com os resultados de busca que são passados. 41 3.4.9 Cadastro.java Este arquivo serve para definir a classe Cadastro, que serve para o usuário, ainda não cadastrado, efetuar o seu registro no sistema. Pela classe ser uma extensão de uma Activity, ela segue o ciclo de vida mencionado num capítulo anterior desde documento. Além disso, ao ser criada, ela define e reinicia variáveis e publica o conteúdo no layout “cadastro”. Tendo preenchido os campos do formulário e apertado o botão de cadastro, esta classe pede à classe BancoDados que consuma o webservice referente ao cadastro. A classe Cadastro recebe um objeto JSON da classe BancoDados com o resultado do cadastro. Tendo recebido e separado os dados sem problemas, Cadastro verifica se a operação de cadastro foi efetuada com sucesso, e em caso positivo, exibe uma caixa de diálogo (Dialog) com a mensagem de êxito. Caso contrário, ele exibe outra caixa de diálogo com a mensagem de falha de operação. 3.4.10 Comentar.java Este arquivo serve para definir a classe Comentar, que serve para o usuário registrar seu comentário para um filme. Pela classe ser uma extensão de uma Activity, ela segue o ciclo de vida mencionado num capítulo anterior desde documento. Além disso, ao ser criada, ela define e reinicia variáveis e publica o conteúdo no layout “comentar”. Tendo preenchido os campos do formulário e apertado o botão de comentar, esta classe pede à classe BancoDados que consuma o webservice referente ao ato de comentar. A classe Comentar recebe um objeto JSON da classe BancoDados com o resultado da operação de comentar. Tendo recebido e separado os dados sem problemas, Comentar verifica se a operação de comentar foi efetuada com sucesso, e em caso positivo, exibe uma caixa de diálogo (Dialog) com a mensagem de êxito. Caso contrário, ele exibe outra caixa de diálogo com a mensagem de falha de operação. 42 3.4.11 Comentarios.java Este arquivo serve para definir a classe Comentarios, que serve exibir os últimos comentários de um determinado filme. Pela classe ser uma extensão de uma Activity, ela segue o ciclo de vida mencionado num capítulo anterior desde documento. Além disso, ao ser criada, ela define e reinicia variáveis e publica o conteúdo no layout “comentarios”. Ao ser retomada (onResume()), a classe atualiza os comentários, pedindo que a classe BancoDados consuma o webservice referente aos comentários. Então, a classe Comentarios recebe o objeto JSON e faz o parsing do objeto a fim de separar os dados que serão utilizados. Tendo recebido e separado os dados sem problemas, ele atualiza o layout para adicionar os comentários na tela. A classe ainda dá a opção do usuário inserir um comentário. Caso o usuário esteja logado, há um Intent para Comentar. Caso contrário, exibe-se um alerta de login e pede à classe Principal que se chame o login. 3.4.12 Config.java Este arquivo serve para definir a classe Config, que serve para configurar e gravar as configurações disponíveis para o aplicativo. Pela classe ser uma extensão de uma Activity, ela segue o ciclo de vida mencionado num capítulo anterior desde documento. Além disso, ao ser criada, ela define e reinicia variáveis e publica o conteúdo no layout “config”. A classe utiliza o SharedPreferences para salvar as configurações feitas, que ficam gravadas persistentemente no sistema operacional. Ou seja, mesmo reiniciando o aplicativo, as preferências continuarão salvas naquele dispositivo até que outro commit de [chave;valor] tome o lugar do antigo. O usuário pode salvar suas informações de login (email e senha) e pode escolher o player de preferência ao tentar abrir o vídeo: usando o player nativo dentro do aplicativo Portacurtas ou usando um player de sua preferência, que esteja instalado no sistema. Ao clicar no botão de salvar, a classe faz um commit das chaves referentes ao login do usuário e da preferencia do player. Se caso houver alguma irregularidade com o que foi digitado 43 nos campos de formulário, um aviso Toast aparece para que o usuário tome ciência do problema. Esta classe também abriga algumas outras configurações invisíveis ao usuário, incluindo a URL do diretório de imagens, o modo DEBUG, a restrição por IP, o tempo de splash e o tempo de timeout para a execução do vídeo. 3.4.13 Destaques.java Este arquivo serve para definir a classe Destaques, que serve para exibir as escolhas editoriais do Portacurtas que são apresentadas como sugestões e destaques ao usuário. Como esta classe é precedida pela Activity do Splash Screen (tela com a marca Portacurtas), ela faz override do acionamento do botão “Back” (voltar). Isso faz com que em vez de voltar para a Activity anterior na pilha, ela acione um diálogo de confirmação de fechamento do aplicativo. Caso o usuário confirme a saída, o aplicativo é finalizado e as activities são destruídas. Pela classe ser uma extensão de uma Activity, ela segue o ciclo de vida mencionado num capítulo anterior desde documento. Além disso, ao ser criada, ela define e reinicia variáveis e publica o conteúdo no layout “destaques”. Ela também publica um diálogo com a mensagem da análise do IP: caso o IP seja do código do Brasil, exibe a mensagem de sucesso. Caso contrário, exibe uma mensagem informando que o usuário não poderá assistir os vídeos. Esta classe pede à classe BancoDados a consumação dos webservices correspondentes ao filme da semana e aos destaques. Prosseguindo, a classe Destaques recebe os objetos JSON e faz o parsing dos objetos a fim de separar os dados que serão utilizados. Tendo recebido e separado os dados sem problemas, ele atualiza o layout para definir os títulos, imagens e textos dos destaques carregados. Caso o usuário clique num destaque, a classe define um Intent para a Activity do Filme selecionado. 44 3.4.14 Filme.java Este arquivo serve para definir a classe Filme, que serve exibir a ficha técnica do filme, com os dados básicos: sinopse, gênero, diretor, elenco, duração e ano de lançamento. Pela classe ser uma extensão de uma Activity, ela segue o ciclo de vida mencionado num capítulo anterior desde documento. Além disso, ao ser criada, ela define e reinicia variáveis e publica o conteúdo no layout “filme”. Ao ser retomada (onResume()), a classe carrega os dados do filme, pedindo que a classe BancoDados consuma o webservice referente ao filme. Caso o filme tenha sido premiado, a classe Filme pede à classe BancoDados que consuma o webservice referente ao prêmio. Então, a classe Filme recebe o objeto JSON e faz o parsing do objeto a fim de separar os dados que serão utilizados. Tendo recebido e separado os dados sem problemas, ele atualiza o layout para exibir os dados do filme na tela. A classe ainda dá a opção do usuário votar. Caso o usuário esteja logado, a classe pede à BancoDados que consuma o webservice relacionado à operação de votar. E ao processar o objeto JSON do retorno, em caso de sucesso, uma mensagem Toast aparece com a indicação de sucesso na operação. Caso contrário, exibe-se um alerta de login e pede à classe Principal que se chame o login. Além disso, o usuário pode visualizar os comentários do filme. Nesse caso, a classe Filme define um Intent para Comentarios. E o usuário também pode efetuar um novo comentário para o filme em questão. Se este for o caso, a classe Filme define um Intent para Comentar. Se o usuário estiver com um IP não restringido, ou seja, um IP brasileiro, ele poderá visualizar o vídeo do filme, caso esteja disponível. Sendo este o caso, a classe Filme passa a URL para a classe Player e define um Intent para a classe Player. 3.4.15 Login.java Este arquivo serve para definir a classe Login, que serve para o usuário fazer o login (autenticação) com suas informações de conta. 45 Pela classe ser uma extensão de uma Activity, ela segue o ciclo de vida mencionado num capítulo anterior desde documento. Além disso, ao ser criada, ela define e reinicia variáveis e publica o conteúdo no layout “login”. Tendo preenchido os campos do formulário e apertado o botão de login, esta classe pede à classe BancoDados que consuma o webservice referente ao ato de logar. A classe Login recebe um objeto JSON da classe BancoDados com o resultado da operação de login. Tendo recebido e separado os dados sem problemas, Login verifica se a operação de login foi efetuada com sucesso, e em caso positivo, exibe uma caixa de diálogo (Dialog) com a mensagem de êxito. Caso contrário, ele exibe outra caixa de diálogo com a mensagem de falha de operação. Há ainda a opção do usuário não-cadastrado fazer um novo registro. Neste caso, a classe Login define um Intent para Cadastro. 3.4.16 Player.java Este arquivo serve para definir a classe Player, que serve exibir o arquivo de vídeo na tela do dispositivo. Pela classe ser uma extensão de uma Activity, ela segue o ciclo de vida mencionado num capítulo anterior desde documento. Além disso, ao ser criada, ela define e reinicia variáveis e publica o conteúdo no layout “player”. Ainda no momento de criação, a classe verifica se deve tocar o vídeo no player interno ou externo, dependendo da configuração feita e salva na classe Config. Caso seja para tocar no player interno (player nativo padrão do sistema operacional Android), o vídeo é renderizado no VideoView do layout. Após a definição de onde vai tocar o vídeo, a classe Player invoca a execução do vídeo. Caso esteja tocando internamente, ela abre a URL do arquivo de vídeo passada anteriormente, e atribui um controle de mídia MediaController sobre o vídeo. Tendo o controle e video setados, o vídeo começa a execução. Caso esteja tocando externamente, a classe Player define um Intent do tipo de dados “vídeo/*”, para que o sistema Android forneça as opções disponíveis de player para o arquivo de vídeo informado. Ao ser retomada (onResume()), caso esteja tocando em player externo, a classe define o tempo como “1”, pois é impossível adquirir o tempo que o vídeo foi tocado num 46 aplicativo externo, e grava a sessão ao pedir que a classe BancoDados consuma o webservice referente à gravação da sessão de filme. Ao ser finalizar (onFinish()), caso o tempo que o vídeo foi tocado não tenha sido detectado apropriadamente, a classe define o tempo como “1” e grava sessão conforme comentado acima. Durante a execução do vídeo no player interno, alguns controles são overrided para que seja detectado, assincronamente, a duração do período da execução do vídeo. Além disso, os controles também são overrided para que possa detectar quando o vídeo foi terminado de executar, para que possa invocar a gravação de sessão – pedindo à classe BancoDados que consuma o webservice referente à gravação de sessão. 3.4.17 Principal.java Este arquivo serve para definir a classe Principal, que serve exibir a tela de Splash com a marca do Portacurtas e possui métodos globais que são utilizados por outras classes. Pela classe ser uma extensão de uma Activity, ela segue o ciclo de vida mencionado num capítulo anterior desde documento. Ao ser criada, ela define e reinicia variáveis e publica o conteúdo no layout “main”. Ainda na criação, a classe invoca a definição e o carregamento das constantes definidas na classe Config. Ela checa se existe uma conexão à Internet, disponível no momento em que inicia. Caso não exista uma conexão, a classe exibe um diálogo alertando o usuário que não é possível conectar e obter os dados necessários para o aplicativo. Logo no início, a classe Principal pega o IP local do dispositivo e pede à classe BancoDados que consuma o webservice referente à verificação de IP com o serviço GeoIP no servidor, e recebe como retorno em objeto JSON o código de país. Após o tempo do splash ter passado, a classe limpa quaisquer valores residuais da última execução e define uma Intent para Destaques. Além disso, a classe também define um Intent para chamar o Login sempre que for necessário – ao comentar ou votar, estando o usuário deslogado, por exemplo. A classe define uma maneira de fazer o logging das atividades e adiciona o botão play às imagens dos filmes, para que o usuário entenda que há um vídeo disponível para a execução. 47 3.4.18 Sobre.java Este arquivo serve para definir a classe Sobre, que serve exibir as informações deste aplicativo Android – tais como autor e número da versão atual. Pela classe ser uma extensão de uma Activity, ela segue o ciclo de vida mencionado num capítulo anterior desde documento. Além disso, ao ser criada, ela define e reinicia variáveis e publica o conteúdo no layout “sobre”. A classe apenas exibe textos fixos sobre o desenvolvedor deste aplicativo e a versão atual do mesmo. 48 3.5 Demonstração Ao abrir o aplicativo no Android, exibe-se a splash screen com a informação do endereço IP da conexão atual. Tendo verificado que há conexão à Internet e os recursos são carregados e abre-se a activity “Destaques da Semana” com a verificação da resolução do endereço IP em código do país. Figura 24 - Splash Screen Figura 25 - Destaques com análise do IP 49 A partir dos Destaques,é possível abrir o filme da semana anunciado no topo da activity, visualizar os quatro destaques editoriais abaixo ou fazer uma busca de um filme por um título. Figura 26 - Destaques da Semana Figura 27 - Busca 50 Efetuando a busca pelo termo “amor”, uma activity de busca é iniciada e exibe os resultados de filmes que possuam “amor” como parte do título. Ao selecionar qualquer um dos resultados, a ficha do filme é carregada e é possível ver as informações básicas do filme em questão. Figura 28 - Resultados de Busca Figura 29 - Ficha do Filme 51 Ao selecionar o botão “Comentar”, a activity de Comentarios é lançada e exibe- se os comentários de outros usuários para o filme selecionado. Selecionando novamente o botão “Comentar”, é lançada a activity para efetuar o comentário se o usuário já estiver logado no aplicativo. Caso contrário, abre-se a activity de login. Figura 30 - Comentarios do Filme Figura 31 - Login 52 Com o usuário autenticado, é possível registrar o comentário ou o voto em relação ao filme selecionado. Figura 32 - Usuário registrando comentário Figura 33 - Usuário registrando voto 53 Se o filme selecionado possuir um vídeo cadastrado, e estando com um IP considerado brasileiro pelo GeoLite, é possível visualizar o vídeo no tocador de vídeo nativo do dispositivo Android ou num outro tocador instalado pelo usuário. Essas preferências são controladas a partir da activity de configuração, onde também é possível deixar os dados de autenticação do usuário salvos para próximas autenticações. Figura 34 - Configurações Figura 35 - Exibição do vídeo 54 Capítulo 4 Considerações Finais O projeto foi concebido como uma prova de conceito para uma aplicação móvel que permitisse a distribuição de conteúdo audiovisual em dispositivos móveis com um controle de restrição de geolocalização e atingiu os objetivos definidos inicialmente. Por não existir uma maneira nativa, no Android, de fazer conexão ao banco de dados, a dificuldade foi criar um aplicativo externo que rodasse num servidor e fornecesse os dados a serem consumidos via Webservices. Além disso, houve a necessidade de utilizar um componente à parte para implementar a restrição de Geolocalização. Isso também acarretou na decisão da hospedagem e processamento dos dados de tal restrição no lado do servidor para que não sobrecarregasse o aplicativo Android. Com a influência da disciplina cursada ainda em período letivo, a implementação foi feita em Android e foi ainda mais incentivada com o estágio na distribuidora de vídeos Synapse. Tendo em vista as tecnologias adotadas pela a empresa, o servidor Windows rodando aplicativos ASP e banco de dados SQL Server, e com o consumo do serviço MaxMind GeoIP, a solução foi facilmente desenvolvida. Ainda que a solução como um todo alcance seu propósito, ainda se encontra distante de uma experiência agradável ao usuário em termos de navegabilidade ou de padrões de desenho (design patterns) mais contemporâneos. É possível ainda sofisticar o lado do servidor com aplicativos mais robustos e com serviços terceirizados de geolocalização mais atualizados, para que a distribuição de vídeo também seja mais escalável e segura. 55 Capítulo 5 Revisão Bibliográfica [1] TAPSCOTT, D. WILLIAMS, A. D., Wikinomics: How Mass Collaboration Changes Everything. Portfolio, New York, 2006. [2] Amazon. Disponível em: http://www.amazon.com/ Acessado em: 23/08/2011. [3] Google. Disponível em: http://www.google.com/ Acessado em: 23/08/2011. [4] Facebook. Disponível em: http://www.facebook.com/ Acessado em: 23/08/2011. [5] Netflix. Disponível em: http://www.netflix.com/ Acessado em: 23/08/2011. [6] SCHAFTER, J.B., KONSTAN, J., RIEDL, J., “Recommender systems in ecommerce”. In Proceedings of the 1st ACM conference on Electronic commerce. Denver, Colorado, United States: ACM, 1999, pp. 158-166. [7] PATEREK, A., “Improving Regularized Singular Value Decomposition for Collaborative Filtering”. In Proc. KDD Cup and Workshop, 2007. [8] Folha do Estado de São Paulo. Disponível em: http://economia.estadao.com.br/noticias/economia+geral,vendas-nainternet-crescem-40-em-2010-mostra-e-bit,59544,0.htm Acessado em: 23/08/2011. [9] GOLDBERG, D., NICHOLS, D., OKI, B. M., TERRY, D., “Using collaborative filtering to weave an information tapestry”. Communications of ACM, vol. 35, no. 12, pp. 61–70, 1992. [10] SU, X. Y., KHOSHGOFTAAR, T.M., “A survey of collaborative filtering techniques”. Advances in Artificial Intelligence, 2009. 56
