Construindo Apps Sociais com OpenSocial APIs

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
(Convidado)
Prof. Itamar Pena Nieradka
(Convidado)
Prof. Juliano Rodrigo Lamb
(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
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
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.
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.
2 <Module>
3 <ModulePrefs title="Olá Mundo!">
5 </ModulePrefs>
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
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
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.
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
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
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
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
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
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.
2 <Module>
3 <ModulePrefs title="Listar amigos">
5 </ModulePrefs>
7 <![CDATA[
8 <script type="text/javascript">
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
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
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
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,
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,
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.

Construindo Apps Sociais com OpenSocial APIs

Construindo Apps Sociais com OpenSocial APIs

Recomendados

Recomendados

Más contenido relacionado

Similar a Construindo Apps Sociais com OpenSocial APIs

Similar a Construindo Apps Sociais com OpenSocial APIs (20)

Construindo Apps Sociais com OpenSocial APIs