Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial

on

  • 321 views

Este trabalho apresenta um estudo sobre a construção de aplicativos sociais usando as APIs do OpenSocial. Faz uma breve abordagem sobre a história do OpenSocial e lista os recipientes que suportam ...

Este trabalho apresenta um estudo sobre a construção de aplicativos sociais usando as APIs do OpenSocial. Faz uma breve abordagem sobre a história do OpenSocial e lista os recipientes que suportam as APIs. Mostra a anatomia de um aplicativo social, bem como as técnicas que podem ser usadas para o seu desenvolvimento.
Apresenta um estudo teórico sobre as APIs que compõe o OpenSocial, tanto a API JavaScript quanto a API para serviços RESTful e em seguida aborda o desenvolvimento usando o OpenSocial Templates (OST). Promove uma comparação entre as APIs do OpenSocial e da rede social Facebook.
Finalmente, apresenta os detalhes de implementação de um aplicativo social na forma de um jogo.

Statistics

Views

Total Views
321
Views on SlideShare
221
Embed Views
100

Actions

Likes
0
Downloads
9
Comments
0

2 Embeds 100

http://cleber.net.br 99
http://www.google.com.br 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial Document Transcript

  • 1. UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ – UTFPR CURSO SUPERIOR DE TECNOLOGIA EM DESENVOLVIMENTO DE SISTEMAS DE INFORMAÇÃO CLEBERSANDER RECH CONSTRUINDO APLICATIVOS SOCIAIS UTILIZANDO AS APIS DO OPENSOCIAL TRABALHO DE DIPLOMAÇÃO MEDIANEIRA 2010
  • 2. CLEBERSANDER RECH CONSTRUINDO APLICATIVOS SOCIAIS UTILIZANDO AS APIS DO OPENSOCIAL Trabalho de Diplomação apresentado à disciplina de Trabalho de Diplomação, do Curso Superior de Tecnologia em Desenvolvimento de Sistemas de Informação da Universidade Tecnológica Federal do Paraná – UTFPR, como requisito parcial para obtenção do título de Tecnólogo. Orientador: Prof. Romualdo Rubens de Freitas. MEDIANEIRA 2010
  • 3. Ministério da Educação Universidade Tecnológica Federal do Paraná Gerência de Ensino Curso Superior de Tecnologia em desenvolvimento de Sistemas de Informação TERMO DE APROVAÇÃO Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial Por Clebersander Rech Este Trabalho de Diplomação (TD) foi apresentado às 14:00 h do dia 18 de novembro de 2010 como requisito parcial para a obtenção do título de Tecnólogo no Curso Superior de Tecnologia em desenvolvimento de Sistemas de Informação, da Universidade Tecnológica Federal do Paraná, Campus Medianeira. Os acadêmicos foram argüidos pela Banca Examinadora composta pelos professores abaixo assinados. Após deliberação, a Banca Examinadora considerou o trabalho aprovado com louvor e mérito. Prof. Romualdo Rubens de Freitas UTFPR – Campus Medianeira (Orientador) Prof. Fernando Schütz UTFPR – Campus Medianeira (Convidado) Prof. Itamar Pena Nieradka UTFPR – Campus Medianeira (Convidado) Prof. Juliano Rodrigo Lamb UTFPR – Campus Medianeira (Responsável pelas atividades de TCC)
  • 4. AGRADECIMENTOS A Deus, autor da vida, por ter me permitido concluir essa caminhada. Aos meus pais Marina e Constantino, pela compreensão e auxílio prestado. E ao resto da minha família, em especial os meus irmãos Max e Willian. Ao meu professor orientador Romualdo pelo auxílio prestado durante o desenvolvimento desse trabalho. Também a todos os professores que de uma forma ou de outra contribuíram com o seu conhecimento ao longo da faculdade. Aos meus ex-colegas de faculdade e de trabalho, pela troca de conhecimentos e pela convivência. E aos demais de também contribuíram para a realização deste trabalho.
  • 5. “A mente que se abre a uma nova idéia jamais voltará ao seu tamanho original.” (EINSTEIN, Albert)
  • 6. RESUMO RECH, Clebersander Rech. Construindo Aplicativos Sociais Utilizando as APIs do Opensocial. 2010. Trabalho de Conclusão de Curso, Universidade Tecnológica Federal do Paraná. Medianeira, 2010. Este trabalho apresenta um estudo sobre a construção de aplicativos sociais usando as APIs do OpenSocial. Faz uma breve abordagem sobre a história do OpenSocial e lista os recipientes que suportam as APIs. Mostra a anatomia de um aplicativo social, bem como as técnicas que podem ser usadas para o seu desenvolvimento. Apresenta um estudo teórico sobre as APIs que compõe o OpenSocial, tanto a API JavaScript quanto a API para serviços RESTful e em seguida aborda o desenvolvimento usando o OpenSocial Templates (OST). Promove uma comparação entre as APIs do OpenSocial e da rede social Facebook. Finalmente, apresenta os detalhes de implementação de um aplicativo social na forma de um jogo. Palavras-chave: OpenSocial. Aplicativos sociais. Redes sociais.
  • 7. ABSTRACT RECH, Clebersander Rech. Building Social Applications Using OpenSocial APIs. 2010. Trabalho de Conclusão de Curso, Universidade Tecnológica Federal do Paraná. Medianeira, 2010. This paper presents a study on how to build social applications using OpenSocial APIs. Shows a brief view of OpenSocial's history and lists the containers that support the APIs. Shows the anatomy of a social application, as well as the techniques that can be used for its development. Presents a theoretical study about OpenSocial's JavaScript API as well as the API for RESTful services and then talks about using OpenSocial Templates (OST) for software development. Promotes a comparison between OpenSocial's APIs and Facebook's social network API. Finally, presents the implementation details of a social game application. Keywords: OpenSocial. Social applications. Social Networks.
  • 8. LISTA DE FIGURAS FIGURA 1 - ARQUITETURA ENTRE A REDE SOCIAL E O APLICATIVO ...................27 FIGURA 2 - ARQUITETURA DE UM APLICATIVO SOCIAL COMPLETAMENTE BASEADO NO SERVIDOR .................................................................................28 FIGURA 3 - CAMADAS DE UM APLICATIVO OPENSOCIAL E COMUNICAÇÕES ASSÍNCRONAS COM O RECIPIENTE ...............................................................29 FIGURA 4 - PARTES QUE COMPÕE A URL DE UMA CHAMADA REST DO OPENSOCIAL .....................................................................................................55 FIGURA 5 - PARTES QUE COMPÕE A URL DE UMA CHAMADA REST DO FACEBOOK.........................................................................................................67 FIGURA 6 - ESBOÇO DO JOGO DA FORCA. ..............................................................72 FIGURA 7 - DIAGRAMA DE CASOS DE USO ..............................................................73 FIGURA 8 - DIAGRAMA DE ATIVIDADES ....................................................................75 FIGURA 9 - ESTRUTURA DE ARQUIVOS QUE COMPÕE O JOGO............................77 FIGURA 10 - VISÃO HOME DO JOGO NO IGOOGLE..................................................80 FIGURA 11- VISÃO CANVAS DO JOGO NO IGOOGLE...............................................82 FIGURA 12 - VISÃO CANVAS DO JOGO......................................................................83 FIGURA 13 - VISÃO DO JOGO QUANDO O USUÁRIO ACERTA OU ERRA O NOME DO AMIGO...............................................................................................84 FIGURA 14 - ATIVIDADE CRIADA PELO JOGO NO ORKUT.......................................85
  • 9. LISTA DE QUADROS QUADRO 1 - APLICATIVOS MAIS POPULARES DO ORKUT......................................17 QUADRO 2 - DATAS DAS PUBLICAÇÕES DAS ESPECIFICAÇÕES DO OPENSOCIAL 18 QUADRO 3 - EXEMPLO DA LINGUAGEM DE MARCAÇÃO XML................................22 QUADRO 4 - EXEMPLO DA LINGUAGEM DE MARCAÇÃO HTML..............................22 QUADRO 5 - EXEMPLO DA LINGUAGEM JAVASCRIPT.............................................23 QUADRO 6 - SINTAXE BÁSICA DE UM OBJETO JSON..............................................23 QUADRO 7 - APLICATIVO DE EXEMPLO DO OPENSOCIAL......................................30 QUADRO 8 - APLICATIVO DE EXEMPLO DO OPENSOCIAL COM DESTAQUE DE CORES DAS SEÇÕES........................................................................................32 QUADRO 9 - ATRIBUTOS DA SEÇÃO MODULEPREFS .............................................33 QUADRO 10 - ELEMENTOS OPCIONAIS DA SEÇÃO MODULEPREFS .........................33 QUADRO 11 - ATRIBUTOS DA SEÇÃO CONTENT........................................................34 QUADRO 12 - APIS ESPECÍFICAS DOS RECURSOS.................................................35 QUADRO 13 - PACOTE DE MENSAGEM.....................................................................36 QUADRO 14 - DEFININDO OS IDIOMAS DE UM GADGET .........................................37 QUADRO 15 - ACESSANDO UM PACOTE DE MENSAGENS VIA A API JAVASCRIPT.37 QUADRO 16 - FUNÇÕES DA CLASSE OPENSOCIAL.PERSON.....................................40 QUADRO 17 - PRINCIPAIS CAMPOS DO OBJETO OPENSOCIAL.PERSON.FIELD ....41 QUADRO 18 - POLÍTICA DE ACESSO DE ALGUNS CAMPOS DOS PERFIS DO ORKUT ................................................................................................................42 QUADRO 19 - FUNÇÃO PARA REQUISITAR A LISTA DE AMIGOS DO DONO DO APLICATIVO........................................................................................................42 QUADRO 20 - FUNÇÃO PARA REQUISITAR A LISTA DE AMIGOS DO DONO DO APLICATIVO USANDO A OSAPI ........................................................................42 QUADRO 21 - FUNÇÃO PARA PROCESSAR O RETORNO DA REQUISIÇÃO DA LISTA DE AMIGOS..............................................................................................44 QUADRO 22 - LISTANDO OS AMIGOS DO DONO DE UM APLICATIVO....................45 QUADRO 23 - PRINCIPAIS CAMPOS DO OBJETO OPENSOCIAL.MESSAGE.FIELD.TYPE.................................................47 QUADRO 24 - PRINCIPAIS CAMPOS DO OBJETO OPENSOCIAL.MESSAGE.FIELD ..47 QUADRO 25 - ENVIANDO UMA MENSAGEM DE E-MAIL ...........................................48 QUADRO 26 - ENVIANDO UMA MENSAGEM DE E-MAIL USANDO A OSAPI............48 QUADRO 27 - CAMPOS DO OBJETO OPENSOCIAL.ACTIVITY.FIELD .....................49 QUADRO 28 - CRIANDO UMA ATIVIDADE ..................................................................50 QUADRO 29 - CRIANDO UMA ATIVIDADE USANDO A OSAPI...................................50 QUADRO 30 - CRIANDO UM CONVITE PARA UM USUÁRIO .....................................50 QUADRO 31 - CRIANDO UM CONVITE PARA UM USUÁRIO USANDO A OSAPI......50 QUADRO 32 - GRAVANDO UM DADO .........................................................................51 QUADRO 33 - GRAVANDO UM DADO USANDO A OSAPI..........................................52 QUADRO 34 - RECUPERANDO UM DADO USANDO A OSAPI ..................................52 QUADRO 35 - RECUPERANDO UM DADO..................................................................53 QUADRO 36 - EXCLUÍNDO UM DADO.........................................................................53 QUADRO 37 - EXCLUÍNDO UM DADO USANDO A OSAPI .........................................53 QUADRO 38 - ESTRUTURA DO OBJETO DE RESPOSTA DE UMA REQUISIÇÃO REST ...................................................................................................................54 QUADRO 39 - FRAGMENTOS DA URL PARA O RECURSO PESSOA .......................56
  • 10. QUADRO 40 - REPRESENTAÇÃO DE UMA PESSOA NO FORMATO JSON .............57 QUADRO 41 - REPRESENTAÇÃO DE UMA PESSOA NO FORMATO XML ...............57 QUADRO 42 - FRAGMENTOS DA URL PARA O RECURSO GRUPO.........................57 QUADRO 43 - FRAGMENTOS DA URL PARA O RECURSO ATIVIDADE...................58 QUADRO 44 - FRAGMENTOS DA URL PARA O RECURSO DADOS DO APLICATIVO .58 QUADRO 45 - PARÂMETROS DE CONSULTA ............................................................59 QUADRO 46 - TEMPLATE DO OPENSOCIAL..............................................................60 QUADRO 47 - TEMPLATE DO OPENSOCIAL..............................................................60 QUADRO 48 - USANDO LINGUAGEM DE EXPRESSÃO.............................................60 QUADRO 49 - CRIAÇÃO E CHAMADA DE UM TEMPLATE.........................................62 QUADRO 50 - USO DO ATRIBUTO IF DO TEMPLATE...............................................62 QUADRO 51 - USO DO ELEMENTO <OS:IF> .............................................................63 QUADRO 52 - USO DO ATRIBUTO IF DO TEMPLATE...............................................63 QUADRO 53 - USO DO ELEMENTO <OS:IF> .............................................................63 QUADRO 54 - TAGS DISPONÍVEIS..............................................................................64 QUADRO 55 - TAGS DISPONÍVEIS PARA PIPELINING DE DADOS...........................65 QUADRO 56 - USO DE PIPELINING DE DADOS EM CONJUNTO COM TEMPLATES...66 QUADRO 57 - TAGS DO OSML E DO FBML COM FUNÇÕES SEMELHANTES.........70 QUADRO 58 - ELEMENTO MODULEPREFS DO ARQUIVO GADGET.XML ......................77 QUADRO 59 - REQUISIÇÃO PARA CARREGAR O PRIMEIRO AMIGO......................78 QUADRO 60 - RECUPERANDO O NÚMERO DE AMIGOS..........................................79 QUADRO 61 - TRECHO DO ARQUIVO GADGET.XML...................................................80 QUADRO 62 - TRECHO DA VISÃO HOME E PROFILE DO ARQUIVO GADGET.XML..81
  • 11. LISTA DE ABREVIATURAS E SIGLAS AJAX Asynchronous Javascript And XML API Application Programming Interface CSS Cascading Style Sheets FBML Facebook Markup Language FQL Facebook Query Language GIF Graphics Interchange Format HTML HyperText Markup Language IDE Integrated Development Environment JPG Joint Photographic Experts Group JSON JavaScript Object Notation JSP JavaServer Pages OSAPI OpenSocial Application Programming Interface OSDE OpenSocial Development Environment OSML OpenSocial Markup Language OST OpenSocial Templating PHP PHP: Hypertext Preprocessor PNG Portable Network Graphics REST Representational State Transfer RPC Remote Procedure Call SDK Software Development Kit SQL Structured Query Language SWF Shockwave Flash UML Unified Modeling Language URI Uniform Resources Identifier URL Uniform Resource Locator XML eXtensible Markup Language
  • 12. SUMÁRIO 1 INTRODUÇÃO.........................................................................................................13 1.1 OBJETIVOS.............................................................................................................14 1.1.1 Objetivo Geral......................................................................................................14 1.1.2 Objetivos Específicos...........................................................................................14 1.2 JUSTIFICATIVA.......................................................................................................14 1.3 ESTRUTURA DO TRABALHO ................................................................................15 2 REDES SOCIAIS VIRTUAIS ...................................................................................16 2.1 ORKUT ....................................................................................................................16 2.2 OPENSOCIAL..........................................................................................................17 2.2.1 Diretório de Aplicativos ........................................................................................19 2.2.2 Melhores Práticas ................................................................................................20 2.2.3 Tecnologia e Ferramentas Envolvidas.................................................................21 2.2.3.1 XML ...................................................................................................................21 2.2.3.2 HTML.................................................................................................................22 2.2.3.3 JavaScript..........................................................................................................22 2.2.3.4 JSON .................................................................................................................23 2.2.3.5 REST .................................................................................................................24 2.2.3.6 OAuth ................................................................................................................24 2.2.3.7 Apache Shindig..................................................................................................25 2.2.3.8 OSDE ................................................................................................................26 2.2.4 Arquitetura do OpenSocial...................................................................................26 2.2.4.1 API Baseada no Cliente.....................................................................................27 2.2.4.2 API Baseada no Servidor...................................................................................28 2.2.5 Arquitetura de um Aplicativo................................................................................29 2.2.6 Aplicativo de Exemplo..........................................................................................30 3 APLICATIVOS DO OPENSOCIAL..........................................................................31 3.1 GADGET XML .........................................................................................................31 3.2 API DE GADGETS...................................................................................................34 3.2.1 Internacionalização..............................................................................................35 3.2.1.1 Pacotes de Mensagens .....................................................................................36 3.2.1.2 Acessando o Pacote de Mensagens .................................................................37 3.3 API JAVASCRIPT DO OPENSOCIAL......................................................................38 3.3.1 OSAPI..................................................................................................................38 3.3.2 Pessoas...............................................................................................................39 3.3.3 Requisições .........................................................................................................42 3.3.4 Atividades ............................................................................................................46 3.3.4.1 Mensagens de E-mail e Notificações.................................................................46 3.3.4.2 Atualizações ......................................................................................................48 3.3.4.3 Convites.............................................................................................................50 3.3.5 Persistência .........................................................................................................51 3.3.5.1 Armazenando Dados.........................................................................................51 3.3.5.2 Recuperando Dados..........................................................................................52 3.3.5.3 Excluindo Dados................................................................................................53 3.4 API RESTFUL DO OPENSOCIAL ...........................................................................54 3.5 OPENSOCIAL TEMPLATES (OST).........................................................................59 3.5.1 Formato do Template...........................................................................................60 3.5.2 Expressões..........................................................................................................60
  • 13. 3.5.3 Variáveis..............................................................................................................61 3.5.4 Chamada de Templates.......................................................................................61 3.5.5 OpenSocial Markup Language (OSML)...............................................................62 3.5.6 Conteúdo Condicional..........................................................................................62 3.5.7 Elementos de Repetição......................................................................................63 3.5.8 Tags.....................................................................................................................63 3.6 PIPELINING DE DADOS .........................................................................................64 3.7 FACEBOOK .............................................................................................................66 3.7.1 Plataforma Facebook...........................................................................................67 3.7.2 Comparativo Entre as APIs do OpenSocial e do Facebook.................................69 3.7.2.1 Linguagem de Marcação ...................................................................................69 3.7.2.2 JavaScript..........................................................................................................70 3.7.2.3 Segurança .........................................................................................................71 4 ESTUDO DE CASO.................................................................................................72 4.1 O JOGO...................................................................................................................72 4.2 ANÁLISE..................................................................................................................73 4.2.1 Casos de Uso ......................................................................................................73 4.2.2 Diagrama de Atividades.......................................................................................75 4.3 IMPLEMENTAÇÃO..................................................................................................75 4.3.1 Carregando um Amigo.........................................................................................78 4.3.2 Visões..................................................................................................................79 4.3.3 Atividades e Compartilhamento ...........................................................................84 4.3.4 Adicionando o Aplicativo......................................................................................85 5 CONSIDERAÇÕES FINAIS.....................................................................................87 REFERÊNCIAS..............................................................................................................88 ANEXOS ........................................................................................................................93
  • 14. 13 1 INTRODUÇÃO Nos últimos anos houve um aumento no número de redes sociais e sites de relacionamento. Todos eles têm em comum a interação entre pessoas, sejam conhecidas ou desconhecidas. É natural do ser humano querer se associar a um grupo e interagir com outros indivíduos. Pode-se atribuir a isso o sucesso desses sites. Com os seus mais de 500 milhões de usuários, o Facebook é a rede social mais popular do mundo (YANO, 2010). No Brasil, a anos também tem-se presenciado o sucesso de outra rede social, o Orkut, que pertence ao Google. Em 2007, o Facebook disponibilizou APIs (Application Programming Interface) para que aplicativos de terceiros pudessem interagir com os usuários do site (KIRKPATRICK, 2007, tradução própria). Desde então, qualquer pessoa com conhecimento de programação pode criar aplicativos que podem ser usados por qualquer um dos 500 milhões de usuários do Facebook. No entanto, esses aplicativos só funcionam no Facebook. Assim como o Facebook, outras redes de relacionamentos interessaram-se em disponibilizar aplicativos para os seus usuários. Pensando nisso, o Google e outras empresas criaram o OpenSocial, uma plataforma que, assim como o Facebook, fornece APIs que podem ser usadas por aplicativos de terceiros para interagir com os usuários de uma rede social. O maior benefício do OpenSocial é a possibilidade de desenvolver um aplicativo que seja executado em diferentes redes sociais, pois as suas APIs são padronizadas. Pode-se fazer uma analogia com a linguagem de programação Java, em que um programa criado usando essa linguagem pode ser executado em diferentes plataformas, como Windows e Linux, por exemplo. Da mesma forma, um aplicativo criado usando o OpenSocial pode, por exemplo, ser executado no Orkut e no MySpace. Tanto o Facebook quanto o OpenSocial têm atraído muitos interessados em desenvolver usando as suas APIs, pois um usuário de uma rede social é um potencial consumidor, e todas essas redes possuem centenas de milhões de usuários. Todo esse mercado não pode passar despercebido.
  • 15. 14 1.1 OBJETIVOS Apresentar um estudo sobre a construção de aplicativos sociais utilizando as APIs do OpenSocial. 1.1.1 Objetivo Geral Realizar um estudo das APIs do OpenSocial e demonstrar o seu funcionamento através da criação de um aplicativo usando a API JavaScript do OpenSocial, que poderá ser hospedado e executado em qualquer rede de relacionamentos que implemente as especificações do OpenSocial. 1.1.2 Objetivos Específicos  Estudar as APIs comuns que compõe o OpenSocial e a estrutura de um aplicativo;  Comparar as APIs do OpenSocial com as APIs do Facebook;  Analisar e implementar um aplicativo utilizando a API JavaScript do OpenSocial;  Hospedar o aplicativo desenvolvido na rede de relacionamentos Orkut. 1.2 JUSTIFICATIVA Sendo a rede social Orkut o segundo site mais acessado no Brasil (ALEXA, 2010b) e o Facebook o segundo site mais acessado no mundo (ALEXA, 2010a), é inegável que as redes de sociais (ou redes de relacionamentos) fazem parte do dia- a-dia das pessoas que acessam a Internet. Com o crescente número de internautas e consequentemente das redes sociais, surge uma demanda por aplicativos com características sociais. E para facilitar a vida do desenvolvedor foi criado o OpenSocial, uma plataforma que fornece um conjunto de APIs para acessar informações sobre individuos e seus
  • 16. 15 relacionamentos entre si e ainda tem a capacidade de disponibilizar e exibir atualizações sobre as ações das pessoas. O OpenSocial utiliza JavaScript, HTML (HyperText Markup Language) e XML (eXtensible Markup Language), permitindo que qualquer desenvolvedor web possa trabalhar com ele. As APIs também fornecem algumas facilidades a mais, como um sistema de armazenamento de dados e um sistema de retorno de chamada assíncrono, também conhecido como callback1 , para suportar interatividade AJAX (Asynchronous Javascript And XML). 1.3 ESTRUTURA DO TRABALHO Este trabalho é dividido em quatro capítulos. O primeiro capítulo introduz as redes sociais e o OpenSocial, bem como apresenta os objetivos e a justificativa do trabalho. O segundo capítulo apresenta uma introdução às redes sociais virtuais, como o Orkut, por exemplo. Também é apresentado o OpenSocial, os motivos que o levaram a ser criado e informações sobre os aplicativos sociais. O terceiro capítulo aborda o estudo das APIs do OpenSocial e as formas de criar um aplicativo. E por último, no quarto capítulo, é realizada a análise e implementação de um aplicativo utilizando as APIs do OpenSocial. ‒‒‒‒‒‒‒‒‒‒‒‒‒‒ 1 Uma função callback é uma função que é passada como parâmetro para outro código que a invocará posteriormente.
  • 17. 16 2 REDES SOCIAIS VIRTUAIS Segundo Ferla (2008): "As redes sociais são formadas por indivíduos com interesses, valores e objetivos comuns para o compartilhamento de informações. A internet é um dos grandes fomentadores para a formação de redes, porque as pessoas podem se encontrar independente de tempo e espaço. As pessoas criam redes sociais online a partir de sites de networking como o Orkut e são um dos principais tipos de ferramentas de mídias sociais." A popularidade das redes sociais virtuais é muito grande. De acordo com Roos (2007), "sites como MySpace, Facebook e Linkedln estão entre os sete dos 20 Websites mais visitados no mundo, e o site de relacionamentos criado pelo Google, o Orkut, acabou virando o predileto dos brasileiros." Alguns recursos são comuns na maioria da redes sociais, como a criação de um perfil pessoal, que pode ser compartilhado. Esse perfil normalmente possui uma foto, informações básicas como o nome, idade, local e um espaço em que são descritas as preferências pessoais, como livros, filmes e gosto musical. O recurso mais importante dessas redes sociais online é encontrar e fazer amigos com outros membros da rede. (ROOS, 2007). As redes sociais virtuais também permitem "a formação de grupos por afinidade, com ou sem autorização, e de espaços específicos para discussões, debates e apresentação de temas variados (comunidades, fóruns, Twitter, sites de relacionamento)." (REDE SOCIAL VIRTUAL, 2010). 2.1 ORKUT De acordo com Orkut (2010a): Orkut é uma rede social filiada ao Google, criada em 24 de Janeiro de 2004 com o objetivo de ajudar seus membros a conhecer pessoas e manter relacionamentos. Seu nome é originado no projetista chefe, Orkut Büyükkokten, engenheiro turco do Google. O alvo inicial do orkut era os Estados Unidos, mas a maioria dos usuários são do Brasil e da Índia. No Brasil é a rede social com maior participação de brasileiros, com mais de 23 milhões de usuários, e o site mais visitado. Na Índia é o segundo mais visitado.
  • 18. 17 Os brasileiros são a maioria no Orkut, representando 50,93% do total de usuários. Indianos formam 20,12% do total e usuários dos Estados Unidos representam 17,56%. (ORKUT, 2010b). O recurso de aplicativos sociais foi adicionado no Orkut em 2008, fazendo uso da integração com o OpenSocial. O Google, proprietário do Orkut, faz uma análise de cada aplicativo que é submetido ao Orkut, bloqueando aplicativos que permitam vulnerabilidades no acesso aos dados dos usuários. (ORKUT, 2010a). Atualmente o Orkut já possui mais de 600 aplicativos (ZMOGINSKI, 2008). Os mais populares são apresentados, a seguir, no Quadro 1. Nome Usuários Descrição BuddyPoke 36.765.759 Permite criar personagens em 3 dimensões (3D). Colheita Feliz 21.615.882 Jogo em que o usuário deve cuidar da sua própria fazenda virtual. Mini Fazenda 16.289.082 Jogo em que, assim como o Colheita Feliz, o usuário deve cuidar da sua própria fazenda virtual. Minha Música 9.054.486 Permite colocar uma música no perfil do usuário. Segredos do Mar 4.887.038 Permite ao usuário criar o seu próprio oceano. Profile Posters 2.592.366 Permite adicionar um pôster no perfil do usuário. Biscoito da Sorte 2.079.996 Oferece mensagens diárias ao usuário. Vida nas Passarelas 2.042.605 Permite ao usuário disputar desfiles virtuais contra concorrentes. Baby Adopter 1.927.630 Permite ao usuário adotar e cuidar de um bebê. Resort Tropical 1.800.592 Permite ao usuário explorar uma ilha tropical. Quadro 1 - Aplicativos mais populares do Orkut Fonte: Orkut (2010c). 2.2 OPENSOCIAL O OpenSocial é uma plataforma que permite criar e implantar aplicativos sociais em múltiplas redes. Ele é o único que foi criado para o uso em múltiplas redes sociais (chamados de recipientes), e também tem o benefício de ser uma biblioteca de código aberto para o desenvolvimento de aplicações. O OpenSocial é, na verdade, concebido para facilitar a implantação de um único aplicativo em múltiplas redes sociais. Ele possui diferentes versões e nem todas as redes sociais
  • 19. 18 suportando o OpenSocial têm suporte a última versão. (GREWE, 2009, p. 55, tradução própria). Toda a documentação do OpenSocial é licenciado por meio da Creative Commons. Além disso, todos os códigos de exemplo da documentação são fornecidos sob a licença Apache 2.0. (OPENSOCIAL, 2010e). Nem todas as redes sociais permitem que organizações de terceiros ou indivíduos possam criar aplicações para redes sociais. Esse recurso realmente emergiu com a API do Facebook, que é o motivo pelo qual se vêem tantos aplicativos para o Facebook. O OpenSocial foi explicitamente criado para permitir aos desenvolvedores criarem aplicativos que pudessem ser implantados em múltiplas redes sociais (recipientes), ao contrário da API exclusiva do Facebook. (GREWE, 2009, p. 1, tradução própria). Atualmente, a tendência parece estar se voltando a aplicativos que não são destinados apenas a serem populares (ou virais), mas que também tenham uma retenção e uso por um longo prazo com interações mais complexas e por mais tempo. Aplicações envolvendo música e mídia, negócios e educação são exemplos desse modelo. (GREWE, 2009, p. 14, tradução própria). O lançamento público do OpenSocial ocorreu com a versão 0.5, em dezembro de 2007 (GREWE, 2009, p. 56, tradução própria). No Quadro 2 são mostradas as datas das publicações das especificações de cada versão. Versão Publicação 0.6 21 dez. 2007 0.7 25 jan. 2008 0.8 27 maio 2008 0.9 15 abr. 2009 1.0 9 mar. 2010 1.1 18 out. 2010 (rascunho) Quadro 2 - Datas das publicações das especificações do OpenSocial Fonte: Opensocial and Gadgets Specification Group (2010d). Os aplicativos do OpenSocial podem aparecer em três interfaces, também chamadas de visões, na página do usuário na rede social:
  • 20. 19  Visão "canvas": esta visão é definida como a "tela cheia" do aplicativo sendo executado. Claro que ela ainda estará dentro da interface da rede social, mas ocupará uma grande porcentagem da interface;  Visão "home": esta é a visão quando o aplicativo está sendo executado na interface principal/inicial que o usuário geralmente vê quando entra (faz o login) na rede social. Na maioria das vezes, ela será reduzida em tamanho quando comparada com a visão "canvas";  Visão "profile": esta é a visão quando o aplicativo está sendo executado na página do perfil do usuário. Assim como a visão "home", essa visão tipicamente ocupa uma porcentagem menor da página. (GREWE, 2009, p. 19, tradução própria). Cada recipiente difere na forma como controla o aplicativo. Essas políticas algumas vezes não são publicadas, e podem mudar com frequência. Por causa disso, os desenvolvedores devem continuamente educar-se nas mudanças de políticas de aplicativos de qualquer rede. (GREWE, 2009, p. 26, tradução própria). No Anexo A é apresentada uma lista de recipientes que implementam o OpenSocial e algumas informações sobre eles. Além dos recipientes apresentados no Anexo A, há outros que também implementam o OpenSocial, mas ainda não estão disponíveis ao público em geral ou estão em fase de testes, tais como o Plaxo Pulse, o Viadeo e o Lokalisten. (OPENSOCIAL, 2010a). 2.2.1 Diretório de Aplicativos Infelizmente, não há um local em que o desenvolvedor possa submeter o seu aplicativo para que ele possa ser usado por todas as redes sociais que fazem parte do OpenSocial. Cada recipiente possui o seu próprio diretório de aplicativos que podem ser instalados, ou seja, o desenvolvedor deve submeter o seu aplicativo separadamente para cada rede social. Além disso, cada rede tem os seus próprios critérios para aceitar um aplicativo. Uma lista extensa de aplicativos pode ser encontrada no endereço http://directory.opensocial.org/gadgets/directory. No entanto, a lista possui aplicativos que podem ser instalados apenas em algumas redes sociais.
  • 21. 20 2.2.2 Melhores Práticas De acordo com OpenSocial (2010g, tradução própria), existem algumas recomendações na construção de aplicativos sociais que os ajudam a se tornar atraentes:  Rápido engajamento: há uma tendência de o usuário experimentar um aplicativo desconhecido e rapidamente abandoná-lo caso não encontre nenhum valor de imediato. Para evitar que isso ocorra, é necessário que se deixe claro logo no início as intenções do aplicativo, e também que o aplicativo tenha conteúdo interessante (especialmente o conteúdo de amigos) e seja fácil de usar;  Aparência consistente: ajuda a manter a consistência do aplicativo se ele possuir uma aparência semelhante a do recipiente onde ele está hospedado;  Permitir auto-expressão: a página do perfil representa a identidade de um usuário, interesses e gostos. Do ponto de vista do proprietário, é um meio de auto-expressão e um ponto de partida para explorar o gráfico social. Do ponto de vista dos espectadores, é um lugar para aprender, comunicar e encontrar interesses comuns;  Dinamicidade: boas aplicações não são apenas um crachá estático, elas mudam dinamicamente para fornecer uma experiência interessante através das sessões;  Expor atividades dos amigos: uma maneira muito fácil de fazer uma aplicação dinâmica e social é registar e apresentar as atividades dos amigos que estão usando o aplicativo. A partir dessas atividades, os usuários se tornam mais conscientes de como os outros estão usando o aplicativo, levando a uma maior utilização;  Navegar pelo grafo de amigos: os usuários geralmente se interessam por interações que exigem pouco esforço, como ver as atividades mais recentes dos amigos e comparar conteúdos e escolhas;  Comunicação dirigida: em lugares onde a comunicação pode acontecer, é uma boa prática deixar essa opção explícita, como em um sistema de comentários;
  • 22. 21  Construir comunidades: ao aumentar as pequenas comunidades tornando-as acessíveis, um aplicativo pode fornecer uma funcionalidade rica e interessante que melhora a experiência global social;  Resolver problemas do mundo real: a plataforma OpenSocial pode ajudar a resolver tarefas do mundo real em que o grafo2 social auxilia na tomada de decisões, como marcar encontros, por exemplo. 2.2.3 Tecnologia e Ferramentas Envolvidas O OpenSocial foi desenvolvido sobre linguagens e especificações conhecidas por quem trabalha com aplicativos para a web, como JavaScript e HTML. Com isso, torna-se fácil para um desenvolvedor criar um aplicativo social. A seguir são apresentadas as linguagens, conceitos e ferramentas envolvidas no OpenSocial. 2.2.3.1 XML Segundo Grewe (2009, p. 64, tradução própria), o OpenSocial é construído sobre os chamados gadgets3 sociais, representados por arquivos XML. O XML é uma linguagem de marcação que consegue armazenar todo tipo de dados, descrevendo-os. Essa capacidade também é chamada de "self- describe data", ou dados autodescritivos e, por utilizar caracteres Unicode, pode armazenar qualquer tipo de caractere ou símbolo, fazendo a representação de informações em qualquer idioma ou cultura. (FARIA, 2005, p. 11). Um trecho exemplificando a linguagem de marcação XML é exibido, a seguir, no Quadro 3. No exemplo, é definido um elemento chamado cor, que por sua vez possui um atributo chamado nome no qual o valor é azul. ‒‒‒‒‒‒‒‒‒‒‒‒‒‒ 2 O grafo social é a base das redes sociais. Cada nó do grafo representa uma pessoa e as conexões entre os nós representam as relações entre elas. 3 Um gadget é um componente feito por desenvolvedores Google que dá aos usuários conteúdos interessantes e dinâmicos que podem ser colocados em qualquer página da web. (GREWE, 2009, p. 59, tradução própria).
  • 23. 22 1 <?xml version="1.0" encoding="UTF-8" ?> 2 <cor nome="azul" /> 3 </elemento> Quadro 3 - Exemplo da linguagem de marcação XML 2.2.3.2 HTML A linguagem de marcação HTML é usada para construir o conteúdo de um aplicativo social. Um exemplo é apresentado no Quadro 4. De acordo com Costa (2007, p. 9): O HTML, ou Hypertext Markup Language, é a linguagem padrão utilizada para o acesso e exibição de páginas Web. As linhas de código HTML são interpretadas pelo browser, que mostra o resultado final ao utilizador, sem necessidade de compilação. Genericamente, a linguagem HTML é constituída por textos e códigos especiais denominados marcas ou tags (os comandos da linguagem). 1 <html> 2 <head> 3 <title>Exemplo</title> 4 </head> 5 <body> 6 <p>Olá mundo!</p> 7 </body> 8 </html> Quadro 4 - Exemplo da linguagem de marcação HTML No Quadro 4, é criado um documento HTML, com um cabeçalho (elemento head) e com um corpo (elemento body). Dentro do cabeçalho é definido o título do documento (elemento title) e dentro do corpo é criado um parágrafo (elemento p). 2.2.3.3 JavaScript É a linguagem de programação JavaScript que trará o aspecto dinâmico a um aplicativo social, como, por exemplo, a busca dos dados do usuário de um aplicativo. Segundo Flanagam (2004, p. 19): JavaScript é uma linguagem de programação leve, interpretada e com recursos de orientação a objetos. [...] Sintaticamente, o núcleo da linguagem JavaScript assemelha-se às linguagens C, C++ e Java, contendo construções de programação com a instrução if, o laço while e o
  • 24. 23 operador &&. Entretanto, a similaridade acaba nessa semelhança sintática. JavaScript é uma linguagem não-tipada, ou seja, as variáveis não precisam ter um tipo especificado. Um exemplo da linguagem JavaScript pode ser visto no Quadro 5. 1 <script type="text/javascript"> 2 var texto = 'Olá mundo'; 3 alert(texto); 4 </script> Quadro 5 - Exemplo da linguagem JavaScript No exemplo mostrado no Quadro 5 uma variável chamada texto e o seu conteúdo é exibido como uma mensagem de alerta no navegador. 2.2.3.4 JSON A troca de dados entre o aplicativo e o servidor da rede social é feita usando o formato JSON (JavaScript Object Notation). (OPENSOCIAL, 2010g). O JSON é um formato de troca de dados que também serve para serializar objetos. Um objeto na memória pode ser transportado por qualquer meio até o seu destino. [...] Utilizamos o JSON para a troca de dados entre funções de APIs existentes na Web. [...] É uma alternativa muito utilizada como contrapartida ao XML na troca de mensagens entre o cliente e a API. (SAMPAIO, 2007, p. 115). Ainda segundo Sampaio (2007, p. 115), "um Objeto JSON é definido como um conjunto de nomes e valores separados por dois pontos e delimitados por vírgulas. Este conjunto de nomes/valores representa as propriedades do objeto sendo definido. O objeto todo fica delimitado por chaves". O Quadro 6 apresenta um exemplo de um objeto no formato JSON. 1 pessoa = { 2 nome : 'Clebersander Rech', 3 idade : 23 4 } Quadro 6 - Sintaxe básica de um objeto JSON No Quadro 6 o objeto chamado pessoa possui duas chaves: uma chamada nome e outra chamada idade. Logo após os dois pontos das chaves são definidos os seus valores.
  • 25. 24 2.2.3.5 REST Para que os clientes possam interagir com os servidores dos recipientes OpenSocial externamente aos gadgets, o OpenSocial define uma linguagem e plataforma neutros em relação a protocolos (OPENSOCIAL AND GADGETS SPECIFICATION GROUP, 2009, tradução própria). Ou seja, para a interação entre os servidores de terceiros e os servidores das redes sociais é utilizada a arquitetura REST, mediante um serviço web disponibilizado pelo servidor e acessado pelo cliente. Um serviço web que segue os principios desta arquitetura é denominado RESTful. No estilo arquitetônico REST, cada peça de informação é um recurso, e esses recursos são endereçados usando Uniform Resources Identifiers (URIs), tipicamente links na Web. Os recursos são postos em prática através de um conjunto de operações simples e bem definidas. O estilo da arquitetura REST cliente-servidor é desenhado para usar um protocolo de comunicação stateless (sem estado), tipicamente o HTTP. No REST, os clientes e os servidores trocam representações de recursos usando uma interface e um protocolo definidos. (GONÇALVES, 2009, p. 429). O protocolo opera principalmente em termos de recursos e operações sobre eles. Um serviço RESTful é definido sobre do protocolo HTTP e usa os métodos padrão HTTP (GET, POST, PUT, DELETE, HEAD e OPTIONS) para recuperar e mudar o estado do servidor. (OPENSOCIAL AND GADGETS SPECIFICATION GROUP, 2009, tradução própria). 2.2.3.6 OAuth Quando um aplicativo OpenSocial REST faz uma requisição para a rede social é necessário que esse aplicativo seja autenticado. Quando essas requisições também envolvem um usuário, a autenticação também é necessária (GREWE, 2009, p. 176, tradução própria). Para resolver a questão de autorização e autenticação, é utilizado o protocolo OAuth. O OAuth é um protocolo de autorização padrão aberto que permite que os administradores acessem dados básicos dos usuários sem acessar as contas dos usuários. Em vez de solicitar nomes de usuários e senhas aos usuários, o OAuth age como a "chave mestra" usando um token de usuário para permitir um acesso limitado aos dados. Os usuários podem revogar a chave mestra, caso necessário. (AJUDA DO GOOGLE APPS ADMINISTRADOR, 2010).
  • 26. 25 2.2.3.7 Apache Shindig Pode-se dizer que o OpenSocial também é uma especificação, que deve ser implementada pelos recipientes. Para facilitar a implementação do OpenSocial no servidor das redes sociais foi criado o projeto Shinding. Apache Shindig é um recipiente OpenSocial e ajuda a começar a hospedagem de aplicativos OpenSocial rapidamente, fornecendo o código para renderizar gadgets, requisições de proxy e manipular requisições REST e RPC. O objetivo do Apache Shindig é permitir que novos sites possam hospedar aplicativos sociais no menor tempo possível. O Apache Shindig é a implementação de referência das especificações da API OpenSocial. (SHINDIG, 2010, tradução própria). O Apache Shindig é composto de quatro partes (SHINDIG, 2010, tradução própria):  Recipiente JavaScript do Gadget: JavaScript fundamental para as funcionalidades gerais do gadget. Esse JavaScript gerencia segurança, comunicação, layout da interface do usuário e extensões de recursos, como a API do OpenSocial;  Servidor de Renderização de Gadget: usado para renderizar o XML do gadget em JavaScript e HTML, para que o mesmo possa ser exposto para o recipiente JavaScript;  Recipiente JavaScript do OpenSocial: ambiente JavaScript que fica no topo do Recipiente JavaScript do Gadget e oferece funcionalidades específicas do OpenSocial (perfis, amigos, atividades e armazenamento de dados);  Servidor de Dados do OpenSocial: uma implementação da interface do servidor para informações específicas do recipiente, incluíndo as APIs REST do OpenSocial, com pontos de extensão para que outros possam se conectar usando o seu próprio backend. O endereço do projeto Apache Shindig é http://shindig.apache.org.
  • 27. 26 2.2.3.8 OSDE O OSDE (OpenSocial Development Environment) é um plugin para o Eclipse IDE (Integrated Development Environment) usado para auxiliar no desenvolvimento e teste de aplicativos do OpenSocial. Segundo Cheng (2010, tradução própria), a versão 1.0 do OSDE foi lançada em 22 junho de 2010 e possui as seguintes características:  Um servidor Shindig embutido para teste local;  Um banco de dados integrado para armazenar e gerenciar dados sociais;  Assistentes (wizards) para a geração de projetos simples e código para o gadget;  Um editor multipainel da especificação do gagdet;  Uma perspectiva do Eclipse chamada "OpenSocial" que disponibiliza uma edição e depuração aprimorada de fácil acesso e controle do servidor Shindig local bem como do banco de dados social;  Um assistente para a gerar um projeto OpenSocial em Java, que terá códigos de exemplo usando a biblioteca Java do OpenSocial RESTful para a conexão ao servidor OpenSocial local;  Possibilidade de teste no servidor do iGoogle;  Análise de desempenho. O plugin OpenSocial Development Environment pode ser baixado no endereço http://code.google.com/p/opensocial-development-environment. 2.2.4 Arquitetura do OpenSocial A arquitetura do OpenSocial envolve o cliente (usando um navegador web) e o recipiente (rede social). Todas as redes sociais servem diretamente ao cliente. Por isso, qualquer requisição feita pelo cliente a um aplicativo social será intermediado pelo recipiente, que pode inclusive "filtrar" os resultados antes que eles sejam entregues ao cliente (GREWE, 2009, p. 57, tradução própria). A Figura 1 apresenta a arquitetura entre a rede social e o aplicativo. Nela, a rede social age como uma ponte entre os usuários e o aplicativo.
  • 28. 27 Figura 1 - Arquitetura entre a rede social e o aplicativo Fonte: Adaptado de Grewe (2009, p. 58, tradução própria). Com a versão 0.8 do OpenSocial, surgiram duas novas APIs OpenSocial:  API baseada no cliente: baseia-se na tecnologia JavaScript no lado do cliente. A API JavaScript do OpenSocial (às vezes simplesmente chamada de API OpenSocial) foi a primeira API surgida no lançamento inicial do OpenSocial. Ela envolve a realização de chamadas usando a API JavaScript do OpenSocial;  API baseada no servidor: nova desde o lançamento do OpenSocial 0.8 em 2008, a API para serviços RESTful permite aos desenvolvedores criar aplicativos com a sua própria tecnologia no lado do servidor, o que possibilita aos desenvolvedores escrever aplicativos hospedados em um servidor e fazer chamadas diretas ao recipiente. Os desenvolvedores podem escrever o aplicativo no lado do servidor em qualquer linguagem suportada pelo mesmo, como Java ou PHP (PHP: Hypertext Preprocessor). (GREWE, 2009, p. 58, tradução própria). 2.2.4.1 API Baseada no Cliente Nesse tipo de modelo, todo o aplicativo é desenvolvido usando XML, HTML e JavaScript. Em algumas redes sociais, tais como MySpace e iGoogle, é possível hospedar o aplicativo no recipiente. Os desenvolvedores de alguns aplicativos podem querer armazenar e recuperar dados do seu próprio aplicativo. Nesses casos, os desenvolvedores utilizam a persistência tal como definida na API JavaScript do OpenSocial. Os desenvolvedores podem querer também armazenar Rede Social Aplicativo da Rede Social
  • 29. 28 os dados no seu próprio banco de dados, ou talvez precisem de outros recursos ou serviços em seus servidores. Nesse modelo, os recursos (como serviços e programas do lado do servidor) são invocados para prestar suporte ao aplicativo. Deste modo, o tipo do aplicativo pode ser descrito como um aplicativo com suporte no lado do servidor. (GREWE, 2009, p. 58, tradução própria). 2.2.4.2 API Baseada no Servidor A API no lado do servidor é disponibilizada em três versões: para aplicativos de uma rede não-social, para aplicativos de uma rede social e para aplicativos híbridos. Alguns aplicativos OpenSocial RESTful no lado do servidor não são gadgets e não são implantados no recipiente, mas usam dados sociais. Ao invés de usar a API JavaScript do OpenSocial, esses aplicativos utilizam a API RESTful do OpenSocial, que possibilita a um programa no lado do servidor obter dados sociais direto da rede social, bem como também enviar dados para a rede social (GREWE, 2009, p. 59, tradução própria). Esse tipo de arquitetura pode ser visto na Figura 2. Figura 2 - Arquitetura de um aplicativo social completamente baseado no servidor Fonte: Adaptado de Grewe (2009, p. 61, tradução própria). Na Figura 2 o servidor onde está o aplicativo cliente requisita os dados ao servidor da rede social através da API RESTful. Desta maneira, o aplicativo não fica hospedado no recipiente da rede social. Rede Social Servidor de Aplicação OpenSocial RESTful Cliente
  • 30. 29 2.2.5 Arquitetura de um Aplicativo Um aplicativo de rede social baseado na API JavaScript do OpenSocial pode ser visto com um objeto em camadas, como mostra a Figura 3. Uma camada externa especifíca o aplicativo como um gadget Google usando XML. O conteúdo interno é o conteúdo do aplicativo, e consiste tipicamente de HTML, JavaScript, CSS (Cascading Style Sheet) e outro conteúdo. No caso do desenvolver não querer colocar o conteúdo diretamente no gadget, ele pode fazer referência a um conteúdo localizado fora do gadget, como uma página HTML em outro servidor ou um arquivo no formato Flash. Os aplicativos baseados no cliente utilizam a API JavaScript do OpenSocial para fazer consultas ao recipiente de uma maneira assíncrona para a maioria das chamadas. A maioria dos métodos do OpenSocial não retornam diretamente dados. Ao invés, o aplicativo deve requisitar o dado, e então, algum tempo depois, o recipiente retornará os resultados para uma função callback no aplicativo. (GREWE, 2009, p. 63, tradução própria). Na Figura 3 é representada a comunicação assíncrona entre o gadget (aplicativo do OpenSocial) e o recipiente (rede social). Figura 3 - Camadas de um aplicativo OpenSocial e comunicações assíncronas com o recipiente Fonte: Adaptado de Grewe (2009, p. 63, tradução própria). O objeto retornado como resposta de uma requisição é uma instância de opensocial.DataResponse. Um único objeto DataRequest pode ter múltiplos objetos de requisição adicionados a ele. Um aplicativo pode fazer várias requisições durante a sessão com o usuário, mas também pode escolher agrupá-las de uma só Aplicativo OpenSocial Gadget XML Conteúdo HTML Recipiente OpenSocial Dados Dados Comunicação Assíncrona
  • 31. 30 vez (para aumentar o desempenho). Uma requisição pode obter o nome do usuário ou a lista de amigos do usuário, por exemplo. A classe para fazer as requisições é opensocial.DataRequest. (Todas as classes e métodos na API JavaScript do OpenSocial iniciam com o namespace4 opensocial). O aplicativo então envia a requisição utilizando o método send da classe DataRequest. (GREWE, 2009, p. 63, tradução própria). 2.2.6 Aplicativo de Exemplo O OpenSocial é construído sobre o que o Google chama de gadgets sociais, que são representados por arquivos XML. (GREWE, 2009, p. 64, tradução própria). O Quadro 7 mostra o código-fonte de um aplicativo de exemplo do OpenSocial. 1 <?xml version="1.0" encoding="UTF-8" ?> 2 <Module> 3 <ModulePrefs title="Olá Mundo!"> 4 <Require feature="opensocial-0.8" /> 5 </ModulePrefs> 6 <Content type="html"> 7 <![CDATA[ 8 Olá Mundo! 9 ]]> 10 </Content> 11 </Module> Quadro 7 - Aplicativo de exemplo do OpenSocial A linha 1 do Quadro 7 indica o conteúdo do arquivo como sendo XML. A linha 2 declara um gadget. Já na linha 3 o elemento ModulePrefs define as informações do gadget, sendo que dentro deste elemento tem-se outro elemento indicando o uso da versão 0.8 da API OpenSocial. Na linha 6 é indicado que o gadget será exibido como HTML. E por fim, na linha 7, é inserido o conteúdo do gadget, que pode incluir HTML, CSS e JavaScript. Toda essa estrutura XML é utilizada para definir o aplicativo como um gadget. ‒‒‒‒‒‒‒‒‒‒‒‒‒‒ 4 Um namespace fornece desambiguação para itens que possuem o mesmo nome mas que residem em namespaces diferentes.
  • 32. 31 3 APLICATIVOS DO OPENSOCIAL Um aplicativo do OpenSocial é definido em um arquivo XML, também chamado de gadget. Esse arquivo XML segue a especificação Google Gadget XML. Dentro deste gadget é usada a API JavaScript do OpenSocial. Um aplicativo social pode então ser descrito com um gadget, que por sua vez pode ser descrito como um arquivo XML. Deve-se levar em conta que todo aplicativo social do OpenSocial é um gadget, mas nem todo gadget será um aplicativo social. Ele só será chamado assim quando fizer uso dos dados do usuário e dos seus amigos. "Gadgets são aplicativos simples em HTML e JavaScript que podem ser incorporados em páginas da web e em outros aplicativos. [...] Seu gadget pode ser executado em diversos sites, incluindo o iGoogle, Google Maps, Orkut ou em qualquer página da web. Escreva seu gadget somente uma vez e faça pequenas alterações para executá-lo em diversos locais." (API DE GADGETS, 2010a). 3.1 GADGET XML Um gadget XML consiste, basicamente, de alguns blocos estruturais simples: XML, HTML e JavaScript. O XML é uma linguagem de marcação de uso geral. Ela é usada para especificar a programação de um gadget e contém instruções sobre como processar e exibir o mesmo. Esse arquivo XML pode conter todos os dados e códigos do gadget ou indicar um local externo onde o restante dos elementos estão. O HTML é uma linguagem de marcação usada para descrever o conteúdo de uma página na web, bem como o conteúdo estático de um gadget. Já a linguagem JavaScript é usada para adicionar comportamento dinâmico ao gadget. (API DE GADGETS, 2010d). Um gadget XML é composto de três partes principais:  Seção de conteúdo: representada pela tag Content, é a parte mais importante. Nela é colocada toda a lógica de programação. É está a parte do gadget que será vista pelo usuário;
  • 33. 32  Preferências do usuário: representada pela tag UserPrefs, permite que sejam definidas configurações para o gadget pelo usuário. Esta tag é opcional;  Preferências do gadget: representada pela tag ModulePrefs, define as informações do gadget, como título, autor, tamanho preferido entre outros. É nesta tag que é definida a versão da API JavaScript do OpenSocial que será usada. (API DE GADGETS, 2010d). O Quadro 8 apresenta o código de um exemplo de gadget, sendo que a seção de preferências do gadget (ModulePrefs) é destacada em vermelho e a seção de conteúdo (Content) em azul. 1 <?xml version="1.0" encoding="UTF-8" ?> 2 <Module> 3 <ModulePrefs title="Olá Mundo!"> 4 <Require feature="opensocial-0.8" /> 5 </ModulePrefs> 6 <Content type="html"> 7 <![CDATA[ 8 Olá Mundo! 9 ]]> 10 </Content> 11 </Module> Quadro 8 - Aplicativo de exemplo do OpenSocial com destaque de cores das seções No Quadro 9 são apresentados os atributos da seção ModulePrefs que são suportados em todos os recipientes. Atributo Descrição title String opcional que fornece o título do gadget. Esse título é exibido na barra de título do gadget. title_url String opcional que fornece uma URL (Uniform Resource Locator) ao qual o título do gadget está vinculado. Por exemplo, é possível vincular o título a uma página web relacionada ao gadget. description String opcional que descreve o gadget. author String opcional que relaciona o autor do gadget. author_email String opcional que fornece o endereço de e-mail do autor do gadget.
  • 34. 33 Atributo Descrição screenshot String opcional que fornece a URL de uma captura de tela do gadget. O formato preferencial é PNG (Portable Network Graphics), mas GIF (Graphics Interchange Format) e JPG (Joint Photographic Experts Group) também são aceitáveis. As capturas de tela de gadget devem ter 280 pixels de largura. A altura da captura de tela deve ser a altura "natural" do gadget quando está sendo usado. thumbnail String opcional que fornece o URL de uma miniatura do gadget. O formato preferencial é PNG, mas GIF e JPG também são aceitáveis. As miniaturas do gadget devem ter 120 x 60 pixels. Quadro 9 - Atributos da seção ModulePrefs Fonte: API de Gadgets (2010e). Na seção ModulePrefs também podem ser aninhados outros elementos, conforme pode ser visto no Quadro 10. Elemento Descrição Require Declara a dependência de um recurso do gadget. Feature Declara a dependência de um recurso do gadget. Preload Instrui o recipiente a buscar dados de uma origem remota durante o processo de renderização do gadget. Icon Especifica uma imagem de 16 x 16 pixels que os recipientes podem associar a um gadget específico. Locale Especifica os locais (idiomas) suportados pelo gadget. Link Um link específico do recipiente. Quadro 10 - Elementos opcionais da seção ModulePrefs Fonte: API de Gadgets (2010e). Na seção Content, o atributo type aceita os valores html (padrão) ou url. O atributo com valor html indica que o gadget armazena o conteúdo propriamente dito. Caso o atributo tenha o valor url, significa que o conteúdo do gadget será carregado de um arquivo externo, cujo caminho será definido no atributo href. O Quadro 11 apresenta os atributos possíveis da seção Content. Atributo Descrição type String opcional que fornece o tipo do conteúdo. Os valores possíveis são html e url. O padrão é html. href String que fornece um URL de destino. Pode se aplicar a um type="url" gadget ou conteúdo com proxy.
  • 35. 34 Atributo Descrição view String opcional. Somente gadgets OpenSocial. Indica em qual visualização do recipiente OpenSocial o conteúdo deve ser exibido. Um gadget OpenSocial pode definir várias seções de conteúdo, cada uma delas aplicável a visualizações diferentes. preferred_height A altura inicial do gadget, em pixels. preferred_width A largura inicial do gadget, em pixels. Quadro 11 - Atributos da seção Content Fonte: API de Gadgets (2010e). Segundo a especificação do OpenSocial, um aplicativo sendo executado em um recipiente deve ser sempre exibido dentro de um elemento iframe. (OPENSOCIAL AND GADGETS SPECIFICATION GROUP, 2010c, tradução própria). O elemento iframe, que faz parte da linguagem HTML, permite que um site seja exibido dentro do outro. Quando um usuário está visualizando um aplicativo em uma rede social qualquer, o aplicativo na verdade não está na página da web em que ele está navegando. O aplicativo está em outro local, mas é inserido na página usando o iframe. Um dos benefícios da utilização desse elemento é que ele isola o aplicativo do resto da página da rede social, evitando que o mau comportamento do aplicativo possa afetar o resto do site, ou até mesmo colocar em risco a segurança do usuário. 3.2 API DE GADGETS Quando um recipiente suporta o OpenSocial, ele também suporta a API (JavaScript) de gadgets. Todos os objetos na API de gadgets iniciam com o namespace gadgets. A API é formada pela API principal e pelas APIs específicas do recurso. (GREWE, 2009, p. 95, tradução própria). A API principal estará sempre disponível para o gadget. Já para utilizar as APIs específicas do recurso, é necessário especificar quais delas devem ser disponibilizadas para o gadget. Isso é declarado na seção de preferências do gadget (ModulePrefs).
  • 36. 35 Para cada recurso específico que se deseja utilizar, é adicionado um elemento Require, com o atributo feature indicando o nome da API. Na linha 4 do Quadro 8 é exibido o seguinte trecho de código: <Require feature="opensocial-0.8" /> Esta declaração instrui o recipiente onde o gadget está hospedado a incluir a versão 0.8 da API JavaScript do OpenSocial. Com isso, o gadget terá acesso a todas as funcionalidades disponibilizadas pela API incluída. As APIs específicas dos recursos são mostradas no Quadro 12, a seguir. No Anexo B são apresentadas as classes da API de gadgets. Biblioteca de recursos Descrição setprefs Define o valor de uma preferência do usuário de modo programático. dynamic-height Permite que o gadget seja redimensionado automaticamente. settitle Define o título do gadget de modo programático. tabs Adiciona uma interface com abas ao gadget. Minimessage Exibe uma mensagem temporária e descartável em um gadget. Flash Incorpora um filme em Flash (especificamente, um arquivo .swf (Shockwave Flash)) em um gadget. locked-domain A biblioteca locked-domain isola os gadgets de outros gadgets em execução na mesma página. Quadro 12 - APIs específicas dos recursos Fonte: API de Gadgets (2010e). 3.2.1 Internacionalização Quem cria um aplicativo, ainda mais social, quer que o mesmo seja acessado pelo maior número de pessoas, e para isso, o idioma não deve ser uma barreira. Para atingir um público maior para o seu aplicativo, o desenvolvedor pode fazer uso do recurso de internacionalização do OpenSocial. Segundo API de Gadgets, 2010e: A API de gadgets oferece uma maneira fácil de você disponibilizar seu gadget para um público internacional. É simples: basta estruturar o gadget de forma que o texto visível para o usuário (qualquer texto que será traduzido) esteja em pacotes de mensagens separados do gadget. Assim, qualquer tradutor de terceiros pode traduzir suas strings e criar novos
  • 37. 36 pacotes de mensagens específicos ao local, os quais você pode adicionar à especificação do seu gadget. Dessa forma, seu gadget fica disponível para um novo grupo de usuários. 3.2.1.1 Pacotes de Mensagens Os gadgets fazem uso de pacotes de mensagens para internacionalizar um aplicativo. Um pacote de mensagem é nada mais do que um arquivo XML. Dentro desse arquivo estarão as strings traduzidas, associadas a um nome único. Cada pacote de mensagem é associado a apenas um idioma e local. Um exemplo de pacote de mensagem pode ser visto no Quadro 13. 1 <messagebundle> 2 <msg name="hello_world">Olá mundo</msg> 3 <msg name="name">Nome</msg> 4 <msg name="city">Cidade</msg> 5 </messagebundle> Quadro 13 - Pacote de mensagem Como visto no Quadro 13, para cada elemento msg, será associado um atributo name com o identificador único da string, e dentro do elemento a string traduzida. Por exemplo, a string traduzida do elemento msg com o atributo name com valor hello_world é Olá mundo. O nome do arquivo do pacote deve seguir a seguinte convenção: <idioma>_<PAIS>.xml Um pacote de linguagem do idioma português do Brasil terá o nome pt_BR.xml. O país pode ser ignorado, substituíndo o código do país por ALL. Por exemplo, um pacote do idioma português, tanto do Brasil quanto de qualquer país de língua portuguesa, terá o nome pt_ALL.xml. Por padrão, o pacote de mensagens usado é o arquivo ALL_ALL.xml. As melhores práticas recomendam sempre ter um pacote de mensagens com esse nome ao lidar com mensagens padrão. (API DE GADGETS, 2010c). Para indicar ao gadgets os idiomas disponíveis, deve-se declarar na seção de preferências do mesmo os arquivos correspondentes a cada idioma, usando o elemento Locale. Nesse elemento, o atributo lang indica o código do idioma e o
  • 38. 37 atributo messages indica a URL do arquivo do pacote de mensagens. O atributo country também pode ser usado para definir o código do país do pacote. Como pode ser visto no exemplo do Quadro 14. 1 <ModulePrefs title="Olá Mundo"> 2 <Locale messages="http://exemplo.com/ALL_ALL.xml" /> 3 <Locale lang="pt" messages="http://exemplo.com/pt_ALL.xml" /> 4 <Locale lang="pt" country="BR" messages="http://exemplo.com/pt_BR.xml" /> 5 <Locale lang="en" messages="http://exemplo.com/en_ALL.xml" /> 6 </ModulePrefs> Quadro 14 - Definindo os idiomas de um gadget 3.2.1.2 Acessando o Pacote de Mensagens Para fazer referência a uma mensagem no conteúdo HTML do gagdet a seguinte convenção deve ser usada: __MSG_<nome>__ Por exemplo, ao invés de no conteúdo do gadget ser colocado: <b>Olá mundo</b> Usando a mensagem internacionalizada o conteúdo fica assim: <b>__MSG_hello__world__</b> As mensagens também podem ser acessadas via a API JavaScript, usando a função getMsg do objeto gadgets.Prefs, como pode ser visto no exemplo do Quadro 15. 1 var prefs = new gadgets.Prefs(); 2 var mensagem = prefs.getMsg('hello_world'); Quadro 15 - Acessando um pacote de mensagens via a API JavaScript Na versão 0.9 da API JavaScript foram adicionadas outras funções para auxiliar na internacionalização e localização de um aplicativo. Com essas novas funções é possível converter datas e horas bem como números. (OPENSOCIAL, 2010b, tradução própria). Para fazer uso dessas novas funções é necessário
  • 39. 38 adicionar o elemento <Require feature="opensocial-i18n" /> na seção de preferências do gadget. As funções JavaScript se encontram no objeto gadgets.i18n. 3.3 API JAVASCRIPT DO OPENSOCIAL A API JavaScript disponibilizada pelo OpenSocial permite o acesso aos dados do usuário do aplicativo (gadget) e aos dados dos amigos do usuário. Permite também o compartilhamento desses dados e a criação de atividades. A API é dividida em três áreas principais:  Pessoas e relacionamentos: os usuários de um aplicativo geralmente possuem amigos;  Atividades: uma atividade é uma forma de notificar outros usuários sobre as ações do usuário do aplicativo;  Persistência: recurso que permite aos aplicativos armazenar dados e recuperá-los posteriormente. Muitas chamadas as funções da API do OpenSocial são assíncronas, isto é, elas não retornam os dados imediatamente quando invocadas. Ao invés disso, é criada uma solicitação no servidor do recipiente para retornar ou atualizar informações. Sendo assim, ao se invocar uma chamada da API, deve-se passar uma função de retorno de chamada (callback). Quando a solicitação no servidor estiver pronta, essa função de retorno será invocada. (OPENSOCIAL, 2010d). 3.3.1 OSAPI A especificação 0.9 do OpenSocial introduziu uma nova API JavaScript, chamada de OSAPI, que torna a requisição de dados e sua análise mais fáceis. Para manter a compatibilidade com a outra API JavaScript, essa nova API está disponível no namespace osapi. (OPENSOCIAL AND GADGETS SPECIFICATION GROUP, 2010d, tradução própria). Para usar essa nova API, deve-se requisitá-la ao recipiente, adicionando o código abaixo nas preferências do gadget:
  • 40. 39 <Require feature="osapi"> Os exemplos em JavaScript serão apresentados usando a API JavaScript tradicional e a OSAPI. Até a versão 0.9 do OpenSocial a API JavaScript tradicional era a única disponível, por tanto a maioria dos gadgets ainda a usam. No entanto, de acordo com o rascunho da versão 1.1 do OpenSocial (OPENSOCIAL AND GADGETS SPECIFICATION GROUP, 2010b, tradução própria), a API JavaScript tradicional será depreciada em favor da OSAPI. 3.3.2 Pessoas Conforme definido pela documentação da API (OPENSOCIAL, 2010d), existem três tipos de pessoas no OpenSocial:  Viewer (Visualizador): o usuário conectado no navegador, ou seja, quem está vendo o aplicativo;  Owner (Proprietário): o usuário a quem o perfil ou aplicativo em questão pertence;  Friends (Amigos): os usuários que o proprietário ou visualizador adicionou como amigos no recipiente. Como mencionado anteriormente, todas as classes e funções da API JavaScript iniciam com o namespace opensocial. Um usuário e os seus amigos, por exemplo, são representados como objetos do tipo opensocial.Person. A classe opensocial.Person, que representa uma pessoa, possui as funções apresentadas no Quadro 16. Resumo da função Detalhes da função String getDisplayName() Obtém um nome de exibição de texto desta pessoa; seguramente retorna uma string útil. String getField(chave, parametros_opcionais) Obtém os dados para esta pessoa, associados à chave especificada. As chaves estão definidas em opensocial.Person.Field. String getId() Obtém um ID que pode ser associado a esta pessoa permanentemente.
  • 41. 40 Resumo da função Detalhes da função Boolean isOwner() Retorna true (verdadeiro) se este objeto de pessoa representar o proprietário da página atual. Boolean isViewer() Retorna true (verdadeiro) se este objeto de pessoa representar o usuário conectado no momento. Quadro 16 - Funções da classe opensocial.Person Fonte: OpenSocial (2010g). Para recuperar uma informação específica de um objeto do tipo opensocial.Person, é utilizado a função getField, em que é passado um parâmetro do tipo opensocial.Person.Field, indicando qual informação deseja- se recuperar. No exemplo abaixo, é mostrado como se obter o campo idade de um objeto representando uma pessoa: var idade = pessoa.getField(opensocial.Person.Field.AGE); No Quadro 17 são mostrados os principais campos que uma pessoa pode apresentar. Campo Descrição ABOUT_ME Uma declaração geral sobre a pessoa, especificada como uma string. ADDRESSES Endereços associados à pessoa, especificados como uma matriz de Endereços. AGE A idade da pessoa, especificada como um número. CURRENT_LOCATION Localização atual da pessoa, especificada como um Endereço. DATE_OF_BIRTH Data de nascimento da pessoa, especificada como um objeto de Data. EMAILS Endereços de e-mail associados à pessoa, especificados como uma matriz de E-mails. GENDER O sexo da pessoa, especificado como um valor opensocial.Enum com a chave da propriedade enum fazendo referência ao valor opensocial.Enum.Gender. HAS_APP Um valor booleano indicando se a pessoa possui instalado o aplicativo atual. ID Um ID de string que pode ser associado a esta pessoa permanentemente. LANGUAGES_SPOKEN Lista dos idiomas que a pessoa fala, como códigos ISO 639-1, especificados como uma matriz de strings. NAME Um objeto opensocial.Name contendo o nome da pessoa.
  • 42. 41 Campo Descrição NICKNAME Uma string representando o apelido da pessoa. PHONE_NUMBERS Telefones associados à pessoa, especificados como uma matriz de Telefones. STATUS O status, frase escolhida ou saudação da pessoa, especificada como uma string. THUMBNAIL_URL O URL da miniatura da foto da pessoa, especificado como uma string. Quadro 17 - Principais campos do objeto opensocial.Person.Field Fonte: OpenSocial (2010g). A lista completa dos campos podem ser consultados na documentação da API JavaScript em OpenSocial (2010g). Deve-se salientar que os campos disponíveis variam de rede social para rede social, e cada rede pode criar os seus próprios campos. Na rede social Orkut, por exemplo, esses dados não são fornecidos por padrão. Segundo Orkut (2010d): Para que um aplicativo acesse os dados do perfil de um usuário, o usuário deve ter acesso garantido ao aplicativo, instalando-o em seu perfil. O orkut não compartilhará PII (Informações pessoais identificáveis) com os aplicativos. Os aplicativos não terão acesso a números de telefone, endereços de e-mail, aniversários e endereços físicos dos usuários do orkut. Os dados disponibilizados para os aplicativos serão apenas os dados que os usuários marcarem como disponíveis para "todos". Os dados restritos a amigos ou amigos de amigos não ficarão disponíveis para os aplicativos. Portanto, o desenvolvedor de um aplicativo social deve estar atento a esses detalhes. Deve-se ter em mente que nem sempre os dados que seu aplicativo necessita estarão disponíveis, além de que eles podem variar conforme o recipiente do aplicativo. No Quadro 18 são apresentados alguns campos do perfil de uma pessoa e a sua política de acesso no Orkut, sendo que os campos marcados como “Informações pessoais identificáveis” não estarão disponíveis para o aplicativo. Campo do Orkut Campo do OpenSocial Política de acesso do Orkut Nome NAME (GIVEN_NAME) Disponível Sobrenome NAME (FAMILY_NAME) Disponível Sexo GENDER Disponível
  • 43. 42 Campo do Orkut Campo do OpenSocial Política de acesso do Orkut Data de nascimento DATE_OF_BIRTH Informações pessoais identificáveis Cidade, Estado, País CURRENT_LOCATION e ADDRESSES Disponível CEP CURRENT_LOCATION e ADDRESS Informações pessoais identificáveis E-mail principal EMAILS Informações pessoais identificáveis Telefone residencial PHONE_NUMBERS Informações pessoais identificáveis Endereço ADDRESS Informações pessoais identificáveis Quadro 18 - Política de acesso de alguns campos dos perfis do Orkut Fonte: Orkut (2010d). 3.3.3 Requisições O Quadro 19 mostra uma função JavaScript que utiliza a API do OpenSocial para requisitar ao recipiente a lista de amigos do dono do aplicativo, bem como os dados do próprio dono. O Quadro 20 mostra a mesma função usando a OSAPI. 1 function requisicao() { 2 var idspec = opensocial.newIdSpec({ 'userId' : 'OWNER', 'groupId' : 'FRIENDS' }); 3 var req = opensocial.newDataRequest(); 4 req.add(req.newFetchPersonRequest('OWNER'), 'dono'); 5 req.add(req.newFetchPeopleRequest(idspec), 'amigos'); 6 req.send(resposta); 7 }; Quadro 19 - Função para requisitar a lista de amigos do dono do aplicativo 1 function requisicao() { 2 osapi.people.getViewerFriends(resposta); 3 }; Quadro 20 - Função para requisitar a lista de amigos do dono do aplicativo usando a OSAPI Na linha 2 do Quadro 19, é criado um objeto do tipo opensocial.Idspec. Este objeto vai indicar a requisição que será criada e quais os dados que serão retornados. Neste caso serão retornados os dados do dono do aplicativo e os seus amigos.
  • 44. 43 Caso se queira requisitar os dados do visualizador do aplicativo, seria necessário criar o mesmo objeto da seguinte forma: var idspec = opensocial.newIdSpec({ 'userId' : 'VIEWER', 'groupId' : 'FRIENDS' }); No construtor do objeto opensocial.IdSpec foram passadas as strings literais 'OWNER' e 'FRIENDS'. Pode-se também optar por usar as propriedades enums5 fornecidas pela API. Por exemplo, a linha 2 do Quadro 19 poderia ser reescrita da seguinte forma: var idspec = opensocial.newIdSpec({ 'userId' : opensocial.IdSpec.PersonId.OWNER, 'groupId' : 'FRIENDS' }); Nos quadros aqui apresentados são usados os valores literais, tornando o código-fonte mais legível. Na linha 3 do Quadro 19 é criado um objeto do tipo opensocial.DataRequest. Esse objeto é muito importante para o aplicativo. É ele que representa uma requisição ao recipiente. Nele podem ser adicionados vários itens de requisição. Aliás, é aconselhável agrupar várias dessas requisições em um único objeto, de forma a aumentar o desempenho do aplicativo. Cada um dos itens adicionados à requisição é executado na ordem em que foi adicionado, ou seja, o primeiro item adicionado será executado por primeiro pelo recipiente que recebeu o pedido de requisição. Os itens que não podem ser executados juntos são executados paralelamente. (OPENSOCIAL, 2010g). Com o objeto que fará a requisição criado, indica-se o que se deve retornar. Para isso, na linha 4 do Quadro 19, é criado e adicionado na requisição um objeto newFetchPersonRequest. Na criação desse objeto é passada a string 'OWNER'como parâmetro. Isso instrui a requisição a retornar os dados do dono do aplicativo. Já o segundo parâmetro do construtor do objeto será usado para mapear os dados de resposta gerados. Na linha 5 do Quadro 19 é criado e adicionado na requisição um objeto newFetchPeopleRequest, passando como parâmetro ao construtor o objeto do ‒‒‒‒‒‒‒‒‒‒‒‒‒‒ 5 Enum é um tipo distinto que consiste em um conjunto de constantes nomeadas.
  • 45. 44 tipo opensocial.Idspec, que havia sido criado na linha 2. Isso instrui o recipiente a retornar uma coleção de objetos representando os amigos do dono do aplicativo. Finalmente, na linha 6 do Quadro 19, é enviada a solicitação de dados ao servidor usando a função send do objeto opensocial.DataRequest. Como parâmetro dessa função é passada outra função: resposta. A função resposta será chamada pelo recipiente quando a requisição for processada e retornada para o aplicativo. Como dito anteriormente, esta é a função de retorno de chamada (callback). No Quadro 21 é apresentada a função que irá processar os dados recebidos do recipiente pelo aplicativo, após o término da requisição. 1 function resposta(dadosResposta) { 2 if (dadosResposta.hadError()) { 3 document.write(dadosResposta.getErrorMessage()); 4 } else { 5 var dono = dadosResposta.get('dono').getData(); 6 var amigos = dadosResposta.get('amigos').getData(); 7 var html = 'Amigos de ' + dono.getDisplayName(); 8 html += ':<br><ul>'; 9 amigos.each(function(pessoa) { 10 html += '<li>' + pessoa.getDisplayName() + '</li>'; 11 }); 12 html += '</ul>'; 13 document.write(html); 14 } 15 } Quadro 21 - Função para processar o retorno da requisição da lista de amigos A função de retorno de chamada receberá como parâmetro um objeto do tipo opensocial.DataResponse, como pode ser visto na linha 1 do Quadro 21. Esse objeto conterá os dados solicitados ao recipiente. Primeiro deve ser verificado se a reposta retornou algum erro (linha 2). Em caso afirmativo, é exibida a mensagem do erro (linha 3). Nas linhas 5 e 6 do Quadro 21 são recuperados os objetos que representam o dono do aplicativo e os seus amigos. Como pode ser observado, o parâmetro passado à função get é o mesmo que havia sido passado a função add na linhas 4 e 5 do Quadro 19. Tendo os objetos recuperados, agora basta formatar a sua exibição no aplicativo. É utilizada a função getDisplayName dos objetos que representam as
  • 46. 45 pessoas para criar uma lista em HTML com o nome de exibição das pessoas, que por último é escrita na tela (linha 13). Uma visão completa do exemplo mostrado nas listagens anteriores pode ser vista no Quadro 22. 1 <?xml version="1.0" encoding="UTF-8" ?> 2 <Module> 3 <ModulePrefs title="Listar amigos"> 4 <Require feature="opensocial-0.8" /> 5 </ModulePrefs> 6 <Content type="html"> 7 <![CDATA[ 8 <script type="text/javascript"> 9 function requisicao() { 10 /* Ver o Quadro 19 */ 11 }; 12 13 function resposta(dadosResposta) { 14 /* Ver o Quadro 21 */ 15 } 16 17 gadgets.util.registerOnLoadHandler(requisicao); 18 </script> 19 ]]> 20 </Content> 21 </Module> Quadro 22 - Listando os amigos do dono de um aplicativo Como pode ser visto no Quadro 22, para que a função requisicao seja executada assim que o aplicativo for carregado, é utilizada a função gadgets.util.registerOnLoadHandler (linha 17), pertencente a API de gadgets. Em resumo, um aplicativo que requisita informações sobre alguma pessoa deve seguir os seguintes passos:  Criar um objeto opensocial.DataRequest (representando um requisição) usando a função opensocial.newDataRequest;  Criar os itens que serão adicionados a requisição usando as funções opensocial.new...;  Para cada item criado, adicionar a requisição através da função add do objeto opensocial.DataRequest;
  • 47. 46  Chamar a função send do objeto opensocial.DataRequest, passando uma função de retorno de chamada (callback);  Criar a função de retorno de chamada (callback) que irá receber como parâmetro um objeto do tipo opensocial.DataResponse, contendo os dados com a resposta da requisição. 3.3.4 Atividades Uma atividade em uma rede social pode ser definida como uma forma de comunicação ou como o compartilhamento de informação. A criação de atividades é uma ótima maneira de divulgar um aplicativo. O OpenSocial fornece ao desenvolvedor a capacidade de requisitar a criação dessas atividades através da sua API. (GREWE, 2009, p. 130, tradução própria). No OpenSocial atividades podem incluir:  Envio direto de e-mail aos usuários;  Notificações;  Atualizações do usuário (e também atualizações dos amigos);  Requisições para instalar um aplicativo (convites). Os recipientes podem controlar o limite de atividades que um aplicativo pode criar. O Orkut, por exemplo, define que o aplicativos ficarão restritos à criação de três atualizações do fluxo de atividades por aplicativo, por dia, para cada usuário. (ORKUT, 2010d). Como o limite de atividades pode variar de rede social para rede social, é importante ao desenvolvedor consultar a documentação de cada rede. 3.3.4.1 Mensagens de E-mail e Notificações Os seguintes passos são necessários para a criação de uma mensagem:  Criar o objeto representando a mensagem, usando a função opensocial.newMessage, passando como parâmetros o corpo (texto) da mensagem e outros campos da mensagem;
  • 48. 47  Chamar a função opensocial.requestSendMessage passando como parâmetros o destinatário da mensagem e a mensagem propriamente dita. Há vários tipos de mensagens que podem ser criadas. O tipo da mensagem é passado como parâmetro na construção do objeto da mensagem. O Quadro 23 lista os tipos de mensagens que podem ser criados. Campo Descrição EMAIL Um e-mail. NOTIFICATION Uma mensagem privada curta. PRIVATE_MESSAGE Uma mensagem enviada a um usuário específico, que pode ser vista somente por esse usuário. PUBLIC_MESSAGE Uma mensagem enviada a um usuário específico, que pode ser vista por outras pessoas além desse usuário. Quadro 23 - Principais campos do objeto opensocial.Message.Field.Type Fonte: OpenSocial (2010g). Na construção do objeto da mensagem também podem ser passados os campos que formarão a mensagem. Esses campos são apresentados no Quadro 24. Campo Descrição BODY O texto principal da mensagem. Atributos HTML são permitidos e limpos pelo recipiente. BODY_ID O texto principal da mensagem como um modelo de mensagem. Especifica o ID de mensagem que será usado no código XML do gadget. TITLE O título da mensagem. Atributos HTML são permitidos e limpos pelo recipiente. TITLE_ID O título da mensagem como um modelo de mensagem. Especifica o ID de mensagem que será usado no código XML do gadget. TYPE O título da mensagem, especificado como um opensocial.Message.Type. Quadro 24 - Principais campos do objeto opensocial.Message.Field Fonte: OpenSocial (2010g). O Quadro 25 exemplifica a criação de uma mensagem de e-mail, que será enviada para o usuário que está visualizando o aplicativo. O Quadro 26 faz o mesmo, porém, usando a OSAPI.
  • 49. 48 1 var parametros = {}; 2 parametros[opensocial.Message.Field.TITLE] = 'Título do e-mail'; 3 parametros[opensocial.Message.Field.TYPE] = opensocial.Message.Type.EMAIL; 4 var mensagem = opensocial.newMessage('Corpo do e-mail', parametros); 5 var destinatario = 'VIEWER'; 6 opensocial.requestSendMessage(destinatario, mensagem); Quadro 25 - Enviando uma mensagem de e-mail 1 var mensagem = {}; 2 mensagem.title = 'Título do e-mail'; 3 mensagem.body = 'Corpo do e-mail'; 4 mensagem.type = opensocial.Message.Type.EMAIL; 5 var destinatario = 'VIEWER'; 6 osapi.ui.requestSendMessage(destinatario, mensagem); Quadro 26 - Enviando uma mensagem de e-mail usando a OSAPI Caso fosse desejado enviar uma notificação ao invés de uma mensagem de e-mail, seria necessário mudar o tipo da mensagem de opensocial.Message.Type.EMAIL para opensocial.Message.Type.NOTIFICATION. 3.3.4.2 Atualizações As atividades geradas por um usuário ou os amigos do usuário são geralmente exibidas nas redes sociais sob o título de "Atualizações". No OpenSocial, uma atividade é representada pela classe opensocial.Activity. Os seguintes passos são necessários para a criação de uma atividade:  Criar o objeto representando a atividade, usando a função opensocial.newActivity, passando os parâmetros que definem a atividade;  Chamar a função opensocial.requestCreateActivity passando como parâmetros a atividade e a prioridade da atividade. Os parâmetros que podem ser passados na criação da atividade estão definidos em opensocial.Activity.Field, e podem ser vistos no Quadro 27.
  • 50. 49 Campo Descrição APP_ID Uma string que especifica o aplicativo ao qual esta atividade está associada. BODY Uma string que especifica uma versão expandida opcional de uma atividade. BODY_ID Uma string que especifica o ID da mensagem do modelo de corpo nas especificações do gadget. EXTERNAL_ID O ID de uma string opcional gerado pelo aplicativo. ID O ID de uma string que é permanentemente associado a esta atividade. MEDIA_ITEMS Todas as fotos, vídeos ou imagens que devem ser associados à atividade. POSTED_TIME Uma string que especifica o tempo, em milissegundos, durante o qual esta atividade ocorreu a partir do horário inicial. PRIORITY Um número entre 0 e 1 que representa a prioridade relativa desta atividade em relação a outras atividades da mesma origem. STREAM_FAVICON_URL Uma string que especifica o URL do favicon6 do fluxo. STREAM_SOURCE_URL Uma string que especifica o URL de origem do fluxo. STREAM_TITLE Uma string que especifica o título do fluxo. STREAM_URL Uma string que especifica o URL do fluxo. TEMPLATE_PARAMS Um mapa dos pares personalizados de chave/valor associados a esta atividade. TITLE Uma string que especifica o texto principal de uma atividade. TITLE_ID Uma string que especifica o ID da mensagem do modelo de título nas especificações do gadget. URL Uma string que especifica o URL que representa esta atividade. USER_ID O ID da string do usuário ao qual esta atividade se destina. Quadro 27 - Campos do objeto opensocial.Activity.Field Fonte: OpenSocial (2010g). Uma atividade pode ter as seguintes prioridades:  opensocial.CreateActivityPriority.HIGH: prioridade alta;  opensocial.CreateActivityPriority.LOW: prioridade baixa. Se for solicitada prioridade alta, o aplicativo solicitará a permissão do usuário para criar as atividades em seu nome, caso ainda não tenha permissão. Se for ‒‒‒‒‒‒‒‒‒‒‒‒‒‒ 6 Ícone usado para representar um site favorito (bookmark) no navegador.
  • 51. 50 solicitada prioridade baixa, a chamada não fará nada se o aplicativo não tiver permissão para a criação de atividades. O Quadro 28 mostra um exemplo de criação de uma atividade enquanto o Quadro 29 mostra um exemplo usando a OSAPI. 1 var parametros = {}; 2 parametros[opensocial.Activity.Field.TITLE] = 'Título da atividade'; 3 var atividade = opensocial.newActivity(parametros); 4 opensocial.requestCreateActivity(atividade, opensocial.CreateActivityPriority.HIGH); Quadro 28 - Criando uma atividade 1 var atividade = {}; 2 atividade.title = 'Título da atividade'; 3 osapi.activities.create({ userId: '@viewer', activity: atividade }); Quadro 29 - Criando uma atividade usando a OSAPI 3.3.4.3 Convites O OpenSocial permite aos usuários convidar os seus amigos para usar um aplicativo. Para isso, basta chamar a função opensocial.requestShareApp, passando como parâmetros o ID de um ou mais usuários e o motivo pelo o qual o usuário deseja compartilhar o aplicativo. Um exemplo de criação de um convite pode ser visto no Quadro 30 e no Quadro 31 usando a OSAPI. 1 var motivo = opensocial.newMessage('Veja que legal esse aplicativo!'); 2 opensocial.requestShareApp('VIEWER', motivo); Quadro 30 - Criando um convite para um usuário 1 var motivo = 'Veja que legal esse aplicativo!'; 2 osapi.ui.requestShareApp('@viewer', motivo); Quadro 31 - Criando um convite para um usuário usando a OSAPI
  • 52. 51 3.3.5 Persistência A API do OpenSocial permite salvar e recuperar dados por usuário e por aplicativo. Esses dados serão sempre armazenados na forma de strings. Os dados são armazenados em pares chave-valor. (OPENSOCIAL, 2010d). Como só strings podem ser armazenadas, é sugerido converter os dados que serão armazenados para o formato JSON. Assim, o dado será gravado como uma string, mas irá manter a estrutura original do objeto. Posteriormente, quanto esse dado for recuperado, a string armazenada pode ser convertida para um objeto JSON. As funções para a conversão de string para JSON e de JSON para string estão na API de gadgets:  gadgets.json.parse: analisa uma string JSON, produzindo um valor JavaScript;  gadgets.json.stringify: converte um valor JavaScript em uma string JSON. 3.3.5.1 Armazenando Dados Para armazenar um valor, deve-se usar a função opensocial.newUpdatePersonAppDataRequest, passando como parâmetros o ID da pessoa, o nome da chave e por último o seu valor. Atualmente, somente o ID especial de VIEWER é permitido. O nome da chave pode conter caracteres alfanuméricos (A-Z; a-z; 0-9), sublinhado( _ ), ponto ( . ) ou hífen ( - ) e o valor deve ser um valor válido no formato JSON. (OPENSOCIAL, 2010g). No Quadro 32 é apresentado um exemplo de como gravar um dado e no Quadro 33 de como gravar um dado usando a OSAPI. 1 var requisicao = opensocial.newDataRequest(); 2 var atualizacao = requisicao.newUpdatePersonAppDataRequest('VIEWER', 'cor', 'verde'); 3 requisicao.add(atualizacao); 4 requisicao.send(); Quadro 32 - Gravando um dado
  • 53. 52 1 var dados = {}; 2 dados.cor = 'verde'; 3 osapi.appdata.update({ userId: '@viewer', data: dados }); Quadro 33 - Gravando um dado usando a OSAPI 3.3.5.2 Recuperando Dados A recuperação dos dados gravados é feita através da função opensocial.newFetchPersonAppDataRequest. Essa função recebe como parâmetros um objeto opensocial.IdSpec para especificar quais pessoas devem ser obtidas e o nome de uma ou mais chaves das quais se deseja obter os dados. Um exemplo de como recuperar dados usando a OSAPI pode ser visto no Quadro 34. 1 function recuperarDados() { 2 osapi.appdata.get({ 3 userId: '@owner', 4 keys: ['cor'] 5 }).execute(retorno); 6 } Quadro 34 - Recuperando um dado usando a OSAPI No Quadro 35 pode ser visto um exemplo de como recuperar dados usando a API JavaScript tradicional. A função JavaScript retorno receberá os dados da requisição.
  • 54. 53 1 function recuperarDados() { 2 var idSpec = opensocial.newIdSpec({ 'userId' : 'OWNER' }); 3 var requisicao = opensocial.newDataRequest(); 4 var visualizador = requisicao.newFetchPersonRequest(opensocial.IdSpec.PersonId.VIEWER ); 5 var recuperacao = requisicao.newFetchPersonAppDataRequest(idSpec, 'cor'); 6 requisicao.add(visualizador, 'visualizador'); 7 requisicao.add(recuperacao, 'dados'); 8 requisicao.send(retorno); 9 } 10 function retorno(retorno) { 11 if (retorno.hadError()) { 12 document.write(retorno.getErrorMessage()); 13 } else { 14 var visualizador = retorno.get('visualizador').getData(); 15 var dados = retorno.get('dados').getData(); 16 var cor = dados[visualizador.getId()]['cor']; 17 document.write('Cor: ' + cor); 18 } 19 } Quadro 35 - Recuperando um dado 3.3.5.3 Excluindo Dados Para excluir um dado do armazenamento, basta chamar a função opensocial.newRemovePersonAppDataRequest, passando como parâmetros o ID da pessoa a ser atualizada (somente o ID especial de VIEWER é permitido) e o nome de uma ou mais chaves a serem excluídas. Um exemplo pode ser visto no Quadro 36 e no Quadro 37 usando a OSAPI. 1 requisicao = opensocial.newDataRequest(); 2 var atualizacao = requisicao.newRemovePersonAppDataRequest('VIEWER', 'chave'); 3 requisicao.add(atualizacao); 4 requisicao.send(); Quadro 36 - Excluíndo um dado 1 appdata.delete({ 2 userId: '@viewer', 3 keys: ['chave'] 4 }); Quadro 37 - Excluíndo um dado usando a OSAPI
  • 55. 54 3.4 API RESTFUL DO OPENSOCIAL Como alternativa a API JavaScript no lado do cliente existe a API RESTful, que permite uma interação entre os servidores de terceiros com os servidores das redes sociais. Ou seja, é possível desenvolver aplicativos sociais que sejam executados fora de um recipiente. Para realizar o serviço de autenticação e autorização é utilizado o protocolo OAuth. Em cada chamada REST são passados os parâmetros do OAuth pela URL. Adicionalmente à API RESTful, há também uma API RPC (Remote Procedure Call) para o OpenSocial, com as mesmas funcionalidades. Aplicativos baseados no servidor podem se comunicar diretamente com uma rede social (recipiente) de uma forma independente de linguagens usando a API RESTful do OpenSocial. O OpenSocial exige que o aplicativo passe por um processo de autorização (ou autenticação). Uma vez completado, isso permite ao programa fazer requisições REST seguras diretamente para o recipiente da rede social. Cada requisição terá associada a informação de autenticação apropriada. (GREWE, 2009, p. 175, tradução própria). A API RESTful define os seguintes recursos: Atividade, Pessoa, Grupo e Dados do Aplicativo. Os recursos podem ser representados em três formatos: JSON, XML e Atom. A maioria das operações realizadas sob esses recursos consistem de recuperação (GET), atualização (PUT), criação (POST ou PUT) ou destruição (DELETE). (OPENSOCIAL AND GADGETS SPECIFICATION GROUP, 2009, tradução própria). A estrutura do objeto de resposta de uma requisição REST bem sucedida, no formato JSON, é apresentado no Quadro 38. 1 { 2 "startIndex" : 1, 3 "itemsPerPage" : 10, 4 "totalResults" : 100, 5 "entry" : [ 6 {...primeiro item...}, 7 {...segundo item...} 8 ... 9 ] 10 } Quadro 38 - Estrutura do objeto de resposta de uma requisição REST
  • 56. 55 No Quadro 38, estão representados:  startIndex: o índice do primeiro resultado retornado na resposta;  itemsPerPage: o número de resultados retornados;  totalResults: o número total de resultados;  entry: uma matriz com os objetos que foram requisitados (pessoas, por exemplo). A criação de uma chamada REST do OpenSocial envolve a construção de uma URL, a especificação do tipo do método HTTP (GET, POST, PUT, DELETE) e a criação de quaisquer dados e parâmetros necessários. (GREWE, 2009, p. 198, tradução própria). As redes sociais que suportam a API RESTful do OpenSocial têm uma URL base para onde as chamadas deverão ser efetuadas. A URL base do Orkut, por exemplo, é http://www.orkut.com/social/rest. Após essa URL base, são adicionados outros fragmentos e parâmetros. Por exemplo, a URL completa para retornar os dados da pessoa no Orkut é http://www.orkut.com/social/rest/people/@me/@self. Caso seja necessário que o resultado retorne no formato XML a URL da chamada será http://www.orkut.com/social/rest/people/@me/@self?format=xml. A Figura 4 mostra as partes que compõe a URL da chamada REST apresentada como exemplo. Figura 4 - Partes que compõe a URL de uma chamada REST do OpenSocial Fonte: Autoria própria. Na URL de exemplo foram usados dois seletores: @me e @self. Os seletores são usados para representar uma pessoa ou um grupo. Existem os seguintes seletores:  @me: para representar o usuário da aplicação;  @self: para representar a pessoa que está requisitando a solicitação;  @all: para representar todo um conjunto;  @friends: para representar o subconjunto de amigos; http://www.orkut.com/social/rest URL base /people/@me/@self Fragmento ?format=xml Parâmetros
  • 57. 56  @app: para representar a aplicação que está fazendo a solicitação. A seguir são apresentados os fragmentos que podem ser usados na chamada de uma requisição REST. O termo {guid} é usado para representar o identificador de usuário único e global (globally-unique user identifier), o termo {pid} representa o registro de uma pessoa dentro de uma coleção, {groupid} representa o identificador do grupo e o termo {appid} representa o identificador do aplicativo. No Quadro 39 são apresentados os fragmentos que podem ser usados na construção da URL para retornar dados sobre uma pessoa. O Quadro 42 apresenta o fragmento usado para retornar os dados de um grupo. Fragmento da URL Descrição /people/{guid}/@all Coleção de todas as pessoas conectadas ao usuário {guid}. /people/{guid}/@friends Coleção de todos os amigos do usuário {guid}. Subconjunto de @all. /people/{guid}/{groupid} Coleção de todas as pessoas conectadas ao usuário {guid} no grupo {groupid}. /people/{guid}/@all/{pid} Registro individual de uma pessoa específica e conhecida de {guid}. Mostra a visão de {pid} através de {guid}. /people/{guid}/@self Registro do perfil do usuário {guid}. /people/@me/@self Registro do perfil do solicitante /people/@supportedFields Returna todos os campos que o recipiente suporta nos objetos de pessoas. /people/{guid}/@deleted Essa é uma API opcional que irá retornar todas as pessoas conectadas ao usuário {guid} e que foram excluídas. Isso deve ser normalmente usado em conjunto com o parâmetro updatedSince. Quadro 39 - Fragmentos da URL para o recurso Pessoa Fonte: Opensocial and Gadgets Specification Group (2009, tradução própria). Um exemplo da representação de uma pessoa no formato JSON é mostrado no Quadro 40, enquanto no Quadro 41 a mesma pessoa é representada no formato XML.
  • 58. 57 1 { 2 "id" : "orkut.com:8fg4evrSqs5q3tibiEOE", 3 "displayName" : "Cleber", 4 "name" : { "formatted" : "Clebersander Rech" }, 5 "gender" : "male" 6 } Quadro 40 - Representação de uma pessoa no formato JSON 1 <person xmlns="http://ns.opensocial.org/2008/opensocial"> 2 <id>orkut.com:8fg4evrSqs5q3tibiEOE</id> 3 <displayName>Cleber</displayName> 4 <name> 5 <formatted>Clebersander Rech</formatted> 6 </name> 7 <gender>male</gender> 8 </person> Quadro 41 - Representação de uma pessoa no formato XML Fragmento da URL Descrição /groups/{guid} Coleção dos grupos associados ao usuário {guid}. Quadro 42 - Fragmentos da URL para o recurso Grupo Fonte: Opensocial and Gadgets Specification Group (2009, tradução própria). Com a API RESTful do OpenSocial não é possível apenas recuperar dados, mas também criar. Enquanto para a recuperação de dados é usado o método GET do HTTP na chamada da URL, para a criação de dados é usado o método POST, passando o recurso que será criado (uma atividade ou um dado, por exemplo) no corpo da requisição HTTP. No Quadro 43 são apresentados os fragmentos para a construção da URL para recuperar atividades, enquanto o Quadro 44 mostra os fragmentos da URL usados para recuperar os dados de um aplicativo. Fragmento da URL Descrição /activities/{guid}/@self Coleção das atividades geradas para o usuário informado. /activities/{guid}/@self/{appid} Coleção das atividades geradas por um aplicativo para o usuário informado. /activities/{guid}/@friends Coleção das atividades geradas pelos amigos do usuário {guid}. /activities/{guid}/@friends/{appid} Coleção das atividades geradas por um aplicativo pelos amigos do usuário {guid}.
  • 59. 58 Fragmento da URL Descrição /activities/{guid}/{groupid} Coleção das atividades geradas por pessoas no grupo {groupid} pertencente ao usuário {uid}. /activities/{guid}/{groupid}/{appid} Coleção das atividades geradas por um aplicativo pelas pessoas no grupo {groupid} pertencente ao usuário {uid}. /activities/{guid}/@self/{appid}/{activityid} Atividade indivisual, geralmente encontrado a partir de coleção. /activities/@supportedFields Retorna todos os campos que o recipiente suporta nos objetos de atividades. Quadro 43 - Fragmentos da URL para o recurso Atividade Fonte: Opensocial and Gadgets Specification Group (2009, tradução própria). Fragmento da URL Descrição /appData/{guid}/@self/{appid} Todos os dados de aplicativo do usuário {guid} no aplicativo {appid}. /appData/{guid}/@friends/{appid} Todos os dados de aplicativo dos amigos do usuário {guid} no aplicativo {appid}. Somente leitura. /appData/{guid}/@self/{appid}?fields={campo} Retorna apenas o dados do {campo} para o usuário {guid} no aplicativo {appid}. Quadro 44 - Fragmentos da URL para o recurso Dados do Aplicativo Fonte: Opensocial and Gadgets Specification Group (2009, tradução própria). Na construção da URL da chamada REST também podem ser passados parâmetros adicionais, que estão listados no Quadro 45. Eles servem para filtrar os resultados, ordená-los ou mesmo para mudar o formato do retorno da chamada. Parâmetro de consulta Descrição count={contador} Número de itens a serem retornados. Se nenhum parâmetro for especificado, o recipiente pode escolher quantos itens na coleção devem ser retornados. No entanto, o recipiente DEVE suportar um grande valor para que todos os itens possam ser retornados por padrão. filterBy={nomeCampo} Para uma coleção, retorna as entradas filtradas pelo campo informado. filterOp={operacao} A operação a ser usada no filtro de uma coleção. Valores válidos são: contains (contém), equals (igual), startsWith (inicia com), e present (presente). O valor padrão é contains. filterValue={valor} O valor a ser usado no filtro de uma coleção. Por exemplo, filterBy=name&filterOp=startsWith&filterV alue=John irá retorna todos os itens cujo campo nome inicia com John.
  • 60. 59 Parâmetro de consulta Descrição format={formato} Formato desejado. Os valores válidos são: atom, json e xml. O valor padrão é json. fields={-join|,|campo} Lista de campos para incluir na representação dos membros de uma coleção. Se nenhum campo for informado cabe ao recipiente decidir quais campos retornar. Entretanto, a coleção DEVE incluir um conjunto mínimo de campos. Para pessoas, esses campos são: id, name e thumbnailUrl. Para as atividades os campos são: id e title. Para indicar o retorno de todos os campos disponíveis, é possível usar @all. sortBy={nomeCampo} Para uma coleção, retorna as entradas ordenadas pelo campo informado. sortOrder={ordem} Usado para ordenar os objetos em uma coleção. Pode ser ascending (ascendente) ou descending (decrescente). O padrão é ascending (ascendente). startIndex={indiceInicio} O índice de uma coleção paginada. updatedSince={dataHora} Quando informado, o recipiente deve retornar somente itens cuja data de atualização é igual ou mais recente que o valor informado. Quadro 45 - Parâmetros de consulta Fonte: Opensocial and Gadgets Specification Group (2009, tradução própria). 3.5 OPENSOCIAL TEMPLATES (OST) O padrão OpenSocial Templates permite aos desenvolvedores (através de marcação e uso de scripts) facilmente especificar funcionalidades necessárias ao aplicativo e elementos gráficos, suportando reusabilidade e o compartilhamento da marcação criada pelo desenvolvedor. Algo semelhante é usado na rede social Facebook, através do Facebook Markup Language (FBML). (GREWE, 2009, p. 325, tradução própria). Uma aplicação usando OpenSocial Templating pode buscar, injetar, manter em cache e armazenar as requisições de dados para o aplicativo antes que qualquer código seja executado no cliente. O OST não representa um substituto completo para o JavaScript, ele pressupõe que os aplicativos podem usar o JavaScript de reserva sempre que o aplicativo não for capaz de usar o OST. (OPENSOCIAL AND GADGETS SPECIFICATION GROUP, 2010e, tradução própria). Para um aplicativo usando o OST, ele deve adicionar o código abaixo nas preferências do gadget: <Require feature="opensocial-templates">
  • 61. 60 3.5.1 Formato do Template Um template pode ser definido em um arquivo XML separado. Esse arquivo pode incluir tags HTML e outras tags customizadas. Um exemplo de template pode ser visto no Quadro 46. 1 <Template> 2 <div style="font-size: 12px;">Olá mundo!</div> 3 </Template> Quadro 46 - Template do OpenSocial Um template também pode ser definido diretamente dentro da seção de conteúdo do arquivo XML que representa o gadget. Nesse caso, o template será definido dentro de um elemento script com o tipo definido como "text/os- template", como pode ser visto no exemplo do Quadro 47. 1 <script type="text/os-template"> 2 <div style="font-size: 12px;">Olá mundo!</div> 3 </script> Quadro 47 - Template do OpenSocial 3.5.2 Expressões Expressões podem ser usadas para acessar dados dentro do template usando um subconjunto da Linguagem de Expressão do JSP (JavaServer Pages). As expressões são escritas usando a sintaxe ${expressao}. Um exemplo de expressão pode ser visto no Quadro 48. 1 <script type="text/os-template"> 2 <div style="font-size: 12px;">Olá ${Viewer.Name}!</div> 3 </script> Quadro 48 - Usando Linguagem de Expressão
  • 62. 61 3.5.3 Variáveis As variáveis são usadas dentro das expressões. Além das variáveis que representam os campos do objeto que será acessado, existem algumas variáveis globais que têm o nome reservado. São elas:  ${Top}: refere-se ao contexto de dados passados no processamento do template;  ${Context}: é uma área para variáveis adicionais necessárias no processamento do template;  ${Cur}: refere-se ao item atualmente sendo processado por um repetidor7 ;  ${My}: refere-se aos dados que são passados para o template. Elementos filhos de tags que são usadas para a chamada de templates são passadas como parâmetros para o template e são acessíveis pela variável ${My}. (OPENSOCIAL AND GADGETS SPECIFICATION GROUP, 2010e, tradução própria). Mensagens de localização dentro de um template podem ser acessadas usando a variável ${Msg}. 3.5.4 Chamada de Templates Templates podem ser chamados por outros templates. Para isso, um template deve ter um nome. Caso o template esteja em um arquivo separado, será usado o atributo name do elemento Template para definir o nome do mesmo. Por exemplo: <Template name="os:HelloWorld">. Já se o template foi criado usando o elemento script, o nome será definido no atributo tag do elemento. No Quadro 49 é mostrado um exemplo de um template e sua chamada. ‒‒‒‒‒‒‒‒‒‒‒‒‒‒ 7 Repetição ou iteração é um recurso das linguagens de programação que permite repetir uma ou mais ações.
  • 63. 62 1 <script type="text/os-template" tag="meuTemplate:OlaMundo"> 2 <div style="font-size: 12px;">Olá mundo!</div> 3 </script> 4 <script type="text/os-template"> 5 <meuTemplate:OlaMundo /> 6 </script> Quadro 49 - Criação e chamada de um template Na linha 1 do Quadro 49 é definido o nome do template (meuTemplate:OlaMundo) e na linha 5 é feita a chamada do mesmo. 3.5.5 OpenSocial Markup Language (OSML) Como parte do OST, é oferecida uma linguagem de marcação chamada OpenSocial Markup Language (OSML). O OSML é um subconjunto do OST, por isso, quando se faz uso do OST o OSML também está disponível para o aplicativo. No entanto, se o aplicativo necessita apenas do OSML, e não precisa do OST, deve-se adicionar o código abaixo nas preferências do gadget: <Require feature="osml"> 3.5.6 Conteúdo Condicional Podem ser usadas expressões para indicar se um elemento deve ser exibido ou não. Para isso é usado o atributo if de qualquer elemento ou pode ser usada a tag <os:If>. O uso da sintaxe ${} ao redor de uma expressão condicional é opcional. Deve-se lembrar que a expressão deve retornar um valor booleano verdadeiro (true) para que o elemento seja exibido. Um exemplo do uso do atributo if e do elemento podem ser vistos no Quadro 50 e Quadro 51 respectivamente. 1 <div if="Top.Pontuacao == Top.MaiorPontuacao"> 2 Você tem a maior pontuação! 3 </div> Quadro 50 - Uso do atributo if do template
  • 64. 63 1 <os:If condition="Top.Pontuacao == Top.MaiorPontuacao"> 2 Você tem a maior pontuação! 3 </os:If> Quadro 51 - Uso do elemento <os:If> 3.5.7 Elementos de Repetição Elementos podem ser repetidos mais de uma vez de acordo com uma expressão. É usado o atributo repeat de qualquer elemento ou a tag <os:Repeat>. O item atual da lista de repetição é colocado na variável ${Cur}. Assim como nos elementos condicionais, o uso da sintaxe ${} ao redor da expressão é opcional. No Quadro 52 é mostrado um exemplo de repetição usando o atributo if e no Quadro 53 é usado o elemento <os:Repeat>. 1 <div repeat="Top.ViewerFriends"> 2 O nome do seu amigo é ${Cur.Name} 3 </div> Quadro 52 - Uso do atributo if do template 1 <os:Repeat expression="Top.ViewerFriends"> 2 O nome do seu amigo é ${Cur.Name} 3 </os:Repeat> Quadro 53 - Uso do elemento <os:If> 3.5.8 Tags Um conjunto inicial de tags está disponível para serem usadas em um gadget. Elas são mostradas no Quadro 54. Lembrando que para usar as tags elas devem estar dentro de blocos <script type="text/os-template">. Tag Descrição Exemplo <os:Name> Mostra o nome de uma pessoa. Se a URL do perfil estiver disponível, será criado um link para o mesmo. Bem-vindo, <os:Name person="${Viewer}" />
  • 65. 64 Tag Descrição Exemplo <os:PeopleSelector> Exibe uma interface com uma lista de pessoas para serem escolhidas, e associa ao campo de um formulário os valores selecionados. Selecione alguns amigos: <os:PeopleSelector group="${ViewerFriends}" inputName="amigos" /> <os:Badge> Exibe as informações sobre uma pessoa usando o estilo do recipiente, geralmente com uma imagem. Meu melhor amigo é: <os:Badge person="${TopFriend}" /> Quadro 54 - Tags disponíveis Fonte: Opensocial and Gadgets Specification Group (2010b, tradução própria). Um recipiente deve suportar no mínimo as três tags listadas no Quadro 54. Um recipiente também pode suportar tags adicionais. Um esforço será feito para fazer com que esse suporte seja o mais consistente possível entre os diferentes recipientes, e tags consideradas úteis podem ser adotadas futuramente na especificação. (OPENSOCIAL AND GADGETS SPECIFICATION GROUP, 2010b, tradução própria). 3.6 PIPELINING DE DADOS Pipelining8 de dados é uma sintaxe declarativa para definir os dados que um gagdet exige do recipiente. Todas as tags de pipelining de dados devem ter um atributo key que é usado para identificar o dado na resposta. O pipelining de dados só deve ser usado para chamadas de requisição de dados e não funciona para atualização de dados. (OPENSOCIAL AND GADGETS SPECIFICATION GROUP, 2010a, tradução própria). Os dados retornados ficam disponíveis em três contextos:  Enviado na requisição de conteúdo: os dados serão enviados para o servidor do desenvolvedor;  OpenSocial Templates: os dados estarão disponíveis através de variáveis nos templates;  JavaScript: os dados estarão disponíveis na API JavaScript. ‒‒‒‒‒‒‒‒‒‒‒‒‒‒ 8 Processamento por encadeamento.
  • 66. 65 No Quadro 55 são exibidas as tags disponíveis para pipelining de dados. Para fazer uso do mesmo, deve-se adicionar a linha abaixo na seção de preferências do gadget: <Require feature="opensocial-data" /> Tag Descrição Exemplo <os:DataRequest> Requisita dados do OpenSocial, incluindo dados de pessoas e atividades. <os:DataRequest key="amigos" method="people.get" userId="@owner" groupId="@friends" /> <os:HttpRequest> Requisita dados arbitrários de uma URL qualquer. <os:HttpRequest key="cores" href="http://exemplo.com/lista Cores.js" /> <os:Var> Declara um valor literal ou resultado de uma instrução da linguagem de expressão. <os:Var key="meuNumero" value="1" /> <os:PeopleRequest> Requisita informações de um grupo ou lista de pessoas. É equivalente a usar a tag <os:DataRequest> com o atributo method="people.get". <os:PeopleRequest key="amigos" userId="@owner" groupId="@friends" /> <os:ViewerRequest> <os:OwnerRequest> Requisita informações do perfil do visualizador ou do dono do gadget. É equivalente a usar a tag <os:DataRequest> com o atributo method="people.get" e o atributo userId="@viewer" ou userId="@owner". <os:ViewerRequest key="visualizador" /> <os:ActivitiesRequest> Requisita atividades. É equivalente a usar a tag <os:DataRequest> com o atributo method="activities.get". <os:ActivitiesRequest key="atividadesVisualizador" userid="@viewer" /> Quadro 55 - Tags disponíveis para pipelining de dados Fonte: Opensocial and Gadgets Specification Group (2010a, tradução própria) e Opensocial and Gadgets Specification Group (2010b, tradução própria). Para acessar o pipelining de dados via JavaScript, está disponível a função opensocial.data.getContext().getDataSet. Por exemplo, para requisitar os dados do visualizador a seguinte linha pode ser usada: <os:ViewerRequest key="Visualizador" /> Já para acessar os dados requisitados, o seguinte código JavaScript pode ser usado:
  • 67. 66 opensocial.data.getContext().getDataSet('Visualizador'); No Quadro 56 um exemplo do uso de pipelining de dados em conjunto com templates pode ser visualizador. 1 <script type="text/os-data"> 2 <os:ViewerRequest key="visualizador" /> 3 <os:PeopleRequest key="amigos" userid="@viewer" groupid="@friends" /> 4 </script> 5 <script type="text/os-template"> 6 Lista de amigos de ${visualizador.name}: 7 <ul> 8 <li repeat="${amigos}">${Cur.name}</li> 9 </ul> 10 </script> Quadro 56 - Uso de pipelining de dados em conjunto com templates Na linha 2 do Quadro 56 é instruído ao recipiente carregar os dados do visualizador do gadget e associá-lo a chave visualizador, que será transformada em uma variável de mesmo nome para uso no template. A linha 3 pede ao recipiente para carregar os dados dos amigos do visualizador. Finalmente, nas linhas 7 e 9 é feito uso das variáveis que foram criadas pelo pipelining de dados. 3.7 FACEBOOK Fundada em fevereiro de 2004, a rede social Facebook possui mais de 500 milhões de usuários ativos. É um dos sites construídos usando a linguagem de programação PHP mais acessado do mundo. Também possui uma das maiores instalações do banco de dados MySQL, executando milhares de bancos de dados. (FACEBOOK, 2010c, tradução própria). Mais de um milhão de desenvolvedores e empresários de mais de 180 países têm utilizado a plataforma de desenvolvimento do Facebook. Por mês, mais de 70% dos usuários utilizam os aplicativos desenvolvidos para o Facebook. São mais de 550 mil aplicativos ativos disponíveis aos usuários, além de mais de um milhão de sites integrados à Plataforma Facebook. (FACEBOOK, 2010b, tradução própria).
  • 68. 67 3.7.1 Plataforma Facebook No núcleo do Facebook está o grafo social, que representa as pessoas e as suas conexões. A Plataforma Facebook é uma coleção de APIs e ferramentas que permitem a integração entre o grafo social e os aplicativos do Facebook ou sites externos. No núcleo da Plataforma Facebook está a API de Grafo, que permite a leitura e a escrita de dados no Facebook. (FACEBOOK, 2010a, tradução própria). A API de Grafo permite uma visão do grafo social do Facebook, representando os objetos no grafo (pessoas, fotos e eventos, por exemplo) e as conexões entre eles (amizades e conteúdo compartilhado, por exemplo). A API do Facebook funciona através do protocolo REST. Assim como na API RESTful do OpenSocial, o acesso aos objetos do grafo social se dá através da construção de uma URL com a definição do método do protocolo HTTP que será usado (geralmente é usado o GET) e, opcionalmente, alguns parâmetros adicionais. Por padrão, os objetos retornados nas chamadas REST estão no formato JSON. Cada objeto no grafo social do Facebook possui uma ID única. Essa ID é representada através de uma URL, no seguinte formato: https://graph.facebook.com/ID Onde a ID da URL mostrada pode ser tanto um número quanto um nome de usuário, ou ainda pode ser usado o seletor me no lugar da ID, que representa o usuário conectado no aplicativo. Na Figura 5 pode-se ver as partes que compõe a URL de uma chamada REST. Figura 5 - Partes que compõe a URL de uma chamada REST do Facebook Fonte: Autoria própria. Por exemplo, uma chamada a URL https://graph.facebook.com/clrech, onde clrech é o nome de usuário, irá retornar o seguinte objeto: { "id": "100000588241073", https://graph.facebook.com/ URL base /clrech Fragmento ?fields=id,name Parâmetros
  • 69. 68 "name": "Clebersander Rech", "first_name": "Clebersander", "last_name": "Rech", "link": "http://www.facebook.com/clrech", "gender": "masculino", "locale": "pt_BR" } No grafo social do Facebook todos os objetos estão conectados uns aos outros através de relacionamentos. Esses relacionamentos são chamados de conexões na API de Grafo. Um exemplo de conexão é a amizade entre duas pessoas. Outro exemplo é os gostos de uma pessoa. Cada conexão também possui uma ID única, que é representada no seguinte formato: https://graph.facebook.com/ID/TIPO_CONEXAO Alguns exemplos de conexões são:  https://graph.facebook.com/me/friends: retorna os amigos do usuário conectado;  https://graph.facebook.com/me/albums: retorna os álbuns de fotos do usuário conectado;  https://graph.facebook.com/clrech/groups: retorna os grupos do usuário clrech. Outros tipos de conexões incluem livros, filmes, observações, vídeos e eventos. A lista completa pode ser consultada na documentação da API no endereço http://developers.facebook.com/docs/reference/api. O Facebook também disponibiliza uma linguagem de consulta declarativa semelhante ao SQL (Structured Query Language), chamada de FBL (Facebook Query Language). A sintaxe básica da FBL é: SELECT [campos] FROM [tabela] WHERE [condicoes] Para solicitar o nome e o e-mail do usuário clrech, por exemplo, a seguinte consulta será feita: SELECT name, email FROM user WHERE username = 'clrech'
  • 70. 69 Apenas as informações de uma tabela podem ser solicitadas de cada vez. A lista completa de tabelas e campos que podem ser consultados usando a FQL pode ser consultado no endereço http://developers.facebook.com/docs/reference/fql. As consultas do FBL são feitas através de chamadas REST usando a seguinte URL: https://api.facebook.com/method/fql.query?query=CONSULTA No parâmetro query é passada a consulta a ser realizada. 3.7.2 Comparativo Entre as APIs do OpenSocial e do Facebook No OpenSocial existe o conceito de visões. No Facebook também existe o mesmo conceito. Existem duas visões: a visão canvas, que, assim como no OpenSocial, é quando o aplicativo é exibido em tela inteira. A outra visão do Facebook é a visão profile, quando o aplicativo é exibido em uma aba no perfil do usuário. No OpenSocial, um aplicativo é sempre exibido dentro de um elemento iframe. Já no Facebook, não necessariamente. Um aplicativo do Facebook pode ser exibido em um iframe ou ser incorporado diretamente no código HTML da página do Facebook. Nesse último modo, o servidor do Facebook lê o arquivo que contém o código do aplicativo, faz o processamento desse arquivo, e inclui o código processado diretamente na página do Facebook. 3.7.2.1 Linguagem de Marcação Assim como o OpenSocial possui a linguagem de marcação OSML, o Facebook também possui a sua própria: o Facebook Markup Language (FBML). O FBML é composto de diversas tags que fornecem acesso aos dados do Facebook (nome do usuário, por exemplo) e outras funcionalidades (exibir uma lista de amigos, por exemplo). Algumas tags do FBML possuem outra correspondente no OSML. No OpenSocial o nome do usuário pode ser exibido dessa forma: <os:Name person="${User}" />
  • 71. 70 Já no Facebook o nome do usuário é exibido assim: <fb:name uid="1" /> A diferença é que na tag do OSML é passado um objeto para a mesma, enquanto na tag do FBML é passado a ID do usuário. As tags do FBML também suportam atributos. A tag <fb:name>, por exemplo, possui o atributo lastnameonly, que recebe um valor booleano indicando se somente o sobrenome do usuário deve ser exibido. No Quadro 57 podem ser vistas algumas tags do OSML e do FBML que possuem funções semelhantes. OSML FBML Descrição <os:PeopleSelector> <fb:friend- selector> Exibe um seletor de pessoas <os:If> <fb:if> Exibe o conteúdo dentro da tag de acordo com uma condição <os:Name> <fb:name> Exibe o nome de um usuário Quadro 57 - Tags do OSML e do FBML com funções semelhantes O FBML oferece muitas outras tags. A lista completa pode ser consultada no endereço http://developers.facebook.com/docs/reference/fbml. 3.7.2.2 JavaScript O Facebook também permite o acesso aos dados da sua rede social através da linguagem de programação JavaScript. Para isso é oferecido o JavaScript SDK (Software Development Kit), que pode ser referenciado diretamente através do endereço http://connect.facebook.net/pt_BR/all.js. Ao contrário do JavaScript do OpenSocial, que pode ser usado apenas dentro de um aplicativo OpenSocial, a API JavaScript do Facebook pode ser usado em qualquer site, dentro ou fora do Facebook. Para solicitar dados ao Facebook, a API JavaScript possui a função FB.api. Essa função recebe como parâmetro um caminho. Esse caminho é o mesmo que o
  • 72. 71 usado nas chamadas REST da API de Grafo. Por exemplo, se para recuperar os amigos do usuário clrech, a URL da chamada REST é: https://graph.facebook.com/clrech/friends Então para recuperar os amigos através da API JavaScript é feita a seguinte chamada: FB.api('/clrech/friends'); Opcionalmente, uma função de retorno de chamada (callback) pode ser passada como parâmetro na função FB.api. Toda a documentação da API JavaScript do Facebook pode ser consultada no endereço http://developers.facebook.com/docs/reference/javascript. 3.7.2.3 Segurança Da mesma forma que o OpenSocial utiliza o protocolo OAuth para a autenticação e autorização das requisições REST, a API de Grafo do Facebook também faz uso desse protocolo. Para usar o OAuth, o site ou aplicativo que deseja acessar os dados do Facebook precisa ser registrado no site do Facebook.
  • 73. 72 4 ESTUDO DE CASO Tendo feito um estudo das APIs do OpenSocial, este capítulo apresenta a análise e a implementação de um aplicativo usando essas APIs. O aplicativo desenvolvido é um jogo da forca. 4.1 O JOGO Em um jogo da forca o objetivo é acertar uma palavra aleatória. Como dica é informado o número de letras dessa palavra. Para cada letra informada erroneamente, uma parte do corpo do enforcado é exibido na forca. O jogo termina quando a palavra é descoberta ou quando todas as partes do enforcado são exibidas. A Figura 6 mostra um esboço de como será o jogo. Figura 6 - Esboço do jogo da forca Fonte: Autoria própria. No aplicativo do jogo da forca a palavra aleatória é o nome de um dos amigos da rede social do jogador. O jogador tem 6 tentativas de acerto, antes que o Pontos: 0 Amigos salvos: 0 Amigos enforcados: 0 Convidar os amigos Novo amigo R
  • 74. 73 jogo termine, ou seja, antes que todas as partes do enforcado sejam desenhadas na forca. O jogo também conta com um sistema de pontuação. Para cada letra do nome do amigo que o jogador acertar, ele ganha um ponto. 4.2 ANÁLISE A análise do aplicativo utilizou alguns diagramas da linguagem de modelagem UML (Unified Modeling Language). A seguir são apresentados alguns casos de uso e um diagrama de atividades do jogo. 4.2.1 Casos de Uso Na Figura 7 é apresentado um diagrama com os principais casos de uso do jogo. Em seguida é feito a descrição de cada caso de uso. Figura 7 - Diagrama de casos de uso Fonte: Autoria própria. Caso de uso: Jogar Descrição: Corresponde ao início do jogo. Pré-condição: O jogador deve ter pelo menos um amigo. Trigger: O jogo começa quando o jogador clicar no botão "Jogar". Pós-condição: Ao fim do jogo, todas as letras que compõe o nome do amigo são exibidas. Uma atividade é criada para o jogador e a sua pontuação é salva.
  • 75. 74 Fluxo de eventos: 1. O sistema carrega um amigo aleatório do jogador. 2. O jogador clica no botão "Jogar". 3. Ao fim do jogo, as letras do nome do amigo são mostradas e o sistema cria uma atividade para o jogador informando o resultado do jogo, para que os seus amigos possam ver. A pontuação do jogador é salva. Caso de uso: Digitar letra Descrição: O jogador digita uma letra que acha que faz parte do nome do amigo. Pré-condição: O jogo deve ter sido iniciado. Trigger: O jogador digita uma letra do teclado. Pós-condição: A letra digitada é exibida. Se a letra digitada faz parte do nome do amigo, o jogador ganha um ponto. Caso contrário, uma parte do boneco é desenhada na forca. Fluxo de eventos: 1. O jogador digita uma letra. 2. O sistema exibe a letra digitada. O sistema verifica se a letra faz parte do nome do amigo. Em caso afirmativo, o jogador ganha um ponto, do contrário, o sistema desenha uma parte do boneco na forca. Caso de uso: Carregar novo amigo Descrição: Carregar um novo amigo aleatório para o jogador tentar adivinhar o nome. Pré-condição: O jogo deve ter sido iniciado. Trigger: O jogador clica no botão "Novo Amigo". Pós-condição: As letras digitadas são apagadas, bem como o boneco da forca. Fluxo de eventos: 3. O jogador clica no botão "Novo Amigo". 4. O sistema carrega um novo amigo aleatóriamente. As letras digitadas são apagadas. O boneco da forca é apagado também.
  • 76. 75 4.2.2 Diagrama de Atividades Na Figura 8 é exibido o diagrama de atividades, que representa os fluxos que o jogo pode ter. Figura 8 - Diagrama de atividades Fonte: Autoria própria. 4.3 IMPLEMENTAÇÃO Para o desenvolvimento do jogo, criou-se um projeto no Eclipse usando o assistente do OSDE. Foi escolhida a versão 0.9 do OpenSocial para esse projeto.
  • 77. 76 Foi decidido também separar a lógica do jogo em dois arquivos JavaScript. Um arquivo, chamado jodo-da-forca.js, possui a lógica relacionada somente ao jogo, como:  Capturar as teclas digitadas;  Verificar se elas fazem parte do nome do amigo;  Exibir as letras digitadas;  Exibir as partes do boneco na forca;  Incrementar a pontuação. Já a lógica referente as funções sociais, usando a API JavaScript do OpenSocial, fica no arquivo opensocial.js, que tem como responsabilidades:  Carregar a pontuação do jogador;  Salvar a pontuação do jogador;  Carregar um amigo aleatório para ser usado no jogo;  Criar atividades relacionadas ao desempenho do jogador, e que serão exibidas no seu perfil na rede social;  Permitir convidar outros amigos para jogar. Na Figura 9 são apresentados os arquivos que fazem parte do projeto criado no Eclipse. Entre eles estão:  style.css: contém a folha de estilos CSS usada na apresentação do jogo;  ALL_ALL.xml: pacote de mensagens usado na internacionalização;  img: pasta contendo as imagens usadas no jogo;  gadget.xml: o arquivo descritor do gadget. É o arquivo mais importante, pois é nele que estão todas as informações do jogo.
  • 78. 77 Figura 9 - Estrutura de arquivos que compõe o jogo Fonte: Captura de tela. Para hospedar os arquivos do jogo na Internet foi escolhido o serviço Google App Engine, que permite hospedar os arquivos gratuitamente na infraestrutura do Google. Os arquivos estão hospedados no endereço http://jogo-forca.appspot.com. O Quadro 58 mostra o elemento ModulePrefs do arquivo gadget.xml. Esse elemento guarda as informações referentes ao gadget. 1 <ModulePrefs 2 author="Cleber Rech" 3 author_email="clrech@gmail.com" 4 description="__MSG_descricao__" 5 screenshot="http://jogo-forca.appspot.com/img/screenshot.png" 6 thumbnail="http://jogo-forca.appspot.com/img/thumbnail.png" 7 title="__MSG_titulo__" 8 width="835"> 9 <Locale messages="http://jogo- forca.appspot.com/i18n/ALL_ALL.xml" /> 10 11 <Optional feature="maximize" /> 12 <Require feature="com.google.gadgets.analytics" /> 13 <Require feature="opensocial-0.9" /> 14 <Require feature="opensocial-data" /> 15 <Require feature="opensocial-templates"> 16 <Param name="process-on-server">true</Param> 17 </Require> 18 <Require feature="dynamic-height" /> 19 <Require feature="views" /> 20 </ModulePrefs> Quadro 58 - Elemento ModulePrefs do arquivo gadget.xml Nas linhas 4 e 7 do Quadro 58, para definir a descrição e o título do gadget, são feitas referências as strings presentes no pacote de mensagens, que é definido
  • 79. 78 na linha 9. Na linha 11, é declarado o recurso opcional maximize. Esse recurso é necessário para que o gagdet seja exibido na visão canvas no serviço de e-mail Gmail, que também permite ao usuário adicionar gadgets do OpenSocial. (OPENSOCIAL, 2010c, tradução própria). É declarado, na linha 12 do Quadro 58, o recurso necessário para que gadget carregue o script do Google Analytics, usado para coletar as estatísticas de visualização do gadget. Já na linha 16, é declarado um parâmetro necessário para que a visão profile do gadget seja habilitada na rede social Orkut. (OPENSOCIAL, 2010f, tradução própria). 4.3.1 Carregando um Amigo Todos os nomes dos amigos que o jogador deve tentar descobrir são carregados aleatóriamente. Infelizmente, a API JavaScript do OpenSocial não tem essa opção de carregar uma pessoa de maneira aleatória. Para que isso fosse possível, logo que a página do jogo termina de carregar, a função JavaScript jogo.carregarDonoAmigos do arquivo opensocial.js carrega o primeiro amigo do jogador. No Quadro 59 é mostrado como é criada essa requisição. 1 var idAmigos = opensocial.newIdSpec({ 2 'userId' : opensocial.IdSpec.PersonId.OWNER, 3 'groupId' : 'FRIENDS' 4 }); 5 6 var parametros = {}; 7 parametros[opensocial.DataRequest.PeopleRequestFields.FIRST] = 1; 8 parametros[opensocial.DataRequest.PeopleRequestFields.MAX] = 1; 9 var amigos = requisicao.newFetchPeopleRequest(idAmigos, parametros); Quadro 59 - Requisição para carregar o primeiro amigo Nas linhas 7 e 8 do Quadro 59 são usados dois parâmetros: opensocial.DataRequest.PeopleRequestFields.FIRST e opensocial.DataRequest.PeopleRequestFields.MAX. A função deles é, respectivamente, indicar o índice do primeiro item da requisição e o número máximo de itens a serem retornados. Como ambos possuem valor 1, somente o primeiro amigo será retornado. Isso é feito pois a resposta da requisição retorna, além dos
  • 80. 79 dados solicitados, o tamanho total da lista de amigos, através da função getTotalSize, como é mostrado na linha 2 do Quadro 60. 1 requisicao.send(function(resposta) { 2 numeroAmigos = resposta.get('amigos').getData().getTotalSize(); 3 }); Quadro 60 - Recuperando o número de amigos Tendo o número total de amigos do jogador, fica fácil carregar outro amigo aleatóriamente. Basta gerar um número aleatório entre 1 e o número total de amigos e passar como parâmetro na próxima requisição. Assim, a linha 7 do Quadro 59 pode ser substituída pela seguinte linha: parametros[opensocial.DataRequest.PeopleRequestFields.FIR ST] = Math.floor(Math.random() * numeroAmigos); Duas funções JavaScript foram usadas: Math.random, para gerar um número aleatório entre 0 e 1 (que é multiplicado pelo número de amigos), e Math.floor, para arredondar o resultado da multiplicação. 4.3.2 Visões O jogo possui três visões: canvas, home e profile. Para facilitar o desenvolvimento e eventual manutenção do código, optou-se por usar a mesma folha de estilos CSS e os mesmos arquivos JavaScript em todas as visões. Em uma abordagem diferente, poderiam ser criados arquivos diferentes para cada visão. Por exemplo, um arquivo CSS para a visão profile e outro arquivo CSS para a visão home. Outra vantagem de usar os mesmos arquivos para todas as visões é que não são necessárias novas requisições a outros arquivos quando uma visão diferente for carregada, pois os arquivos já foram carregados anteriormente e permanecerão no cache do navegador do usuário. No Quadro 61 é apresentado um trecho do arquivo gadget.xml.
  • 81. 80 1 <Content type="html" view="home,profile"> 2 <![CDATA[ 3 <link href="http://jogo-forca.appspot.com/css/style.css" rel="stylesheet" type="text/css" /> 4 5 <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min. js"></script> 6 <script type="text/javascript" src="http://jogo- forca.appspot.com/js/jogo-da-forca.js"></script> 7 <script type="text/javascript" src="http://jogo- forca.appspot.com/js/opensocial.js"></script> 8 ]]> 9 </Content> Quadro 61 - Trecho do arquivo gadget.xml Na linha 1 do Quadro 61 é definido que todo o conteúdo que está dentro do elemento Content será carregado nas visões profile, home e canvas. Ou seja, o arquivo da folha de estilo (linha 3) e os arquivos de JavaScript (linhas 5, 6 e 7) serão carregados em todas as visões do gadget. Entre esses arquivos está o arquivo do jQuery (linha 5), uma biblioteca JavaScript com funções úteis ao desenvolvimento nessa linguagem. A visão home e profile do gadget tem o mesmo conteúdo: exibem a pontuação do jogador, caso ele já tenha jogado o jogo, e também exibem um link que ao ser clicado leva o jogador para a visão canvas. Na Figura 10 é exibida a visão home (a mesma que a visão profile) do jogo no site iGoogle. Figura 10 - Visão home do jogo no iGoogle Fonte: Captura de tela.
  • 82. 81 No Quadro 62 pode-se ver o código das visões home e profile. 1 <Content type="html" view="home,profile"> 2 <![CDATA[ 3 <script xmlns:os="http://ns.opensocial.org/2008/markup" type="text/os-data"> 4 <os:PeopleRequest key="dono" userId="@owner" /> 5 <os:DataRequest key="pontuacao" method="appdata.get" userId="@owner" fields="*" /> 6 </script> 7 8 <script type="text/os-template" xmlns:os="http://ns.opensocial.org/2008/markup" xmlns:osx="http://ns.opensocial.org/2009/extensions"> 9 <div id="pontuacao" if="${pontuacao[dono.id]}"> 10 <div id="pontos">__MSG_pontos__ ${pontuacao[dono.id]['pontos']}</div> 11 <div id="estatisticas"> 12 __MSG_amigos_salvos__ ${pontuacao[dono.id]['salvos']}<br /> 13 __MSG_amigos_enforcados__ ${pontuacao[dono.id]['enforcados']} 14 </div> 15 </div> 16 17 <osx:NavigateToApp>__MSG_ir_para_jogo__</osx:NavigateToApp> 18 </script> 19 ]]> 20 </Content> Quadro 62 - Trecho da visão home e profile do arquivo gadget.xml Nas visões home e profile foram usadas duas tags do OpenSocial Markup Language (OSML). Como pode-se ver nas linhas 4 e 5 do Quadro 62, é feito uso de pipelining de dados para solicitar ao recipiente que sejam carregadas as informações do dono do gadget, através da tag <os:PeopleRequest>, e todos os dados que foram salvos anteriormente no gadget, través da tag <os:DataRequest>. Essas informações solicitadas são associadas a uma chave, que é descrita no atributo key das tags usadas. Na linha 9 do Quadro 62 é usado um recurso do OpenSocial Templates (OST): o atributo if. Ele é usado para indicar ao recipiente que o elemento <div>, que possui o atributo if, só deve ser exibido caso tenham sido carregados os dados salvos anteriormente pelo dono do gadget. No caso, esses dados estariam na variável pontuacao. A expressão usada foi pontuacao[dono.id], pois os dados salvos pelos gadgets ficam associados ao ID um usuário. Na linha 10 do Quadro 62 a seguinte expressão é usada:
  • 83. 82 ${pontuacao[dono.id]['pontos']} Essa expressão instrui ao recipiente exibir o dado pontos que foi salvo para usuário com o ID dono.id. E por último, na linha 17 do Quadro 62, é usada a tag <osx:NavigateToApp>, que faz com que o recipiente crie um link para a visão canvas do gadget. É na visão canvas do gadget que é encontrado o jogo propriamente dito. Na Figura 11, é exibida a visão canvas do jogo no iGoogle. Figura 11- Visão canvas do jogo no iGoogle Fonte: Autoria própria. Como pode-se perceber na Figura 10, existe um botão onde se lê "Clique aqui para começar a jogar!". Este botão foi necessário, pois, para que o código JavaScript do jogo possa capturar as teclas digitadas, a página do navegador do usuário onde encontra-se o jogo deve estar com o foco. Como o gagdet é exibido dentro de um elemento iframe, que seria uma página dentro de outra página, ele não tem o foco assim que o jogo é carregado. A partir do momento em que o usuário clica no botão, a página onde encontra-se o jogo passa a receber o foco, e com isso consegue-se capturar as teclas digitadas pelo usuário.
  • 84. 83 A visão canvas consiste apenas de código HTML. Todo o comportamento dinâmico do jogo é feito pelas funções JavaScript. Na Figura 12 é exibido o estado do jogo logo após o usuário clicar no botão que aparece na Figura 11. Nesse momento, aparecem os espaços em branco correspondentes as letras do nome do amigo do jogador. Figura 12 - Visão canvas do jogo Fonte: Autoria própria. O jogo pode terminar de duas maneiras: com o jogador acertando todas as letras do nome do amigo, como mostrado no lado esquerdo da Figura 13, ou quando após 6 tentativas o usuário não consegue descobrir o nome do amigo, como no lado direito da Figura 13.
  • 85. 84 Figura 13 - Visão do jogo quando o usuário acerta ou erra o nome do amigo Fonte: Autoria própria. Logo após o fim do jogo, o jogador tem a opção de começar novamente, mas com um novo amigo escolhido aleatóriamente. Para isso, ele deve clicar no botão "Novo Amigo", que aparece na cor verde na Figura 13. 4.3.3 Atividades e Compartilhamento Logo após o término do jogo, é criada uma atividade informando o resultado do jogo, bem como a pontuação total do jogador. Essa atividade criada pelo gadget geralmente será exibida no perfil do usuário do recipiente. Mas, conforme o recipiente do gadget, ela pode ser exibida em outros locais. Ao usuário é dada a opção de excluir, a qualquer momento, a atividade criada. A Figura 14 mostra uma atividade criada no Orkut, e que é exibida no perfil do dono do gadget.
  • 86. 85 Figura 14 - Atividade criada pelo jogo no Orkut Fonte: Autoria própria. Como pode ser visto no canto superior direito da Figura 11, há um botão com o texto "Convidar os amigos". Ao ser clicado, esse botão chama uma função JavaScript, que dará ao jogador a opção de convidar outras pessoas. Para esse fim específico, a API JavaScript do OpenSocial possui a função opensocial.requestShareApp, que exibe ao usuário do gadget uma interface em que ele pode selecionar os amigos que ele deseja que usem o gadget também. No entanto, essa função não está disponível em todos os recipientes, como o Orkut, por exemplo. Nos recipientes em que a função opensocial.requestShareApp não está disponível, optou-se por usar a função opensocial.requestSendMessage da API JavaScript do OpenSocial. Essa função permite enviar um e-mail, informando sobre a existência do gagdet, para as pessoas que o usuário indicar. A única forma de saber se a função opensocial.requestShareApp está disponível é verificar qual o recipiente do gadget e saber de antemão se essa função funciona nele. Isso pode ser feito usando a função opensocial.getEnvironment().getDomain, que retorna o nome do domínio do recipiente. 4.3.4 Adicionando o Aplicativo O jogo criado está disponível na rede social Orkut e no iGoogle, através dos seguintes endereços:  Orkut: http://orkut.com/Application?appId=332749754900
  • 87. 86  iGoogle: http://www.google.com/ig/directory?url=jogo- forca.appspot.com/gadget.xml Normalmente, antes que o usuário possa usar o aplicativo, as redes sociais exigem que ele confirme a instalação do aplicativo. Embora outras redes sociais não foram citadas, nada impede que o aplicativo possa ser usado em outras redes, pois algumas permitem que o aplicativo seja usado mesmo não estando disponível na lista de aplicativos da rede social. Para isso, basta saber o endereço do arquivo XML descritor do gadget. No caso do jogo que foi desenvolvido, o endereço do arquivo XML é o seguinte: http://jogo-forca.appspot.com/gadget.xml. O código-fonte do gadget também está disponível na Internet para que qualquer pessoa possa vê-lo. Ele foi hospedado no serviço Google Code e está disponível no seguinte endereço: http://code.google.com/p/jogo-da-forca-opensocial/source/browse/#svn/trunk
  • 88. 87 5 CONSIDERAÇÕES FINAIS A criação de um aplicativo social tornou-se uma tarefa fácil. O OpenSocial veio justamente para facilitar esse desenvolvimento. A intenção da sua criação é permitir que o programador do aplicativo possa focar-se nas funcionalidades do mesmo, e não preocupar-se com diferentes APIs em diferentes redes sociais. Mas nem sempre é isso que acontece. Segundo Grewe (2009, p. 119, tradução própria), infelizmente a natureza nova da programação nas redes sociais faz com que nem todos os recipientes suportem o padrão OpenSocial com a mesma observância. Por exemplo, os dados do usuário que está visualizando o aplicativo, em algumas redes, só serão retornados caso o mesmo tenha o aplicativo instalado. Esse exemplo vale para a rede social Orkut. A maior parte da documentação do OpenSocial é encontrada na Internet. Existem pouquíssimos livros que tratam do assunto, e como as informações nessa área mudam rapidamente, os livros acabam se tornando desatualizados em pouco tempo. Por isso, o desenvolvedor deve estar sempre atento as novidades e mudanças que ocorrem, seja através de blogs, grupos de discussão ou nos próprios sites das redes sociais. O aplicativo que foi desenvolvido, na forma de um jogo, estará disponível para qualquer usuário das redes sociais onde ele foi adicionado. Caso o jogo tenha uma popularidade considerável, a intenção é monetizá-lo, usando serviços de terceiros para inserir propagandas no jogo, afinal, a maioria dos aplicativos sociais são criados com essa finalidade. A intenção também é continuar melhorando o jogo, baseado em sugestões e idéias. Para isso, os jogadores têm a disposição um canal de comunicação, onde podem enviar mensagens. Para trabalhos futuros, fica a sugestão de um estudo mais aprofundado das APIs do Facebook, que atualmente é o maior concorrente do OpenSocial, bem como pesquisas cujo intuito é de explorar o potencial, possivelmente, comercial e de marketing das redes sociais.
  • 89. 88 REFERÊNCIAS AJUDA DO GOOGLE APPS ADMINISTRADOR. Gerenciar configurações de OAuth. Disponível em <http://www.google.com/support/a/bin/answer.py?hl=br&answer=61017>. Acesso em 28 jul. 2010. ALEXA. Alexa Top 500 Global Sites. Disponível em <http://www.alexa.com/topsites>. Acesso em 15. fev. 2010a. ______. Top Sites in Brazil. Disponível em <http://www.alexa.com/topsites/countries/BR>. Acesso em 15. fev. 2010b. API DE GADGETS. API de gadgets. Disponível em <http://code.google.com/intl/pt- BR/apis/gadgets>. Acesso em: 16 abr. 2010a. ______. API Reference. Disponível em <http://code.google.com/intl/pt- BR/apis/gadgets/docs/reference>. Acesso em: 16 abr. 2010b. ______. Gadgets e internacionalização (i18n). Disponível em <http://code.google.com/intl/pt-BR/apis/gadgets/docs/i18n.html>. Acesso em: 30 ago. 2010c. ______. Primeiros Passos: API de gadgets.*. Disponível em <http://code.google.com/intl/pt-BR/apis/gadgets/docs/gs.html>. Acesso em: 16 abr. 2010d. ______. Referência XML de gadgets. Disponível em <http://code.google.com/intl/pt-BR/apis/gadgets/docs/reference.html>. Acesso em: 16 abr. 2010e. COSTA, Carlos J. Desenvolvimento para Web. Lisboa: Lusocrédito Ltda, 2007.
  • 90. 89 CHENG, Albert. OpenSocial Development Environment 1.0 Released. Publicado em 23 jun. 2010. Disponível em <http://igoogledeveloper.blogspot.com/2010/06/opensocial-development- environment-10.html>. Acesso em: 02 set. 2010. FACEBOOK. Documentação - Desenvolvedores do Facebook. Disponível em <http://developers.facebook.com/docs>. Acesso em: 14 set. 2010a. ______. Estatísticas. Disponível em <http://www.facebook.com/press/info.php?statisticst>. Acesso em: 14 set. 2010b. ______. Resumo de informações. Disponível em <http://www.facebook.com/press/info.php?factsheet>. Acesso em: 14 set. 2010c. FARIA, Rogério Amorim de. Treinamento Avançado em XML. São Paulo: Digerati Books, 2005. FERLA, Luiz Alberto. O que são Redes Sociais? Talk:2, o Blog da Talk. Publicado em 16 dez. 2008. Disponível em <http://www.talk2.com.br/artigos-e-white-papers/o- que-sao-redes-sociais>. Acesso em 20. fev. 2010. FLANAGAN, David. Javascript - o Guia Definitivo. 4. ed. São Paulo: Bookman, 2004. GONÇALVES, Antonio. Beginning Java EE 6 Platform with GlassFish 3: from novice to professional. Nova Iorque: Apress, 2009. GREWE, Lynne. OpenSocial Network Programming. Indianapolis: Wrox, 2009. KIRKPATRICK, David. Facebook's plan to hook up the world. CNNMoney.com. Publicado em 29 maio 2007. Disponível em <http://money.cnn.com/2007/05/24/technology/facebook.fortune>. Acesso em: 13 set. 2010.
  • 91. 90 OPENSOCIAL. Containers. Disponível em <http://wiki.opensocial.org/index.php?title=Containers&oldid=4368>. Acesso em: 25 fev. 2010a. ______. Gadgets.i18n (v0.9). Disponível em <http://wiki.opensocial.org/index.php?title=Gadgets.i18n_(v0.9)&oldid=3506>. Acesso em: 30 ago. 2010b. ______. Gmail. Disponível em <http://wiki.opensocial.org/index.php?title=Gmail&oldid=2045>. Acesso em: 20 out. 2010c. ______. Guia do desenvolvedor da API do OpenSocial. Disponível em <http://code.google.com/intl/pt-BR/apis/opensocial/docs/0.8/devguide.html>. Acesso em 20 abr. 2010d. ______. Perguntas freqüentes. Disponível em <http://code.google.com/intl/pt- BR/apis/opensocial/faq.html>. Acesso em 20 abr. 2010e. ______. Orkut. Disponível em <http://wiki.opensocial.org/index.php?title=Orkut&oldid=5551>. Acesso em: 20 out. 2010f. ______. Referência da API do OpenSocial. Disponível em <http://code.google.com/intl/pt-BR/apis/opensocial/docs/0.8/reference/>. Acesso em 20 abr. 2010g. ______. Social Design Best Practices. Disponível em <http://wiki.opensocial.org/index.php?title=Social_Design_Best_Practices&oldid=324 8>. Acesso em: 25 fev. 2010g. OPENSOCIAL AND GADGETS SPECIFICATION GROUP. OpenSocial RESTful Protocol Specification v0.9. Publicado em 15 abr. 2009. Disponível em <http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/REST- API.html>. Acesso em: 06 ago. 2010.
  • 92. 91 ______. OpenSocial Core Gadget Specification 1.0. Publicado em mar. 2010a. Disponível em <http://opensocial- resources.googlecode.com/svn/spec/1.0/Core-Gadget.xml>. Acesso em: 31 ago. 2010. ______. OpenSocial Social Gadget Specification 1.0. Publicado em mar. 2010b. Disponível em <http://opensocial- resources.googlecode.com/svn/spec/1.0/Social-Gadget.xml>. Acesso em: 31 ago. 2010. ______. OpenSocial Specification 1.0. Publicado em mar. 2010c. Disponível em <http://opensocial-resources.googlecode.com/svn/spec/1.0/OpenSocial- Specification.xml>. Acesso em: 20 out. 2010. ______. OpenSocial Specification Release Notes. Publicado em out. 2010d. Disponível em <http://opensocial- resources.googlecode.com/svn/spec/1.1/OpenSocial-Specification-Release- Notes.xml>. Acesso em: 20 out. 2010. ______. OpenSocial Templating Specification 1.0. Publicado em fev. 2010e. Disponível em <http://opensocial- resources.googlecode.com/svn/spec/draft/OpenSocial-Templating.xml>. Acesso em: 25 ago. 2010. ORKUT. In: WIKIPÉDIA, a enciclopédia livre. Flórida: Wikimedia Foundation, 2010. Disponível em: <http://pt.wikipedia.org/w/index.php?title=Orkut&oldid=18967177>. Acesso em: 22 fev. 2010a. ______. Dados demográficos. Disponível em <http://www.orkut.com.br/Main#MembersAll>. Acesso em: 22 fev. 2010b. ______. Diretório de aplicativos. Disponível em <http://www.orkut.com.br/Main#AppDirectory?dirFilters=featured>. Acesso em: 24 out. 2010c.
  • 93. 92 ______. Guia do Desenvolvedor do Orkut (API do OpenSocial v0.8.1). Disponível em <http://code.google.com/intl/pt-BR/apis/orkut/docs/orkutdevguide.html>. Acesso em 20 abr. 2010d. REDE SOCIAL VIRTUAL. In: WIKIPÉDIA, a enciclopédia livre. Flórida: Wikimedia Foundation, 2010. Disponível em: <http://pt.wikipedia.org/w/index.php?title=Rede_social_virtual&oldid=18871083>. Acesso em: 20 fev. 2010. ROOS, Dave. HowStuffWorks - Como funcionam as redes sociais online. Publicado em 01 nov. 2007 (atualizado em 17 abr. 2008). Disponível em <http://informatica.hsw.uol.com.br/redes-sociais-online.htm>. Acesso em 20 fev. de 2010. SAMPAIO, Cleuton. Web 2.0 e Mashups: Reinventando a Internet. Rio de Janeiro: Brasport, 2007. SHINDIG, 2010. Welcome To Apache Shindig! Disponível em <http://shindig.apache.org>. Acesso em: 08 set. 2010. YANO, Célio. Facebook alcança 500 milhões de usuários. INFO Online. São Paulo: 21 jul. 2010. Disponível em <http://info.abril.com.br/noticias/tecnologia- pessoal/facebook-alcanca-500-milhoes-de-usuarios-21072010-29.shl>. Acesso em: 13 set. 2010. ZMOGINSKI, Felipe. Open Social já dá 600 apps ao orkut. INFO Online. São Paulo: 29 out. 2008. Disponível em <http://info.abril.com.br/aberto/infonews/102008/29102008-34.shl>. Acesso em: 20 fev. 2010.
  • 94. 93 ANEXOS
  • 95. 94 ANEXO A – LISTA DE RECIPIENTES DO OPENSOCIAL Recipiente Versão Atual Usuários Ativos Tráfigo Geográfico Cyworld v0.8 Coréia: 86.4% iGoogle v0.8 Avatars United v0.8.1 América do Norte: 31% Oeste da Europa: 58% goo Home v0.8 2,7 milhões/dia Japão: 96.5% mixi v0.8 5,4 mihões/dia Japão: 96.0% hi5 v0.8 53 mihões/mês México:16.5% Tailândia: 15.3% iWiW v0.8 3,2 mihões/mês Hungria: 98% LinkedIn v0.8 20 mihões/mês Estados Unidos: 47% Índia: 15% Lonely Planet v0.8 1 mihão/mês Estados Unidos: 22.3% MySpace v0.9 100 mihões/mês Estados Unidos: 66% Alemanha: 4% orkut v0.8 5,4 mihões/mês Brasil: 50% Índia 17% Netlog v0.8 41 mihões/mês Itália: 25% Bélgica: 9% QuePasa v0.8 < 100 mil/dia México: 22% Estados Unidos: 11% Socialtext v0.8 < 10 mil/dia Estados Unidos: 52% Webon v0.8 < 1 mil/dia RenRen v0.9 4 milhões/dia China: 91% Yahoo! v0.8 126 milhões/mês Estados Unidos: 35% Índia: 9% Yonja v0.8 < 100 mil/dia Turquia: 86.3% Webjam v0.8 < 10 mil/dia Estados Unidos: 29% Reino Unido: 28% itimes v0.7 < 100 mil/dia Índia: 75% 51.com v0.7 3,2 milhões/dia China 96% Freebar v0.7 < 50 mil/dia Itália: 92% Friendster v0.7 2,4 milhões/mês Indonésia: 30% Filipinas: 23% IDtail v0.7 < 10 mil/dia Coréia do Sul: 90%+ Mail.ru v0.7 12 milhões/dia Rússia: 72% Cazaquistão: 10% Hyves v0.7 4 milhões/dia Holanda: 95%
  • 96. 95 Recipiente Versão Atual Usuários Ativos Tráfigo Geográfico Ning v0.7 6,8 milhões/mês Estados Unidos: 44% Índia: 7% YiQi v0.7 < 50 mil/dia China: 90% FanBox v0.7 2 milhões/mês Estados Unidos: 58% phpFox v0.8 < 50 mil/dia Estados Unidos: 34% Google Friend Connect v0.8 ATutor v0.8 < 8 mil/dia Sonico v0.8 Recipiente Versão Atual Usuários Ativos Tráfigo Geográfico XING v0.8 VZ-Netzwerke v0.81 Fonte: OpenSocial (2010a).
  • 97. 96 ANEXO B – CLASSES DA API DE GADGETS Classe Descrição Métodos Prefs Fornece acesso às preferências do usuário, as dimensões do módulo e as mensagens.  getArray: recupera uma preferência de matriz;  getBool: recupera uma preferência booleana;  getCountry: obtém o país atual;  getFloat: recupera uma preferência de ponto flutuante;  getInt: recupera uma preferência de número inteiro;  getLang: obtém o idioma atual que o gadget deve usar na visualização;  getMsg: obtém uma mensagem não formatada;  getString: recupera uma preferência de string;  set: armazena uma preferência;  setArray: armazena uma preferência de matriz. io Fornece funções de recuperação de conteúdo remoto.  encodeValues: converte um objeto de entrada em uma string de dados codificada como uma URL;  getProxyUrl: obtém a versão proxy de uma URL passada;  makeRequest: obtém o conteúdo a partir da URL fornecida. json Fornece operações de conversão de objetos de e para JSON.  parse: analisa uma string JSON, produzindo um valor JavaScript;  stringify: converte um valor JavaScript em uma string JSON. util Fornece funções de utilidade de uso geral.  escapeString: cria códigos de escape para os dados inseridos, usando entidades HTML para garantir maior segurança;  getFeatureParameters: obtém os parâmetros do recurso;  getUrlParameters: obtém os parâmetros da URL;  hasFeature: retorna se o recurso atual é suportado;  makeClosure: cria um invólucro adequado para ser passado como um retorno de chamada;  registerOnLoadHandler: registra uma função para ser invocada após o carregamento do gadget;  unescapeString: inverte os códigos de escape de uma string.
  • 98. 97 Classe Descrição Métodos MiniMessage Usado para criar mensagens que aparecerão para o usuário dentro do gadget.  createDismissibleMessage: cria uma mensagem que pode ser ocultada.  createStaticMessage: cria uma mensagem estática que pode ser ocultada.  createTimerMessage: cria uma mensagem que é exibida por um número especificado de segundos.  dismissMessage: oculta a mensagem especificada. Tab Classe para representar uma aba.  getCallback: retorna a função de retorno de chamada, executada quando a aba é selecionada.  getContentContainer: retorna o elemento HTML no qual o conteúdo da aba é visualizado.  getIndex: retorna o índice da aba.  getName: retorna o marcador da aba na forma de uma string.  getNameContainer: retorna o elemento HTML que contém o marcador da aba. TabSet Classe que pode ser usada pelos gadgets para criar abas.  addTab: adiciona uma nova aba;  alignTabs: define o alinhamento das abas;  displayTabs: exibe ou oculta abas e todo o conteúdo associado a elas;  getHeaderContainer: retorna o elemento do cabeçalho da aba;  getSelectedTab: retorna o objeto da aba selecionada no momento;  getTabs: retorna uma matriz de todos os objetos das abas existentes;  removeTab: remove uma aba do índice de abas e todo o conteúdo associado a ela;  setSelectedTab: seleciona a aba e ativa a função de retorno de chamada da aba, se existir;  swapTabs: troca as posições das abas. flash Integra conteúdo Flash nos gadgets.  embedCachedFlash: injeta um arquivo Flash com cache na página;  embedFlash: injeta um arquivo Flash na página;  getMajorVersion: detecta o Flash Player e sua versão principal. rpc Fornece operações para realizar chamadas RPC (Remote Procedure Call).  call: chama um serviço RPC;  register: registra um serviço RPC;  registerDefault: registra uma função padrão para processar todas as chamadas RPC desconhecidas, que falham sem aviso por padrão;  unregister: cancela o registro de um serviço RPC;  unregisterDefault: cancela a função de processamento padrão.
  • 99. 98 Classe Descrição Métodos views Fornece operações para lidar com visualizações.  getCurrentView: retorna a visualização atual;  getParams: retorna os parâmetros passados ao gadget para esta visualização;  getSupportedViews: retorna todas as visualizações suportadas;  requestNavigateTo: Tenta ir para uma visualização diferente. skins Fornece operações para obter informações de exibição sobre a skin exibida atualmente.  getProperty: obtém a propriedade de exibição mapeada para a chave em questão. window Fornece operações para obter informações e alterar a janela na qual o gadget é colocado.  adjustHeight: ajusta a altura do gadget  getViewportDimensions: detecta as dimensões internas de um frame.  setTitle: define o título do gadget. Quadro - Classes da API de gadgets Fonte: API de Gadgets (2010d).