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
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
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)
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.
“A mente que se abre a uma nova idéia
jamais voltará ao seu tamanho original.”
(EINSTEIN, Albert)
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.
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.
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
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
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
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
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
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
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.
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
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.
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.
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
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:
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.
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;
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).
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
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.
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).
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.
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.
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
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
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
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.
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;
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.
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.
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).
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
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
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
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:
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.
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.
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
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.
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.
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
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;
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;
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.
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.
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.
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
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
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.
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
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
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
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.
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}.
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.
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">
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
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.
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
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}" />
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.
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/listaCores.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:
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).
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
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'
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}" />
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
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.
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
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.
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.
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.
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.
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="[email protected]"
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
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
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.
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.
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:
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.
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.
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.
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
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
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.
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.
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.
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=3248>. 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.
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.
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.
93
ANEXOS
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%
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).
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.
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.
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).