UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ – UTFPR
CURSO SUPERIOR DE TECNOLOGIA EM DESENVOLVIMENTO DE SISTEMAS
DE INFORMAÇ...
CLEBERSANDER RECH
CONSTRUINDO APLICATIVOS SOCIAIS UTILIZANDO AS APIS DO OPENSOCIAL
Trabalho de Diplomação apresentado à
di...
Ministério da Educação
Universidade Tecnológica Federal do Paraná
Gerência de Ensino
Curso Superior de Tecnologia em desen...
AGRADECIMENTOS
A Deus, autor da vida, por ter me permitido concluir essa caminhada.
Aos meus pais Marina e Constantino, pe...
“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 Conclu...
ABSTRACT
RECH, Clebersander Rech. Building Social Applications Using OpenSocial APIs.
2010. Trabalho de Conclusão de Curso...
LISTA DE FIGURAS
FIGURA 1 - ARQUITETURA ENTRE A REDE SOCIAL E O APLICATIVO ...................27
FIGURA 2 - ARQUITETURA DE...
LISTA DE QUADROS
QUADRO 1 - APLICATIVOS MAIS POPULARES DO ORKUT......................................17
QUADRO 2 - DATAS D...
QUADRO 40 - REPRESENTAÇÃO DE UMA PESSOA NO FORMATO JSON .............57
QUADRO 41 - REPRESENTAÇÃO DE UMA PESSOA NO FORMATO...
LISTA DE ABREVIATURAS E SIGLAS
AJAX Asynchronous Javascript And XML
API Application Programming Interface
CSS Cascading St...
SUMÁRIO
1 INTRODUÇÃO.........................................................................................................
3.5.3 Variáveis..............................................................................................................
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 ...
14
1.1 OBJETIVOS
Apresentar um estudo sobre a construção de aplicativos sociais utilizando as
APIs do OpenSocial.
1.1.1 Ob...
15
relacionamentos entre si e ainda tem a capacidade de disponibilizar e exibir
atualizações sobre as ações das pessoas.
O...
16
2 REDES SOCIAIS VIRTUAIS
Segundo Ferla (2008):
"As redes sociais são formadas por indivíduos com interesses, valores e
...
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...
18
suportando o OpenSocial têm suporte a última versão. (GREWE, 2009, p. 55,
tradução própria).
Toda a documentação do Ope...
19
 Visão "canvas": esta visão é definida como a "tela cheia" do aplicativo
sendo executado. Claro que ela ainda estará d...
20
2.2.2 Melhores Práticas
De acordo com OpenSocial (2010g, tradução própria), existem algumas
recomendações na construção...
21
 Construir comunidades: ao aumentar as pequenas comunidades
tornando-as acessíveis, um aplicativo pode fornecer uma fu...
22
1 <?xml version="1.0" encoding="UTF-8" ?>
2 <cor nome="azul" />
3 </elemento>
Quadro 3 - Exemplo da linguagem de marcaç...
23
operador &&. Entretanto, a similaridade acaba nessa semelhança sintática.
JavaScript é uma linguagem não-tipada, ou sej...
24
2.2.3.5 REST
Para que os clientes possam interagir com os servidores dos recipientes
OpenSocial externamente aos gadget...
25
2.2.3.7 Apache Shindig
Pode-se dizer que o OpenSocial também é uma especificação, que deve ser
implementada pelos recip...
26
2.2.3.8 OSDE
O OSDE (OpenSocial Development Environment) é um plugin para o Eclipse
IDE (Integrated Development Environ...
27
Figura 1 - Arquitetura entre a rede social e o aplicativo
Fonte: Adaptado de Grewe (2009, p. 58, tradução própria).
Com...
28
os dados no seu próprio banco de dados, ou talvez precisem de outros recursos ou
serviços em seus servidores. Nesse mod...
29
2.2.5 Arquitetura de um Aplicativo
Um aplicativo de rede social baseado na API JavaScript do OpenSocial pode
ser visto ...
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 exem...
31
3 APLICATIVOS DO OPENSOCIAL
Um aplicativo do OpenSocial é definido em um arquivo XML, também
chamado de gadget. Esse ar...
32
 Preferências do usuário: representada pela tag UserPrefs, permite
que sejam definidas configurações para o gadget pel...
33
Atributo Descrição
screenshot String opcional que fornece a URL de uma captura de tela do gadget. O
formato preferencia...
34
Atributo Descrição
view String opcional. Somente gadgets OpenSocial. Indica em qual visualização
do recipiente OpenSoci...
35
Para cada recurso específico que se deseja utilizar, é adicionado um
elemento Require, com o atributo feature indicando...
36
pacotes de mensagens específicos ao local, os quais você pode adicionar à
especificação do seu gadget. Dessa forma, seu...
37
atributo messages indica a URL do arquivo do pacote de mensagens. O atributo
country também pode ser usado para definir...
38
adicionar o elemento <Require feature="opensocial-i18n" /> na seção de
preferências do gadget. As funções JavaScript se...
39
<Require feature="osapi">
Os exemplos em JavaScript serão apresentados usando a API JavaScript
tradicional e a OSAPI.
A...
40
Resumo da função Detalhes da função
Boolean isOwner() Retorna true (verdadeiro) se este objeto de pessoa representar o
...
41
Campo Descrição
NICKNAME Uma string representando o apelido da pessoa.
PHONE_NUMBERS Telefones associados à pessoa, esp...
42
Campo do Orkut Campo do OpenSocial Política de acesso do Orkut
Data de
nascimento
DATE_OF_BIRTH Informações pessoais
id...
43
Caso se queira requisitar os dados do visualizador do aplicativo, seria
necessário criar o mesmo objeto da seguinte for...
44
tipo opensocial.Idspec, que havia sido criado na linha 2. Isso instrui o recipiente
a retornar uma coleção de objetos r...
45
pessoas para criar uma lista em HTML com o nome de exibição das pessoas, que
por último é escrita na tela (linha 13).
U...
46
 Chamar a função send do objeto opensocial.DataRequest, passando
uma função de retorno de chamada (callback);
 Criar ...
47
 Chamar a função opensocial.requestSendMessage passando como
parâmetros o destinatário da mensagem e a mensagem propri...
48
1 var parametros = {};
2 parametros[opensocial.Message.Field.TITLE] = 'Título do e-mail';
3 parametros[opensocial.Messa...
49
Campo Descrição
APP_ID Uma string que especifica o aplicativo ao qual esta atividade está
associada.
BODY Uma string qu...
50
solicitada prioridade baixa, a chamada não fará nada se o aplicativo não tiver
permissão para a criação de atividades.
...
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...
52
1 var dados = {};
2 dados.cor = 'verde';
3 osapi.appdata.update({ userId: '@viewer', data: dados });
Quadro 33 - Gravan...
53
1 function recuperarDados() {
2 var idSpec = opensocial.newIdSpec({ 'userId' : 'OWNER' });
3 var requisicao = opensocia...
54
3.4 API RESTFUL DO OPENSOCIAL
Como alternativa a API JavaScript no lado do cliente existe a API RESTful,
que permite um...
55
No Quadro 38, estão representados:
 startIndex: o índice do primeiro resultado retornado na resposta;
 itemsPerPage: ...
56
 @app: para representar a aplicação que está fazendo a solicitação.
A seguir são apresentados os fragmentos que podem ...
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial
Upcoming SlideShare
Loading in …5
×

Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial

860
-1

Published on

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.

Published in: Internet
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
860
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
21
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial

  1. 1. UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ – UTFPR CURSO SUPERIOR DE TECNOLOGIA EM DESENVOLVIMENTO DE SISTEMAS DE INFORMAÇÃO CLEBERSANDER RECH CONSTRUINDO APLICATIVOS SOCIAIS UTILIZANDO AS APIS DO OPENSOCIAL TRABALHO DE DIPLOMAÇÃO MEDIANEIRA 2010
  2. 2. CLEBERSANDER RECH CONSTRUINDO APLICATIVOS SOCIAIS UTILIZANDO AS APIS DO OPENSOCIAL Trabalho de Diplomação apresentado à disciplina de Trabalho de Diplomação, do Curso Superior de Tecnologia em Desenvolvimento de Sistemas de Informação da Universidade Tecnológica Federal do Paraná – UTFPR, como requisito parcial para obtenção do título de Tecnólogo. Orientador: Prof. Romualdo Rubens de Freitas. MEDIANEIRA 2010
  3. 3. Ministério da Educação Universidade Tecnológica Federal do Paraná Gerência de Ensino Curso Superior de Tecnologia em desenvolvimento de Sistemas de Informação TERMO DE APROVAÇÃO Construindo Aplicativos Sociais Utilizando as APIs do OpenSocial Por Clebersander Rech Este Trabalho de Diplomação (TD) foi apresentado às 14:00 h do dia 18 de novembro de 2010 como requisito parcial para a obtenção do título de Tecnólogo no Curso Superior de Tecnologia em desenvolvimento de Sistemas de Informação, da Universidade Tecnológica Federal do Paraná, Campus Medianeira. Os acadêmicos foram argüidos pela Banca Examinadora composta pelos professores abaixo assinados. Após deliberação, a Banca Examinadora considerou o trabalho aprovado com louvor e mérito. Prof. Romualdo Rubens de Freitas UTFPR – Campus Medianeira (Orientador) Prof. Fernando Schütz UTFPR – Campus Medianeira (Convidado) Prof. Itamar Pena Nieradka UTFPR – Campus Medianeira (Convidado) Prof. Juliano Rodrigo Lamb UTFPR – Campus Medianeira (Responsável pelas atividades de TCC)
  4. 4. AGRADECIMENTOS A Deus, autor da vida, por ter me permitido concluir essa caminhada. Aos meus pais Marina e Constantino, pela compreensão e auxílio prestado. E ao resto da minha família, em especial os meus irmãos Max e Willian. Ao meu professor orientador Romualdo pelo auxílio prestado durante o desenvolvimento desse trabalho. Também a todos os professores que de uma forma ou de outra contribuíram com o seu conhecimento ao longo da faculdade. Aos meus ex-colegas de faculdade e de trabalho, pela troca de conhecimentos e pela convivência. E aos demais de também contribuíram para a realização deste trabalho.
  5. 5. “A mente que se abre a uma nova idéia jamais voltará ao seu tamanho original.” (EINSTEIN, Albert)
  6. 6. RESUMO RECH, Clebersander Rech. Construindo Aplicativos Sociais Utilizando as APIs do Opensocial. 2010. Trabalho de Conclusão de Curso, Universidade Tecnológica Federal do Paraná. Medianeira, 2010. Este trabalho apresenta um estudo sobre a construção de aplicativos sociais usando as APIs do OpenSocial. Faz uma breve abordagem sobre a história do OpenSocial e lista os recipientes que suportam as APIs. Mostra a anatomia de um aplicativo social, bem como as técnicas que podem ser usadas para o seu desenvolvimento. Apresenta um estudo teórico sobre as APIs que compõe o OpenSocial, tanto a API JavaScript quanto a API para serviços RESTful e em seguida aborda o desenvolvimento usando o OpenSocial Templates (OST). Promove uma comparação entre as APIs do OpenSocial e da rede social Facebook. Finalmente, apresenta os detalhes de implementação de um aplicativo social na forma de um jogo. Palavras-chave: OpenSocial. Aplicativos sociais. Redes sociais.
  7. 7. ABSTRACT RECH, Clebersander Rech. Building Social Applications Using OpenSocial APIs. 2010. Trabalho de Conclusão de Curso, Universidade Tecnológica Federal do Paraná. Medianeira, 2010. This paper presents a study on how to build social applications using OpenSocial APIs. Shows a brief view of OpenSocial's history and lists the containers that support the APIs. Shows the anatomy of a social application, as well as the techniques that can be used for its development. Presents a theoretical study about OpenSocial's JavaScript API as well as the API for RESTful services and then talks about using OpenSocial Templates (OST) for software development. Promotes a comparison between OpenSocial's APIs and Facebook's social network API. Finally, presents the implementation details of a social game application. Keywords: OpenSocial. Social applications. Social Networks.
  8. 8. LISTA DE FIGURAS FIGURA 1 - ARQUITETURA ENTRE A REDE SOCIAL E O APLICATIVO ...................27 FIGURA 2 - ARQUITETURA DE UM APLICATIVO SOCIAL COMPLETAMENTE BASEADO NO SERVIDOR .................................................................................28 FIGURA 3 - CAMADAS DE UM APLICATIVO OPENSOCIAL E COMUNICAÇÕES ASSÍNCRONAS COM O RECIPIENTE ...............................................................29 FIGURA 4 - PARTES QUE COMPÕE A URL DE UMA CHAMADA REST DO OPENSOCIAL .....................................................................................................55 FIGURA 5 - PARTES QUE COMPÕE A URL DE UMA CHAMADA REST DO FACEBOOK.........................................................................................................67 FIGURA 6 - ESBOÇO DO JOGO DA FORCA. ..............................................................72 FIGURA 7 - DIAGRAMA DE CASOS DE USO ..............................................................73 FIGURA 8 - DIAGRAMA DE ATIVIDADES ....................................................................75 FIGURA 9 - ESTRUTURA DE ARQUIVOS QUE COMPÕE O JOGO............................77 FIGURA 10 - VISÃO HOME DO JOGO NO IGOOGLE..................................................80 FIGURA 11- VISÃO CANVAS DO JOGO NO IGOOGLE...............................................82 FIGURA 12 - VISÃO CANVAS DO JOGO......................................................................83 FIGURA 13 - VISÃO DO JOGO QUANDO O USUÁRIO ACERTA OU ERRA O NOME DO AMIGO...............................................................................................84 FIGURA 14 - ATIVIDADE CRIADA PELO JOGO NO ORKUT.......................................85
  9. 9. LISTA DE QUADROS QUADRO 1 - APLICATIVOS MAIS POPULARES DO ORKUT......................................17 QUADRO 2 - DATAS DAS PUBLICAÇÕES DAS ESPECIFICAÇÕES DO OPENSOCIAL 18 QUADRO 3 - EXEMPLO DA LINGUAGEM DE MARCAÇÃO XML................................22 QUADRO 4 - EXEMPLO DA LINGUAGEM DE MARCAÇÃO HTML..............................22 QUADRO 5 - EXEMPLO DA LINGUAGEM JAVASCRIPT.............................................23 QUADRO 6 - SINTAXE BÁSICA DE UM OBJETO JSON..............................................23 QUADRO 7 - APLICATIVO DE EXEMPLO DO OPENSOCIAL......................................30 QUADRO 8 - APLICATIVO DE EXEMPLO DO OPENSOCIAL COM DESTAQUE DE CORES DAS SEÇÕES........................................................................................32 QUADRO 9 - ATRIBUTOS DA SEÇÃO MODULEPREFS .............................................33 QUADRO 10 - ELEMENTOS OPCIONAIS DA SEÇÃO MODULEPREFS .........................33 QUADRO 11 - ATRIBUTOS DA SEÇÃO CONTENT........................................................34 QUADRO 12 - APIS ESPECÍFICAS DOS RECURSOS.................................................35 QUADRO 13 - PACOTE DE MENSAGEM.....................................................................36 QUADRO 14 - DEFININDO OS IDIOMAS DE UM GADGET .........................................37 QUADRO 15 - ACESSANDO UM PACOTE DE MENSAGENS VIA A API JAVASCRIPT.37 QUADRO 16 - FUNÇÕES DA CLASSE OPENSOCIAL.PERSON.....................................40 QUADRO 17 - PRINCIPAIS CAMPOS DO OBJETO OPENSOCIAL.PERSON.FIELD ....41 QUADRO 18 - POLÍTICA DE ACESSO DE ALGUNS CAMPOS DOS PERFIS DO ORKUT ................................................................................................................42 QUADRO 19 - FUNÇÃO PARA REQUISITAR A LISTA DE AMIGOS DO DONO DO APLICATIVO........................................................................................................42 QUADRO 20 - FUNÇÃO PARA REQUISITAR A LISTA DE AMIGOS DO DONO DO APLICATIVO USANDO A OSAPI ........................................................................42 QUADRO 21 - FUNÇÃO PARA PROCESSAR O RETORNO DA REQUISIÇÃO DA LISTA DE AMIGOS..............................................................................................44 QUADRO 22 - LISTANDO OS AMIGOS DO DONO DE UM APLICATIVO....................45 QUADRO 23 - PRINCIPAIS CAMPOS DO OBJETO OPENSOCIAL.MESSAGE.FIELD.TYPE.................................................47 QUADRO 24 - PRINCIPAIS CAMPOS DO OBJETO OPENSOCIAL.MESSAGE.FIELD ..47 QUADRO 25 - ENVIANDO UMA MENSAGEM DE E-MAIL ...........................................48 QUADRO 26 - ENVIANDO UMA MENSAGEM DE E-MAIL USANDO A OSAPI............48 QUADRO 27 - CAMPOS DO OBJETO OPENSOCIAL.ACTIVITY.FIELD .....................49 QUADRO 28 - CRIANDO UMA ATIVIDADE ..................................................................50 QUADRO 29 - CRIANDO UMA ATIVIDADE USANDO A OSAPI...................................50 QUADRO 30 - CRIANDO UM CONVITE PARA UM USUÁRIO .....................................50 QUADRO 31 - CRIANDO UM CONVITE PARA UM USUÁRIO USANDO A OSAPI......50 QUADRO 32 - GRAVANDO UM DADO .........................................................................51 QUADRO 33 - GRAVANDO UM DADO USANDO A OSAPI..........................................52 QUADRO 34 - RECUPERANDO UM DADO USANDO A OSAPI ..................................52 QUADRO 35 - RECUPERANDO UM DADO..................................................................53 QUADRO 36 - EXCLUÍNDO UM DADO.........................................................................53 QUADRO 37 - EXCLUÍNDO UM DADO USANDO A OSAPI .........................................53 QUADRO 38 - ESTRUTURA DO OBJETO DE RESPOSTA DE UMA REQUISIÇÃO REST ...................................................................................................................54 QUADRO 39 - FRAGMENTOS DA URL PARA O RECURSO PESSOA .......................56
  10. 10. QUADRO 40 - REPRESENTAÇÃO DE UMA PESSOA NO FORMATO JSON .............57 QUADRO 41 - REPRESENTAÇÃO DE UMA PESSOA NO FORMATO XML ...............57 QUADRO 42 - FRAGMENTOS DA URL PARA O RECURSO GRUPO.........................57 QUADRO 43 - FRAGMENTOS DA URL PARA O RECURSO ATIVIDADE...................58 QUADRO 44 - FRAGMENTOS DA URL PARA O RECURSO DADOS DO APLICATIVO .58 QUADRO 45 - PARÂMETROS DE CONSULTA ............................................................59 QUADRO 46 - TEMPLATE DO OPENSOCIAL..............................................................60 QUADRO 47 - TEMPLATE DO OPENSOCIAL..............................................................60 QUADRO 48 - USANDO LINGUAGEM DE EXPRESSÃO.............................................60 QUADRO 49 - CRIAÇÃO E CHAMADA DE UM TEMPLATE.........................................62 QUADRO 50 - USO DO ATRIBUTO IF DO TEMPLATE...............................................62 QUADRO 51 - USO DO ELEMENTO <OS:IF> .............................................................63 QUADRO 52 - USO DO ATRIBUTO IF DO TEMPLATE...............................................63 QUADRO 53 - USO DO ELEMENTO <OS:IF> .............................................................63 QUADRO 54 - TAGS DISPONÍVEIS..............................................................................64 QUADRO 55 - TAGS DISPONÍVEIS PARA PIPELINING DE DADOS...........................65 QUADRO 56 - USO DE PIPELINING DE DADOS EM CONJUNTO COM TEMPLATES...66 QUADRO 57 - TAGS DO OSML E DO FBML COM FUNÇÕES SEMELHANTES.........70 QUADRO 58 - ELEMENTO MODULEPREFS DO ARQUIVO GADGET.XML ......................77 QUADRO 59 - REQUISIÇÃO PARA CARREGAR O PRIMEIRO AMIGO......................78 QUADRO 60 - RECUPERANDO O NÚMERO DE AMIGOS..........................................79 QUADRO 61 - TRECHO DO ARQUIVO GADGET.XML...................................................80 QUADRO 62 - TRECHO DA VISÃO HOME E PROFILE DO ARQUIVO GADGET.XML..81
  11. 11. LISTA DE ABREVIATURAS E SIGLAS AJAX Asynchronous Javascript And XML API Application Programming Interface CSS Cascading Style Sheets FBML Facebook Markup Language FQL Facebook Query Language GIF Graphics Interchange Format HTML HyperText Markup Language IDE Integrated Development Environment JPG Joint Photographic Experts Group JSON JavaScript Object Notation JSP JavaServer Pages OSAPI OpenSocial Application Programming Interface OSDE OpenSocial Development Environment OSML OpenSocial Markup Language OST OpenSocial Templating PHP PHP: Hypertext Preprocessor PNG Portable Network Graphics REST Representational State Transfer RPC Remote Procedure Call SDK Software Development Kit SQL Structured Query Language SWF Shockwave Flash UML Unified Modeling Language URI Uniform Resources Identifier URL Uniform Resource Locator XML eXtensible Markup Language
  12. 12. SUMÁRIO 1 INTRODUÇÃO.........................................................................................................13 1.1 OBJETIVOS.............................................................................................................14 1.1.1 Objetivo Geral......................................................................................................14 1.1.2 Objetivos Específicos...........................................................................................14 1.2 JUSTIFICATIVA.......................................................................................................14 1.3 ESTRUTURA DO TRABALHO ................................................................................15 2 REDES SOCIAIS VIRTUAIS ...................................................................................16 2.1 ORKUT ....................................................................................................................16 2.2 OPENSOCIAL..........................................................................................................17 2.2.1 Diretório de Aplicativos ........................................................................................19 2.2.2 Melhores Práticas ................................................................................................20 2.2.3 Tecnologia e Ferramentas Envolvidas.................................................................21 2.2.3.1 XML ...................................................................................................................21 2.2.3.2 HTML.................................................................................................................22 2.2.3.3 JavaScript..........................................................................................................22 2.2.3.4 JSON .................................................................................................................23 2.2.3.5 REST .................................................................................................................24 2.2.3.6 OAuth ................................................................................................................24 2.2.3.7 Apache Shindig..................................................................................................25 2.2.3.8 OSDE ................................................................................................................26 2.2.4 Arquitetura do OpenSocial...................................................................................26 2.2.4.1 API Baseada no Cliente.....................................................................................27 2.2.4.2 API Baseada no Servidor...................................................................................28 2.2.5 Arquitetura de um Aplicativo................................................................................29 2.2.6 Aplicativo de Exemplo..........................................................................................30 3 APLICATIVOS DO OPENSOCIAL..........................................................................31 3.1 GADGET XML .........................................................................................................31 3.2 API DE GADGETS...................................................................................................34 3.2.1 Internacionalização..............................................................................................35 3.2.1.1 Pacotes de Mensagens .....................................................................................36 3.2.1.2 Acessando o Pacote de Mensagens .................................................................37 3.3 API JAVASCRIPT DO OPENSOCIAL......................................................................38 3.3.1 OSAPI..................................................................................................................38 3.3.2 Pessoas...............................................................................................................39 3.3.3 Requisições .........................................................................................................42 3.3.4 Atividades ............................................................................................................46 3.3.4.1 Mensagens de E-mail e Notificações.................................................................46 3.3.4.2 Atualizações ......................................................................................................48 3.3.4.3 Convites.............................................................................................................50 3.3.5 Persistência .........................................................................................................51 3.3.5.1 Armazenando Dados.........................................................................................51 3.3.5.2 Recuperando Dados..........................................................................................52 3.3.5.3 Excluindo Dados................................................................................................53 3.4 API RESTFUL DO OPENSOCIAL ...........................................................................54 3.5 OPENSOCIAL TEMPLATES (OST).........................................................................59 3.5.1 Formato do Template...........................................................................................60 3.5.2 Expressões..........................................................................................................60
  13. 13. 3.5.3 Variáveis..............................................................................................................61 3.5.4 Chamada de Templates.......................................................................................61 3.5.5 OpenSocial Markup Language (OSML)...............................................................62 3.5.6 Conteúdo Condicional..........................................................................................62 3.5.7 Elementos de Repetição......................................................................................63 3.5.8 Tags.....................................................................................................................63 3.6 PIPELINING DE DADOS .........................................................................................64 3.7 FACEBOOK .............................................................................................................66 3.7.1 Plataforma Facebook...........................................................................................67 3.7.2 Comparativo Entre as APIs do OpenSocial e do Facebook.................................69 3.7.2.1 Linguagem de Marcação ...................................................................................69 3.7.2.2 JavaScript..........................................................................................................70 3.7.2.3 Segurança .........................................................................................................71 4 ESTUDO DE CASO.................................................................................................72 4.1 O JOGO...................................................................................................................72 4.2 ANÁLISE..................................................................................................................73 4.2.1 Casos de Uso ......................................................................................................73 4.2.2 Diagrama de Atividades.......................................................................................75 4.3 IMPLEMENTAÇÃO..................................................................................................75 4.3.1 Carregando um Amigo.........................................................................................78 4.3.2 Visões..................................................................................................................79 4.3.3 Atividades e Compartilhamento ...........................................................................84 4.3.4 Adicionando o Aplicativo......................................................................................85 5 CONSIDERAÇÕES FINAIS.....................................................................................87 REFERÊNCIAS..............................................................................................................88 ANEXOS ........................................................................................................................93
  14. 14. 13 1 INTRODUÇÃO Nos últimos anos houve um aumento no número de redes sociais e sites de relacionamento. Todos eles têm em comum a interação entre pessoas, sejam conhecidas ou desconhecidas. É natural do ser humano querer se associar a um grupo e interagir com outros indivíduos. Pode-se atribuir a isso o sucesso desses sites. Com os seus mais de 500 milhões de usuários, o Facebook é a rede social mais popular do mundo (YANO, 2010). No Brasil, a anos também tem-se presenciado o sucesso de outra rede social, o Orkut, que pertence ao Google. Em 2007, o Facebook disponibilizou APIs (Application Programming Interface) para que aplicativos de terceiros pudessem interagir com os usuários do site (KIRKPATRICK, 2007, tradução própria). Desde então, qualquer pessoa com conhecimento de programação pode criar aplicativos que podem ser usados por qualquer um dos 500 milhões de usuários do Facebook. No entanto, esses aplicativos só funcionam no Facebook. Assim como o Facebook, outras redes de relacionamentos interessaram-se em disponibilizar aplicativos para os seus usuários. Pensando nisso, o Google e outras empresas criaram o OpenSocial, uma plataforma que, assim como o Facebook, fornece APIs que podem ser usadas por aplicativos de terceiros para interagir com os usuários de uma rede social. O maior benefício do OpenSocial é a possibilidade de desenvolver um aplicativo que seja executado em diferentes redes sociais, pois as suas APIs são padronizadas. Pode-se fazer uma analogia com a linguagem de programação Java, em que um programa criado usando essa linguagem pode ser executado em diferentes plataformas, como Windows e Linux, por exemplo. Da mesma forma, um aplicativo criado usando o OpenSocial pode, por exemplo, ser executado no Orkut e no MySpace. Tanto o Facebook quanto o OpenSocial têm atraído muitos interessados em desenvolver usando as suas APIs, pois um usuário de uma rede social é um potencial consumidor, e todas essas redes possuem centenas de milhões de usuários. Todo esse mercado não pode passar despercebido.
  15. 15. 14 1.1 OBJETIVOS Apresentar um estudo sobre a construção de aplicativos sociais utilizando as APIs do OpenSocial. 1.1.1 Objetivo Geral Realizar um estudo das APIs do OpenSocial e demonstrar o seu funcionamento através da criação de um aplicativo usando a API JavaScript do OpenSocial, que poderá ser hospedado e executado em qualquer rede de relacionamentos que implemente as especificações do OpenSocial. 1.1.2 Objetivos Específicos  Estudar as APIs comuns que compõe o OpenSocial e a estrutura de um aplicativo;  Comparar as APIs do OpenSocial com as APIs do Facebook;  Analisar e implementar um aplicativo utilizando a API JavaScript do OpenSocial;  Hospedar o aplicativo desenvolvido na rede de relacionamentos Orkut. 1.2 JUSTIFICATIVA Sendo a rede social Orkut o segundo site mais acessado no Brasil (ALEXA, 2010b) e o Facebook o segundo site mais acessado no mundo (ALEXA, 2010a), é inegável que as redes de sociais (ou redes de relacionamentos) fazem parte do dia- a-dia das pessoas que acessam a Internet. Com o crescente número de internautas e consequentemente das redes sociais, surge uma demanda por aplicativos com características sociais. E para facilitar a vida do desenvolvedor foi criado o OpenSocial, uma plataforma que fornece um conjunto de APIs para acessar informações sobre individuos e seus
  16. 16. 15 relacionamentos entre si e ainda tem a capacidade de disponibilizar e exibir atualizações sobre as ações das pessoas. O OpenSocial utiliza JavaScript, HTML (HyperText Markup Language) e XML (eXtensible Markup Language), permitindo que qualquer desenvolvedor web possa trabalhar com ele. As APIs também fornecem algumas facilidades a mais, como um sistema de armazenamento de dados e um sistema de retorno de chamada assíncrono, também conhecido como callback1 , para suportar interatividade AJAX (Asynchronous Javascript And XML). 1.3 ESTRUTURA DO TRABALHO Este trabalho é dividido em quatro capítulos. O primeiro capítulo introduz as redes sociais e o OpenSocial, bem como apresenta os objetivos e a justificativa do trabalho. O segundo capítulo apresenta uma introdução às redes sociais virtuais, como o Orkut, por exemplo. Também é apresentado o OpenSocial, os motivos que o levaram a ser criado e informações sobre os aplicativos sociais. O terceiro capítulo aborda o estudo das APIs do OpenSocial e as formas de criar um aplicativo. E por último, no quarto capítulo, é realizada a análise e implementação de um aplicativo utilizando as APIs do OpenSocial. ‒‒‒‒‒‒‒‒‒‒‒‒‒‒ 1 Uma função callback é uma função que é passada como parâmetro para outro código que a invocará posteriormente.
  17. 17. 16 2 REDES SOCIAIS VIRTUAIS Segundo Ferla (2008): "As redes sociais são formadas por indivíduos com interesses, valores e objetivos comuns para o compartilhamento de informações. A internet é um dos grandes fomentadores para a formação de redes, porque as pessoas podem se encontrar independente de tempo e espaço. As pessoas criam redes sociais online a partir de sites de networking como o Orkut e são um dos principais tipos de ferramentas de mídias sociais." A popularidade das redes sociais virtuais é muito grande. De acordo com Roos (2007), "sites como MySpace, Facebook e Linkedln estão entre os sete dos 20 Websites mais visitados no mundo, e o site de relacionamentos criado pelo Google, o Orkut, acabou virando o predileto dos brasileiros." Alguns recursos são comuns na maioria da redes sociais, como a criação de um perfil pessoal, que pode ser compartilhado. Esse perfil normalmente possui uma foto, informações básicas como o nome, idade, local e um espaço em que são descritas as preferências pessoais, como livros, filmes e gosto musical. O recurso mais importante dessas redes sociais online é encontrar e fazer amigos com outros membros da rede. (ROOS, 2007). As redes sociais virtuais também permitem "a formação de grupos por afinidade, com ou sem autorização, e de espaços específicos para discussões, debates e apresentação de temas variados (comunidades, fóruns, Twitter, sites de relacionamento)." (REDE SOCIAL VIRTUAL, 2010). 2.1 ORKUT De acordo com Orkut (2010a): Orkut é uma rede social filiada ao Google, criada em 24 de Janeiro de 2004 com o objetivo de ajudar seus membros a conhecer pessoas e manter relacionamentos. Seu nome é originado no projetista chefe, Orkut Büyükkokten, engenheiro turco do Google. O alvo inicial do orkut era os Estados Unidos, mas a maioria dos usuários são do Brasil e da Índia. No Brasil é a rede social com maior participação de brasileiros, com mais de 23 milhões de usuários, e o site mais visitado. Na Índia é o segundo mais visitado.
  18. 18. 17 Os brasileiros são a maioria no Orkut, representando 50,93% do total de usuários. Indianos formam 20,12% do total e usuários dos Estados Unidos representam 17,56%. (ORKUT, 2010b). O recurso de aplicativos sociais foi adicionado no Orkut em 2008, fazendo uso da integração com o OpenSocial. O Google, proprietário do Orkut, faz uma análise de cada aplicativo que é submetido ao Orkut, bloqueando aplicativos que permitam vulnerabilidades no acesso aos dados dos usuários. (ORKUT, 2010a). Atualmente o Orkut já possui mais de 600 aplicativos (ZMOGINSKI, 2008). Os mais populares são apresentados, a seguir, no Quadro 1. Nome Usuários Descrição BuddyPoke 36.765.759 Permite criar personagens em 3 dimensões (3D). Colheita Feliz 21.615.882 Jogo em que o usuário deve cuidar da sua própria fazenda virtual. Mini Fazenda 16.289.082 Jogo em que, assim como o Colheita Feliz, o usuário deve cuidar da sua própria fazenda virtual. Minha Música 9.054.486 Permite colocar uma música no perfil do usuário. Segredos do Mar 4.887.038 Permite ao usuário criar o seu próprio oceano. Profile Posters 2.592.366 Permite adicionar um pôster no perfil do usuário. Biscoito da Sorte 2.079.996 Oferece mensagens diárias ao usuário. Vida nas Passarelas 2.042.605 Permite ao usuário disputar desfiles virtuais contra concorrentes. Baby Adopter 1.927.630 Permite ao usuário adotar e cuidar de um bebê. Resort Tropical 1.800.592 Permite ao usuário explorar uma ilha tropical. Quadro 1 - Aplicativos mais populares do Orkut Fonte: Orkut (2010c). 2.2 OPENSOCIAL O OpenSocial é uma plataforma que permite criar e implantar aplicativos sociais em múltiplas redes. Ele é o único que foi criado para o uso em múltiplas redes sociais (chamados de recipientes), e também tem o benefício de ser uma biblioteca de código aberto para o desenvolvimento de aplicações. O OpenSocial é, na verdade, concebido para facilitar a implantação de um único aplicativo em múltiplas redes sociais. Ele possui diferentes versões e nem todas as redes sociais
  19. 19. 18 suportando o OpenSocial têm suporte a última versão. (GREWE, 2009, p. 55, tradução própria). Toda a documentação do OpenSocial é licenciado por meio da Creative Commons. Além disso, todos os códigos de exemplo da documentação são fornecidos sob a licença Apache 2.0. (OPENSOCIAL, 2010e). Nem todas as redes sociais permitem que organizações de terceiros ou indivíduos possam criar aplicações para redes sociais. Esse recurso realmente emergiu com a API do Facebook, que é o motivo pelo qual se vêem tantos aplicativos para o Facebook. O OpenSocial foi explicitamente criado para permitir aos desenvolvedores criarem aplicativos que pudessem ser implantados em múltiplas redes sociais (recipientes), ao contrário da API exclusiva do Facebook. (GREWE, 2009, p. 1, tradução própria). Atualmente, a tendência parece estar se voltando a aplicativos que não são destinados apenas a serem populares (ou virais), mas que também tenham uma retenção e uso por um longo prazo com interações mais complexas e por mais tempo. Aplicações envolvendo música e mídia, negócios e educação são exemplos desse modelo. (GREWE, 2009, p. 14, tradução própria). O lançamento público do OpenSocial ocorreu com a versão 0.5, em dezembro de 2007 (GREWE, 2009, p. 56, tradução própria). No Quadro 2 são mostradas as datas das publicações das especificações de cada versão. Versão Publicação 0.6 21 dez. 2007 0.7 25 jan. 2008 0.8 27 maio 2008 0.9 15 abr. 2009 1.0 9 mar. 2010 1.1 18 out. 2010 (rascunho) Quadro 2 - Datas das publicações das especificações do OpenSocial Fonte: Opensocial and Gadgets Specification Group (2010d). Os aplicativos do OpenSocial podem aparecer em três interfaces, também chamadas de visões, na página do usuário na rede social:
  20. 20. 19  Visão "canvas": esta visão é definida como a "tela cheia" do aplicativo sendo executado. Claro que ela ainda estará dentro da interface da rede social, mas ocupará uma grande porcentagem da interface;  Visão "home": esta é a visão quando o aplicativo está sendo executado na interface principal/inicial que o usuário geralmente vê quando entra (faz o login) na rede social. Na maioria das vezes, ela será reduzida em tamanho quando comparada com a visão "canvas";  Visão "profile": esta é a visão quando o aplicativo está sendo executado na página do perfil do usuário. Assim como a visão "home", essa visão tipicamente ocupa uma porcentagem menor da página. (GREWE, 2009, p. 19, tradução própria). Cada recipiente difere na forma como controla o aplicativo. Essas políticas algumas vezes não são publicadas, e podem mudar com frequência. Por causa disso, os desenvolvedores devem continuamente educar-se nas mudanças de políticas de aplicativos de qualquer rede. (GREWE, 2009, p. 26, tradução própria). No Anexo A é apresentada uma lista de recipientes que implementam o OpenSocial e algumas informações sobre eles. Além dos recipientes apresentados no Anexo A, há outros que também implementam o OpenSocial, mas ainda não estão disponíveis ao público em geral ou estão em fase de testes, tais como o Plaxo Pulse, o Viadeo e o Lokalisten. (OPENSOCIAL, 2010a). 2.2.1 Diretório de Aplicativos Infelizmente, não há um local em que o desenvolvedor possa submeter o seu aplicativo para que ele possa ser usado por todas as redes sociais que fazem parte do OpenSocial. Cada recipiente possui o seu próprio diretório de aplicativos que podem ser instalados, ou seja, o desenvolvedor deve submeter o seu aplicativo separadamente para cada rede social. Além disso, cada rede tem os seus próprios critérios para aceitar um aplicativo. Uma lista extensa de aplicativos pode ser encontrada no endereço http://directory.opensocial.org/gadgets/directory. No entanto, a lista possui aplicativos que podem ser instalados apenas em algumas redes sociais.
  21. 21. 20 2.2.2 Melhores Práticas De acordo com OpenSocial (2010g, tradução própria), existem algumas recomendações na construção de aplicativos sociais que os ajudam a se tornar atraentes:  Rápido engajamento: há uma tendência de o usuário experimentar um aplicativo desconhecido e rapidamente abandoná-lo caso não encontre nenhum valor de imediato. Para evitar que isso ocorra, é necessário que se deixe claro logo no início as intenções do aplicativo, e também que o aplicativo tenha conteúdo interessante (especialmente o conteúdo de amigos) e seja fácil de usar;  Aparência consistente: ajuda a manter a consistência do aplicativo se ele possuir uma aparência semelhante a do recipiente onde ele está hospedado;  Permitir auto-expressão: a página do perfil representa a identidade de um usuário, interesses e gostos. Do ponto de vista do proprietário, é um meio de auto-expressão e um ponto de partida para explorar o gráfico social. Do ponto de vista dos espectadores, é um lugar para aprender, comunicar e encontrar interesses comuns;  Dinamicidade: boas aplicações não são apenas um crachá estático, elas mudam dinamicamente para fornecer uma experiência interessante através das sessões;  Expor atividades dos amigos: uma maneira muito fácil de fazer uma aplicação dinâmica e social é registar e apresentar as atividades dos amigos que estão usando o aplicativo. A partir dessas atividades, os usuários se tornam mais conscientes de como os outros estão usando o aplicativo, levando a uma maior utilização;  Navegar pelo grafo de amigos: os usuários geralmente se interessam por interações que exigem pouco esforço, como ver as atividades mais recentes dos amigos e comparar conteúdos e escolhas;  Comunicação dirigida: em lugares onde a comunicação pode acontecer, é uma boa prática deixar essa opção explícita, como em um sistema de comentários;
  22. 22. 21  Construir comunidades: ao aumentar as pequenas comunidades tornando-as acessíveis, um aplicativo pode fornecer uma funcionalidade rica e interessante que melhora a experiência global social;  Resolver problemas do mundo real: a plataforma OpenSocial pode ajudar a resolver tarefas do mundo real em que o grafo2 social auxilia na tomada de decisões, como marcar encontros, por exemplo. 2.2.3 Tecnologia e Ferramentas Envolvidas O OpenSocial foi desenvolvido sobre linguagens e especificações conhecidas por quem trabalha com aplicativos para a web, como JavaScript e HTML. Com isso, torna-se fácil para um desenvolvedor criar um aplicativo social. A seguir são apresentadas as linguagens, conceitos e ferramentas envolvidas no OpenSocial. 2.2.3.1 XML Segundo Grewe (2009, p. 64, tradução própria), o OpenSocial é construído sobre os chamados gadgets3 sociais, representados por arquivos XML. O XML é uma linguagem de marcação que consegue armazenar todo tipo de dados, descrevendo-os. Essa capacidade também é chamada de "self- describe data", ou dados autodescritivos e, por utilizar caracteres Unicode, pode armazenar qualquer tipo de caractere ou símbolo, fazendo a representação de informações em qualquer idioma ou cultura. (FARIA, 2005, p. 11). Um trecho exemplificando a linguagem de marcação XML é exibido, a seguir, no Quadro 3. No exemplo, é definido um elemento chamado cor, que por sua vez possui um atributo chamado nome no qual o valor é azul. ‒‒‒‒‒‒‒‒‒‒‒‒‒‒ 2 O grafo social é a base das redes sociais. Cada nó do grafo representa uma pessoa e as conexões entre os nós representam as relações entre elas. 3 Um gadget é um componente feito por desenvolvedores Google que dá aos usuários conteúdos interessantes e dinâmicos que podem ser colocados em qualquer página da web. (GREWE, 2009, p. 59, tradução própria).
  23. 23. 22 1 <?xml version="1.0" encoding="UTF-8" ?> 2 <cor nome="azul" /> 3 </elemento> Quadro 3 - Exemplo da linguagem de marcação XML 2.2.3.2 HTML A linguagem de marcação HTML é usada para construir o conteúdo de um aplicativo social. Um exemplo é apresentado no Quadro 4. De acordo com Costa (2007, p. 9): O HTML, ou Hypertext Markup Language, é a linguagem padrão utilizada para o acesso e exibição de páginas Web. As linhas de código HTML são interpretadas pelo browser, que mostra o resultado final ao utilizador, sem necessidade de compilação. Genericamente, a linguagem HTML é constituída por textos e códigos especiais denominados marcas ou tags (os comandos da linguagem). 1 <html> 2 <head> 3 <title>Exemplo</title> 4 </head> 5 <body> 6 <p>Olá mundo!</p> 7 </body> 8 </html> Quadro 4 - Exemplo da linguagem de marcação HTML No Quadro 4, é criado um documento HTML, com um cabeçalho (elemento head) e com um corpo (elemento body). Dentro do cabeçalho é definido o título do documento (elemento title) e dentro do corpo é criado um parágrafo (elemento p). 2.2.3.3 JavaScript É a linguagem de programação JavaScript que trará o aspecto dinâmico a um aplicativo social, como, por exemplo, a busca dos dados do usuário de um aplicativo. Segundo Flanagam (2004, p. 19): JavaScript é uma linguagem de programação leve, interpretada e com recursos de orientação a objetos. [...] Sintaticamente, o núcleo da linguagem JavaScript assemelha-se às linguagens C, C++ e Java, contendo construções de programação com a instrução if, o laço while e o
  24. 24. 23 operador &&. Entretanto, a similaridade acaba nessa semelhança sintática. JavaScript é uma linguagem não-tipada, ou seja, as variáveis não precisam ter um tipo especificado. Um exemplo da linguagem JavaScript pode ser visto no Quadro 5. 1 <script type="text/javascript"> 2 var texto = 'Olá mundo'; 3 alert(texto); 4 </script> Quadro 5 - Exemplo da linguagem JavaScript No exemplo mostrado no Quadro 5 uma variável chamada texto e o seu conteúdo é exibido como uma mensagem de alerta no navegador. 2.2.3.4 JSON A troca de dados entre o aplicativo e o servidor da rede social é feita usando o formato JSON (JavaScript Object Notation). (OPENSOCIAL, 2010g). O JSON é um formato de troca de dados que também serve para serializar objetos. Um objeto na memória pode ser transportado por qualquer meio até o seu destino. [...] Utilizamos o JSON para a troca de dados entre funções de APIs existentes na Web. [...] É uma alternativa muito utilizada como contrapartida ao XML na troca de mensagens entre o cliente e a API. (SAMPAIO, 2007, p. 115). Ainda segundo Sampaio (2007, p. 115), "um Objeto JSON é definido como um conjunto de nomes e valores separados por dois pontos e delimitados por vírgulas. Este conjunto de nomes/valores representa as propriedades do objeto sendo definido. O objeto todo fica delimitado por chaves". O Quadro 6 apresenta um exemplo de um objeto no formato JSON. 1 pessoa = { 2 nome : 'Clebersander Rech', 3 idade : 23 4 } Quadro 6 - Sintaxe básica de um objeto JSON No Quadro 6 o objeto chamado pessoa possui duas chaves: uma chamada nome e outra chamada idade. Logo após os dois pontos das chaves são definidos os seus valores.
  25. 25. 24 2.2.3.5 REST Para que os clientes possam interagir com os servidores dos recipientes OpenSocial externamente aos gadgets, o OpenSocial define uma linguagem e plataforma neutros em relação a protocolos (OPENSOCIAL AND GADGETS SPECIFICATION GROUP, 2009, tradução própria). Ou seja, para a interação entre os servidores de terceiros e os servidores das redes sociais é utilizada a arquitetura REST, mediante um serviço web disponibilizado pelo servidor e acessado pelo cliente. Um serviço web que segue os principios desta arquitetura é denominado RESTful. No estilo arquitetônico REST, cada peça de informação é um recurso, e esses recursos são endereçados usando Uniform Resources Identifiers (URIs), tipicamente links na Web. Os recursos são postos em prática através de um conjunto de operações simples e bem definidas. O estilo da arquitetura REST cliente-servidor é desenhado para usar um protocolo de comunicação stateless (sem estado), tipicamente o HTTP. No REST, os clientes e os servidores trocam representações de recursos usando uma interface e um protocolo definidos. (GONÇALVES, 2009, p. 429). O protocolo opera principalmente em termos de recursos e operações sobre eles. Um serviço RESTful é definido sobre do protocolo HTTP e usa os métodos padrão HTTP (GET, POST, PUT, DELETE, HEAD e OPTIONS) para recuperar e mudar o estado do servidor. (OPENSOCIAL AND GADGETS SPECIFICATION GROUP, 2009, tradução própria). 2.2.3.6 OAuth Quando um aplicativo OpenSocial REST faz uma requisição para a rede social é necessário que esse aplicativo seja autenticado. Quando essas requisições também envolvem um usuário, a autenticação também é necessária (GREWE, 2009, p. 176, tradução própria). Para resolver a questão de autorização e autenticação, é utilizado o protocolo OAuth. O OAuth é um protocolo de autorização padrão aberto que permite que os administradores acessem dados básicos dos usuários sem acessar as contas dos usuários. Em vez de solicitar nomes de usuários e senhas aos usuários, o OAuth age como a "chave mestra" usando um token de usuário para permitir um acesso limitado aos dados. Os usuários podem revogar a chave mestra, caso necessário. (AJUDA DO GOOGLE APPS ADMINISTRADOR, 2010).
  26. 26. 25 2.2.3.7 Apache Shindig Pode-se dizer que o OpenSocial também é uma especificação, que deve ser implementada pelos recipientes. Para facilitar a implementação do OpenSocial no servidor das redes sociais foi criado o projeto Shinding. Apache Shindig é um recipiente OpenSocial e ajuda a começar a hospedagem de aplicativos OpenSocial rapidamente, fornecendo o código para renderizar gadgets, requisições de proxy e manipular requisições REST e RPC. O objetivo do Apache Shindig é permitir que novos sites possam hospedar aplicativos sociais no menor tempo possível. O Apache Shindig é a implementação de referência das especificações da API OpenSocial. (SHINDIG, 2010, tradução própria). O Apache Shindig é composto de quatro partes (SHINDIG, 2010, tradução própria):  Recipiente JavaScript do Gadget: JavaScript fundamental para as funcionalidades gerais do gadget. Esse JavaScript gerencia segurança, comunicação, layout da interface do usuário e extensões de recursos, como a API do OpenSocial;  Servidor de Renderização de Gadget: usado para renderizar o XML do gadget em JavaScript e HTML, para que o mesmo possa ser exposto para o recipiente JavaScript;  Recipiente JavaScript do OpenSocial: ambiente JavaScript que fica no topo do Recipiente JavaScript do Gadget e oferece funcionalidades específicas do OpenSocial (perfis, amigos, atividades e armazenamento de dados);  Servidor de Dados do OpenSocial: uma implementação da interface do servidor para informações específicas do recipiente, incluíndo as APIs REST do OpenSocial, com pontos de extensão para que outros possam se conectar usando o seu próprio backend. O endereço do projeto Apache Shindig é http://shindig.apache.org.
  27. 27. 26 2.2.3.8 OSDE O OSDE (OpenSocial Development Environment) é um plugin para o Eclipse IDE (Integrated Development Environment) usado para auxiliar no desenvolvimento e teste de aplicativos do OpenSocial. Segundo Cheng (2010, tradução própria), a versão 1.0 do OSDE foi lançada em 22 junho de 2010 e possui as seguintes características:  Um servidor Shindig embutido para teste local;  Um banco de dados integrado para armazenar e gerenciar dados sociais;  Assistentes (wizards) para a geração de projetos simples e código para o gadget;  Um editor multipainel da especificação do gagdet;  Uma perspectiva do Eclipse chamada "OpenSocial" que disponibiliza uma edição e depuração aprimorada de fácil acesso e controle do servidor Shindig local bem como do banco de dados social;  Um assistente para a gerar um projeto OpenSocial em Java, que terá códigos de exemplo usando a biblioteca Java do OpenSocial RESTful para a conexão ao servidor OpenSocial local;  Possibilidade de teste no servidor do iGoogle;  Análise de desempenho. O plugin OpenSocial Development Environment pode ser baixado no endereço http://code.google.com/p/opensocial-development-environment. 2.2.4 Arquitetura do OpenSocial A arquitetura do OpenSocial envolve o cliente (usando um navegador web) e o recipiente (rede social). Todas as redes sociais servem diretamente ao cliente. Por isso, qualquer requisição feita pelo cliente a um aplicativo social será intermediado pelo recipiente, que pode inclusive "filtrar" os resultados antes que eles sejam entregues ao cliente (GREWE, 2009, p. 57, tradução própria). A Figura 1 apresenta a arquitetura entre a rede social e o aplicativo. Nela, a rede social age como uma ponte entre os usuários e o aplicativo.
  28. 28. 27 Figura 1 - Arquitetura entre a rede social e o aplicativo Fonte: Adaptado de Grewe (2009, p. 58, tradução própria). Com a versão 0.8 do OpenSocial, surgiram duas novas APIs OpenSocial:  API baseada no cliente: baseia-se na tecnologia JavaScript no lado do cliente. A API JavaScript do OpenSocial (às vezes simplesmente chamada de API OpenSocial) foi a primeira API surgida no lançamento inicial do OpenSocial. Ela envolve a realização de chamadas usando a API JavaScript do OpenSocial;  API baseada no servidor: nova desde o lançamento do OpenSocial 0.8 em 2008, a API para serviços RESTful permite aos desenvolvedores criar aplicativos com a sua própria tecnologia no lado do servidor, o que possibilita aos desenvolvedores escrever aplicativos hospedados em um servidor e fazer chamadas diretas ao recipiente. Os desenvolvedores podem escrever o aplicativo no lado do servidor em qualquer linguagem suportada pelo mesmo, como Java ou PHP (PHP: Hypertext Preprocessor). (GREWE, 2009, p. 58, tradução própria). 2.2.4.1 API Baseada no Cliente Nesse tipo de modelo, todo o aplicativo é desenvolvido usando XML, HTML e JavaScript. Em algumas redes sociais, tais como MySpace e iGoogle, é possível hospedar o aplicativo no recipiente. Os desenvolvedores de alguns aplicativos podem querer armazenar e recuperar dados do seu próprio aplicativo. Nesses casos, os desenvolvedores utilizam a persistência tal como definida na API JavaScript do OpenSocial. Os desenvolvedores podem querer também armazenar Rede Social Aplicativo da Rede Social
  29. 29. 28 os dados no seu próprio banco de dados, ou talvez precisem de outros recursos ou serviços em seus servidores. Nesse modelo, os recursos (como serviços e programas do lado do servidor) são invocados para prestar suporte ao aplicativo. Deste modo, o tipo do aplicativo pode ser descrito como um aplicativo com suporte no lado do servidor. (GREWE, 2009, p. 58, tradução própria). 2.2.4.2 API Baseada no Servidor A API no lado do servidor é disponibilizada em três versões: para aplicativos de uma rede não-social, para aplicativos de uma rede social e para aplicativos híbridos. Alguns aplicativos OpenSocial RESTful no lado do servidor não são gadgets e não são implantados no recipiente, mas usam dados sociais. Ao invés de usar a API JavaScript do OpenSocial, esses aplicativos utilizam a API RESTful do OpenSocial, que possibilita a um programa no lado do servidor obter dados sociais direto da rede social, bem como também enviar dados para a rede social (GREWE, 2009, p. 59, tradução própria). Esse tipo de arquitetura pode ser visto na Figura 2. Figura 2 - Arquitetura de um aplicativo social completamente baseado no servidor Fonte: Adaptado de Grewe (2009, p. 61, tradução própria). Na Figura 2 o servidor onde está o aplicativo cliente requisita os dados ao servidor da rede social através da API RESTful. Desta maneira, o aplicativo não fica hospedado no recipiente da rede social. Rede Social Servidor de Aplicação OpenSocial RESTful Cliente
  30. 30. 29 2.2.5 Arquitetura de um Aplicativo Um aplicativo de rede social baseado na API JavaScript do OpenSocial pode ser visto com um objeto em camadas, como mostra a Figura 3. Uma camada externa especifíca o aplicativo como um gadget Google usando XML. O conteúdo interno é o conteúdo do aplicativo, e consiste tipicamente de HTML, JavaScript, CSS (Cascading Style Sheet) e outro conteúdo. No caso do desenvolver não querer colocar o conteúdo diretamente no gadget, ele pode fazer referência a um conteúdo localizado fora do gadget, como uma página HTML em outro servidor ou um arquivo no formato Flash. Os aplicativos baseados no cliente utilizam a API JavaScript do OpenSocial para fazer consultas ao recipiente de uma maneira assíncrona para a maioria das chamadas. A maioria dos métodos do OpenSocial não retornam diretamente dados. Ao invés, o aplicativo deve requisitar o dado, e então, algum tempo depois, o recipiente retornará os resultados para uma função callback no aplicativo. (GREWE, 2009, p. 63, tradução própria). Na Figura 3 é representada a comunicação assíncrona entre o gadget (aplicativo do OpenSocial) e o recipiente (rede social). Figura 3 - Camadas de um aplicativo OpenSocial e comunicações assíncronas com o recipiente Fonte: Adaptado de Grewe (2009, p. 63, tradução própria). O objeto retornado como resposta de uma requisição é uma instância de opensocial.DataResponse. Um único objeto DataRequest pode ter múltiplos objetos de requisição adicionados a ele. Um aplicativo pode fazer várias requisições durante a sessão com o usuário, mas também pode escolher agrupá-las de uma só Aplicativo OpenSocial Gadget XML Conteúdo HTML Recipiente OpenSocial Dados Dados Comunicação Assíncrona
  31. 31. 30 vez (para aumentar o desempenho). Uma requisição pode obter o nome do usuário ou a lista de amigos do usuário, por exemplo. A classe para fazer as requisições é opensocial.DataRequest. (Todas as classes e métodos na API JavaScript do OpenSocial iniciam com o namespace4 opensocial). O aplicativo então envia a requisição utilizando o método send da classe DataRequest. (GREWE, 2009, p. 63, tradução própria). 2.2.6 Aplicativo de Exemplo O OpenSocial é construído sobre o que o Google chama de gadgets sociais, que são representados por arquivos XML. (GREWE, 2009, p. 64, tradução própria). O Quadro 7 mostra o código-fonte de um aplicativo de exemplo do OpenSocial. 1 <?xml version="1.0" encoding="UTF-8" ?> 2 <Module> 3 <ModulePrefs title="Olá Mundo!"> 4 <Require feature="opensocial-0.8" /> 5 </ModulePrefs> 6 <Content type="html"> 7 <![CDATA[ 8 Olá Mundo! 9 ]]> 10 </Content> 11 </Module> Quadro 7 - Aplicativo de exemplo do OpenSocial A linha 1 do Quadro 7 indica o conteúdo do arquivo como sendo XML. A linha 2 declara um gadget. Já na linha 3 o elemento ModulePrefs define as informações do gadget, sendo que dentro deste elemento tem-se outro elemento indicando o uso da versão 0.8 da API OpenSocial. Na linha 6 é indicado que o gadget será exibido como HTML. E por fim, na linha 7, é inserido o conteúdo do gadget, que pode incluir HTML, CSS e JavaScript. Toda essa estrutura XML é utilizada para definir o aplicativo como um gadget. ‒‒‒‒‒‒‒‒‒‒‒‒‒‒ 4 Um namespace fornece desambiguação para itens que possuem o mesmo nome mas que residem em namespaces diferentes.
  32. 32. 31 3 APLICATIVOS DO OPENSOCIAL Um aplicativo do OpenSocial é definido em um arquivo XML, também chamado de gadget. Esse arquivo XML segue a especificação Google Gadget XML. Dentro deste gadget é usada a API JavaScript do OpenSocial. Um aplicativo social pode então ser descrito com um gadget, que por sua vez pode ser descrito como um arquivo XML. Deve-se levar em conta que todo aplicativo social do OpenSocial é um gadget, mas nem todo gadget será um aplicativo social. Ele só será chamado assim quando fizer uso dos dados do usuário e dos seus amigos. "Gadgets são aplicativos simples em HTML e JavaScript que podem ser incorporados em páginas da web e em outros aplicativos. [...] Seu gadget pode ser executado em diversos sites, incluindo o iGoogle, Google Maps, Orkut ou em qualquer página da web. Escreva seu gadget somente uma vez e faça pequenas alterações para executá-lo em diversos locais." (API DE GADGETS, 2010a). 3.1 GADGET XML Um gadget XML consiste, basicamente, de alguns blocos estruturais simples: XML, HTML e JavaScript. O XML é uma linguagem de marcação de uso geral. Ela é usada para especificar a programação de um gadget e contém instruções sobre como processar e exibir o mesmo. Esse arquivo XML pode conter todos os dados e códigos do gadget ou indicar um local externo onde o restante dos elementos estão. O HTML é uma linguagem de marcação usada para descrever o conteúdo de uma página na web, bem como o conteúdo estático de um gadget. Já a linguagem JavaScript é usada para adicionar comportamento dinâmico ao gadget. (API DE GADGETS, 2010d). Um gadget XML é composto de três partes principais:  Seção de conteúdo: representada pela tag Content, é a parte mais importante. Nela é colocada toda a lógica de programação. É está a parte do gadget que será vista pelo usuário;
  33. 33. 32  Preferências do usuário: representada pela tag UserPrefs, permite que sejam definidas configurações para o gadget pelo usuário. Esta tag é opcional;  Preferências do gadget: representada pela tag ModulePrefs, define as informações do gadget, como título, autor, tamanho preferido entre outros. É nesta tag que é definida a versão da API JavaScript do OpenSocial que será usada. (API DE GADGETS, 2010d). O Quadro 8 apresenta o código de um exemplo de gadget, sendo que a seção de preferências do gadget (ModulePrefs) é destacada em vermelho e a seção de conteúdo (Content) em azul. 1 <?xml version="1.0" encoding="UTF-8" ?> 2 <Module> 3 <ModulePrefs title="Olá Mundo!"> 4 <Require feature="opensocial-0.8" /> 5 </ModulePrefs> 6 <Content type="html"> 7 <![CDATA[ 8 Olá Mundo! 9 ]]> 10 </Content> 11 </Module> Quadro 8 - Aplicativo de exemplo do OpenSocial com destaque de cores das seções No Quadro 9 são apresentados os atributos da seção ModulePrefs que são suportados em todos os recipientes. Atributo Descrição title String opcional que fornece o título do gadget. Esse título é exibido na barra de título do gadget. title_url String opcional que fornece uma URL (Uniform Resource Locator) ao qual o título do gadget está vinculado. Por exemplo, é possível vincular o título a uma página web relacionada ao gadget. description String opcional que descreve o gadget. author String opcional que relaciona o autor do gadget. author_email String opcional que fornece o endereço de e-mail do autor do gadget.
  34. 34. 33 Atributo Descrição screenshot String opcional que fornece a URL de uma captura de tela do gadget. O formato preferencial é PNG (Portable Network Graphics), mas GIF (Graphics Interchange Format) e JPG (Joint Photographic Experts Group) também são aceitáveis. As capturas de tela de gadget devem ter 280 pixels de largura. A altura da captura de tela deve ser a altura "natural" do gadget quando está sendo usado. thumbnail String opcional que fornece o URL de uma miniatura do gadget. O formato preferencial é PNG, mas GIF e JPG também são aceitáveis. As miniaturas do gadget devem ter 120 x 60 pixels. Quadro 9 - Atributos da seção ModulePrefs Fonte: API de Gadgets (2010e). Na seção ModulePrefs também podem ser aninhados outros elementos, conforme pode ser visto no Quadro 10. Elemento Descrição Require Declara a dependência de um recurso do gadget. Feature Declara a dependência de um recurso do gadget. Preload Instrui o recipiente a buscar dados de uma origem remota durante o processo de renderização do gadget. Icon Especifica uma imagem de 16 x 16 pixels que os recipientes podem associar a um gadget específico. Locale Especifica os locais (idiomas) suportados pelo gadget. Link Um link específico do recipiente. Quadro 10 - Elementos opcionais da seção ModulePrefs Fonte: API de Gadgets (2010e). Na seção Content, o atributo type aceita os valores html (padrão) ou url. O atributo com valor html indica que o gadget armazena o conteúdo propriamente dito. Caso o atributo tenha o valor url, significa que o conteúdo do gadget será carregado de um arquivo externo, cujo caminho será definido no atributo href. O Quadro 11 apresenta os atributos possíveis da seção Content. Atributo Descrição type String opcional que fornece o tipo do conteúdo. Os valores possíveis são html e url. O padrão é html. href String que fornece um URL de destino. Pode se aplicar a um type="url" gadget ou conteúdo com proxy.
  35. 35. 34 Atributo Descrição view String opcional. Somente gadgets OpenSocial. Indica em qual visualização do recipiente OpenSocial o conteúdo deve ser exibido. Um gadget OpenSocial pode definir várias seções de conteúdo, cada uma delas aplicável a visualizações diferentes. preferred_height A altura inicial do gadget, em pixels. preferred_width A largura inicial do gadget, em pixels. Quadro 11 - Atributos da seção Content Fonte: API de Gadgets (2010e). Segundo a especificação do OpenSocial, um aplicativo sendo executado em um recipiente deve ser sempre exibido dentro de um elemento iframe. (OPENSOCIAL AND GADGETS SPECIFICATION GROUP, 2010c, tradução própria). O elemento iframe, que faz parte da linguagem HTML, permite que um site seja exibido dentro do outro. Quando um usuário está visualizando um aplicativo em uma rede social qualquer, o aplicativo na verdade não está na página da web em que ele está navegando. O aplicativo está em outro local, mas é inserido na página usando o iframe. Um dos benefícios da utilização desse elemento é que ele isola o aplicativo do resto da página da rede social, evitando que o mau comportamento do aplicativo possa afetar o resto do site, ou até mesmo colocar em risco a segurança do usuário. 3.2 API DE GADGETS Quando um recipiente suporta o OpenSocial, ele também suporta a API (JavaScript) de gadgets. Todos os objetos na API de gadgets iniciam com o namespace gadgets. A API é formada pela API principal e pelas APIs específicas do recurso. (GREWE, 2009, p. 95, tradução própria). A API principal estará sempre disponível para o gadget. Já para utilizar as APIs específicas do recurso, é necessário especificar quais delas devem ser disponibilizadas para o gadget. Isso é declarado na seção de preferências do gadget (ModulePrefs).
  36. 36. 35 Para cada recurso específico que se deseja utilizar, é adicionado um elemento Require, com o atributo feature indicando o nome da API. Na linha 4 do Quadro 8 é exibido o seguinte trecho de código: <Require feature="opensocial-0.8" /> Esta declaração instrui o recipiente onde o gadget está hospedado a incluir a versão 0.8 da API JavaScript do OpenSocial. Com isso, o gadget terá acesso a todas as funcionalidades disponibilizadas pela API incluída. As APIs específicas dos recursos são mostradas no Quadro 12, a seguir. No Anexo B são apresentadas as classes da API de gadgets. Biblioteca de recursos Descrição setprefs Define o valor de uma preferência do usuário de modo programático. dynamic-height Permite que o gadget seja redimensionado automaticamente. settitle Define o título do gadget de modo programático. tabs Adiciona uma interface com abas ao gadget. Minimessage Exibe uma mensagem temporária e descartável em um gadget. Flash Incorpora um filme em Flash (especificamente, um arquivo .swf (Shockwave Flash)) em um gadget. locked-domain A biblioteca locked-domain isola os gadgets de outros gadgets em execução na mesma página. Quadro 12 - APIs específicas dos recursos Fonte: API de Gadgets (2010e). 3.2.1 Internacionalização Quem cria um aplicativo, ainda mais social, quer que o mesmo seja acessado pelo maior número de pessoas, e para isso, o idioma não deve ser uma barreira. Para atingir um público maior para o seu aplicativo, o desenvolvedor pode fazer uso do recurso de internacionalização do OpenSocial. Segundo API de Gadgets, 2010e: A API de gadgets oferece uma maneira fácil de você disponibilizar seu gadget para um público internacional. É simples: basta estruturar o gadget de forma que o texto visível para o usuário (qualquer texto que será traduzido) esteja em pacotes de mensagens separados do gadget. Assim, qualquer tradutor de terceiros pode traduzir suas strings e criar novos
  37. 37. 36 pacotes de mensagens específicos ao local, os quais você pode adicionar à especificação do seu gadget. Dessa forma, seu gadget fica disponível para um novo grupo de usuários. 3.2.1.1 Pacotes de Mensagens Os gadgets fazem uso de pacotes de mensagens para internacionalizar um aplicativo. Um pacote de mensagem é nada mais do que um arquivo XML. Dentro desse arquivo estarão as strings traduzidas, associadas a um nome único. Cada pacote de mensagem é associado a apenas um idioma e local. Um exemplo de pacote de mensagem pode ser visto no Quadro 13. 1 <messagebundle> 2 <msg name="hello_world">Olá mundo</msg> 3 <msg name="name">Nome</msg> 4 <msg name="city">Cidade</msg> 5 </messagebundle> Quadro 13 - Pacote de mensagem Como visto no Quadro 13, para cada elemento msg, será associado um atributo name com o identificador único da string, e dentro do elemento a string traduzida. Por exemplo, a string traduzida do elemento msg com o atributo name com valor hello_world é Olá mundo. O nome do arquivo do pacote deve seguir a seguinte convenção: <idioma>_<PAIS>.xml Um pacote de linguagem do idioma português do Brasil terá o nome pt_BR.xml. O país pode ser ignorado, substituíndo o código do país por ALL. Por exemplo, um pacote do idioma português, tanto do Brasil quanto de qualquer país de língua portuguesa, terá o nome pt_ALL.xml. Por padrão, o pacote de mensagens usado é o arquivo ALL_ALL.xml. As melhores práticas recomendam sempre ter um pacote de mensagens com esse nome ao lidar com mensagens padrão. (API DE GADGETS, 2010c). Para indicar ao gadgets os idiomas disponíveis, deve-se declarar na seção de preferências do mesmo os arquivos correspondentes a cada idioma, usando o elemento Locale. Nesse elemento, o atributo lang indica o código do idioma e o
  38. 38. 37 atributo messages indica a URL do arquivo do pacote de mensagens. O atributo country também pode ser usado para definir o código do país do pacote. Como pode ser visto no exemplo do Quadro 14. 1 <ModulePrefs title="Olá Mundo"> 2 <Locale messages="http://exemplo.com/ALL_ALL.xml" /> 3 <Locale lang="pt" messages="http://exemplo.com/pt_ALL.xml" /> 4 <Locale lang="pt" country="BR" messages="http://exemplo.com/pt_BR.xml" /> 5 <Locale lang="en" messages="http://exemplo.com/en_ALL.xml" /> 6 </ModulePrefs> Quadro 14 - Definindo os idiomas de um gadget 3.2.1.2 Acessando o Pacote de Mensagens Para fazer referência a uma mensagem no conteúdo HTML do gagdet a seguinte convenção deve ser usada: __MSG_<nome>__ Por exemplo, ao invés de no conteúdo do gadget ser colocado: <b>Olá mundo</b> Usando a mensagem internacionalizada o conteúdo fica assim: <b>__MSG_hello__world__</b> As mensagens também podem ser acessadas via a API JavaScript, usando a função getMsg do objeto gadgets.Prefs, como pode ser visto no exemplo do Quadro 15. 1 var prefs = new gadgets.Prefs(); 2 var mensagem = prefs.getMsg('hello_world'); Quadro 15 - Acessando um pacote de mensagens via a API JavaScript Na versão 0.9 da API JavaScript foram adicionadas outras funções para auxiliar na internacionalização e localização de um aplicativo. Com essas novas funções é possível converter datas e horas bem como números. (OPENSOCIAL, 2010b, tradução própria). Para fazer uso dessas novas funções é necessário
  39. 39. 38 adicionar o elemento <Require feature="opensocial-i18n" /> na seção de preferências do gadget. As funções JavaScript se encontram no objeto gadgets.i18n. 3.3 API JAVASCRIPT DO OPENSOCIAL A API JavaScript disponibilizada pelo OpenSocial permite o acesso aos dados do usuário do aplicativo (gadget) e aos dados dos amigos do usuário. Permite também o compartilhamento desses dados e a criação de atividades. A API é dividida em três áreas principais:  Pessoas e relacionamentos: os usuários de um aplicativo geralmente possuem amigos;  Atividades: uma atividade é uma forma de notificar outros usuários sobre as ações do usuário do aplicativo;  Persistência: recurso que permite aos aplicativos armazenar dados e recuperá-los posteriormente. Muitas chamadas as funções da API do OpenSocial são assíncronas, isto é, elas não retornam os dados imediatamente quando invocadas. Ao invés disso, é criada uma solicitação no servidor do recipiente para retornar ou atualizar informações. Sendo assim, ao se invocar uma chamada da API, deve-se passar uma função de retorno de chamada (callback). Quando a solicitação no servidor estiver pronta, essa função de retorno será invocada. (OPENSOCIAL, 2010d). 3.3.1 OSAPI A especificação 0.9 do OpenSocial introduziu uma nova API JavaScript, chamada de OSAPI, que torna a requisição de dados e sua análise mais fáceis. Para manter a compatibilidade com a outra API JavaScript, essa nova API está disponível no namespace osapi. (OPENSOCIAL AND GADGETS SPECIFICATION GROUP, 2010d, tradução própria). Para usar essa nova API, deve-se requisitá-la ao recipiente, adicionando o código abaixo nas preferências do gadget:
  40. 40. 39 <Require feature="osapi"> Os exemplos em JavaScript serão apresentados usando a API JavaScript tradicional e a OSAPI. Até a versão 0.9 do OpenSocial a API JavaScript tradicional era a única disponível, por tanto a maioria dos gadgets ainda a usam. No entanto, de acordo com o rascunho da versão 1.1 do OpenSocial (OPENSOCIAL AND GADGETS SPECIFICATION GROUP, 2010b, tradução própria), a API JavaScript tradicional será depreciada em favor da OSAPI. 3.3.2 Pessoas Conforme definido pela documentação da API (OPENSOCIAL, 2010d), existem três tipos de pessoas no OpenSocial:  Viewer (Visualizador): o usuário conectado no navegador, ou seja, quem está vendo o aplicativo;  Owner (Proprietário): o usuário a quem o perfil ou aplicativo em questão pertence;  Friends (Amigos): os usuários que o proprietário ou visualizador adicionou como amigos no recipiente. Como mencionado anteriormente, todas as classes e funções da API JavaScript iniciam com o namespace opensocial. Um usuário e os seus amigos, por exemplo, são representados como objetos do tipo opensocial.Person. A classe opensocial.Person, que representa uma pessoa, possui as funções apresentadas no Quadro 16. Resumo da função Detalhes da função String getDisplayName() Obtém um nome de exibição de texto desta pessoa; seguramente retorna uma string útil. String getField(chave, parametros_opcionais) Obtém os dados para esta pessoa, associados à chave especificada. As chaves estão definidas em opensocial.Person.Field. String getId() Obtém um ID que pode ser associado a esta pessoa permanentemente.
  41. 41. 40 Resumo da função Detalhes da função Boolean isOwner() Retorna true (verdadeiro) se este objeto de pessoa representar o proprietário da página atual. Boolean isViewer() Retorna true (verdadeiro) se este objeto de pessoa representar o usuário conectado no momento. Quadro 16 - Funções da classe opensocial.Person Fonte: OpenSocial (2010g). Para recuperar uma informação específica de um objeto do tipo opensocial.Person, é utilizado a função getField, em que é passado um parâmetro do tipo opensocial.Person.Field, indicando qual informação deseja- se recuperar. No exemplo abaixo, é mostrado como se obter o campo idade de um objeto representando uma pessoa: var idade = pessoa.getField(opensocial.Person.Field.AGE); No Quadro 17 são mostrados os principais campos que uma pessoa pode apresentar. Campo Descrição ABOUT_ME Uma declaração geral sobre a pessoa, especificada como uma string. ADDRESSES Endereços associados à pessoa, especificados como uma matriz de Endereços. AGE A idade da pessoa, especificada como um número. CURRENT_LOCATION Localização atual da pessoa, especificada como um Endereço. DATE_OF_BIRTH Data de nascimento da pessoa, especificada como um objeto de Data. EMAILS Endereços de e-mail associados à pessoa, especificados como uma matriz de E-mails. GENDER O sexo da pessoa, especificado como um valor opensocial.Enum com a chave da propriedade enum fazendo referência ao valor opensocial.Enum.Gender. HAS_APP Um valor booleano indicando se a pessoa possui instalado o aplicativo atual. ID Um ID de string que pode ser associado a esta pessoa permanentemente. LANGUAGES_SPOKEN Lista dos idiomas que a pessoa fala, como códigos ISO 639-1, especificados como uma matriz de strings. NAME Um objeto opensocial.Name contendo o nome da pessoa.
  42. 42. 41 Campo Descrição NICKNAME Uma string representando o apelido da pessoa. PHONE_NUMBERS Telefones associados à pessoa, especificados como uma matriz de Telefones. STATUS O status, frase escolhida ou saudação da pessoa, especificada como uma string. THUMBNAIL_URL O URL da miniatura da foto da pessoa, especificado como uma string. Quadro 17 - Principais campos do objeto opensocial.Person.Field Fonte: OpenSocial (2010g). A lista completa dos campos podem ser consultados na documentação da API JavaScript em OpenSocial (2010g). Deve-se salientar que os campos disponíveis variam de rede social para rede social, e cada rede pode criar os seus próprios campos. Na rede social Orkut, por exemplo, esses dados não são fornecidos por padrão. Segundo Orkut (2010d): Para que um aplicativo acesse os dados do perfil de um usuário, o usuário deve ter acesso garantido ao aplicativo, instalando-o em seu perfil. O orkut não compartilhará PII (Informações pessoais identificáveis) com os aplicativos. Os aplicativos não terão acesso a números de telefone, endereços de e-mail, aniversários e endereços físicos dos usuários do orkut. Os dados disponibilizados para os aplicativos serão apenas os dados que os usuários marcarem como disponíveis para "todos". Os dados restritos a amigos ou amigos de amigos não ficarão disponíveis para os aplicativos. Portanto, o desenvolvedor de um aplicativo social deve estar atento a esses detalhes. Deve-se ter em mente que nem sempre os dados que seu aplicativo necessita estarão disponíveis, além de que eles podem variar conforme o recipiente do aplicativo. No Quadro 18 são apresentados alguns campos do perfil de uma pessoa e a sua política de acesso no Orkut, sendo que os campos marcados como “Informações pessoais identificáveis” não estarão disponíveis para o aplicativo. Campo do Orkut Campo do OpenSocial Política de acesso do Orkut Nome NAME (GIVEN_NAME) Disponível Sobrenome NAME (FAMILY_NAME) Disponível Sexo GENDER Disponível
  43. 43. 42 Campo do Orkut Campo do OpenSocial Política de acesso do Orkut Data de nascimento DATE_OF_BIRTH Informações pessoais identificáveis Cidade, Estado, País CURRENT_LOCATION e ADDRESSES Disponível CEP CURRENT_LOCATION e ADDRESS Informações pessoais identificáveis E-mail principal EMAILS Informações pessoais identificáveis Telefone residencial PHONE_NUMBERS Informações pessoais identificáveis Endereço ADDRESS Informações pessoais identificáveis Quadro 18 - Política de acesso de alguns campos dos perfis do Orkut Fonte: Orkut (2010d). 3.3.3 Requisições O Quadro 19 mostra uma função JavaScript que utiliza a API do OpenSocial para requisitar ao recipiente a lista de amigos do dono do aplicativo, bem como os dados do próprio dono. O Quadro 20 mostra a mesma função usando a OSAPI. 1 function requisicao() { 2 var idspec = opensocial.newIdSpec({ 'userId' : 'OWNER', 'groupId' : 'FRIENDS' }); 3 var req = opensocial.newDataRequest(); 4 req.add(req.newFetchPersonRequest('OWNER'), 'dono'); 5 req.add(req.newFetchPeopleRequest(idspec), 'amigos'); 6 req.send(resposta); 7 }; Quadro 19 - Função para requisitar a lista de amigos do dono do aplicativo 1 function requisicao() { 2 osapi.people.getViewerFriends(resposta); 3 }; Quadro 20 - Função para requisitar a lista de amigos do dono do aplicativo usando a OSAPI Na linha 2 do Quadro 19, é criado um objeto do tipo opensocial.Idspec. Este objeto vai indicar a requisição que será criada e quais os dados que serão retornados. Neste caso serão retornados os dados do dono do aplicativo e os seus amigos.
  44. 44. 43 Caso se queira requisitar os dados do visualizador do aplicativo, seria necessário criar o mesmo objeto da seguinte forma: var idspec = opensocial.newIdSpec({ 'userId' : 'VIEWER', 'groupId' : 'FRIENDS' }); No construtor do objeto opensocial.IdSpec foram passadas as strings literais 'OWNER' e 'FRIENDS'. Pode-se também optar por usar as propriedades enums5 fornecidas pela API. Por exemplo, a linha 2 do Quadro 19 poderia ser reescrita da seguinte forma: var idspec = opensocial.newIdSpec({ 'userId' : opensocial.IdSpec.PersonId.OWNER, 'groupId' : 'FRIENDS' }); Nos quadros aqui apresentados são usados os valores literais, tornando o código-fonte mais legível. Na linha 3 do Quadro 19 é criado um objeto do tipo opensocial.DataRequest. Esse objeto é muito importante para o aplicativo. É ele que representa uma requisição ao recipiente. Nele podem ser adicionados vários itens de requisição. Aliás, é aconselhável agrupar várias dessas requisições em um único objeto, de forma a aumentar o desempenho do aplicativo. Cada um dos itens adicionados à requisição é executado na ordem em que foi adicionado, ou seja, o primeiro item adicionado será executado por primeiro pelo recipiente que recebeu o pedido de requisição. Os itens que não podem ser executados juntos são executados paralelamente. (OPENSOCIAL, 2010g). Com o objeto que fará a requisição criado, indica-se o que se deve retornar. Para isso, na linha 4 do Quadro 19, é criado e adicionado na requisição um objeto newFetchPersonRequest. Na criação desse objeto é passada a string 'OWNER'como parâmetro. Isso instrui a requisição a retornar os dados do dono do aplicativo. Já o segundo parâmetro do construtor do objeto será usado para mapear os dados de resposta gerados. Na linha 5 do Quadro 19 é criado e adicionado na requisição um objeto newFetchPeopleRequest, passando como parâmetro ao construtor o objeto do ‒‒‒‒‒‒‒‒‒‒‒‒‒‒ 5 Enum é um tipo distinto que consiste em um conjunto de constantes nomeadas.
  45. 45. 44 tipo opensocial.Idspec, que havia sido criado na linha 2. Isso instrui o recipiente a retornar uma coleção de objetos representando os amigos do dono do aplicativo. Finalmente, na linha 6 do Quadro 19, é enviada a solicitação de dados ao servidor usando a função send do objeto opensocial.DataRequest. Como parâmetro dessa função é passada outra função: resposta. A função resposta será chamada pelo recipiente quando a requisição for processada e retornada para o aplicativo. Como dito anteriormente, esta é a função de retorno de chamada (callback). No Quadro 21 é apresentada a função que irá processar os dados recebidos do recipiente pelo aplicativo, após o término da requisição. 1 function resposta(dadosResposta) { 2 if (dadosResposta.hadError()) { 3 document.write(dadosResposta.getErrorMessage()); 4 } else { 5 var dono = dadosResposta.get('dono').getData(); 6 var amigos = dadosResposta.get('amigos').getData(); 7 var html = 'Amigos de ' + dono.getDisplayName(); 8 html += ':<br><ul>'; 9 amigos.each(function(pessoa) { 10 html += '<li>' + pessoa.getDisplayName() + '</li>'; 11 }); 12 html += '</ul>'; 13 document.write(html); 14 } 15 } Quadro 21 - Função para processar o retorno da requisição da lista de amigos A função de retorno de chamada receberá como parâmetro um objeto do tipo opensocial.DataResponse, como pode ser visto na linha 1 do Quadro 21. Esse objeto conterá os dados solicitados ao recipiente. Primeiro deve ser verificado se a reposta retornou algum erro (linha 2). Em caso afirmativo, é exibida a mensagem do erro (linha 3). Nas linhas 5 e 6 do Quadro 21 são recuperados os objetos que representam o dono do aplicativo e os seus amigos. Como pode ser observado, o parâmetro passado à função get é o mesmo que havia sido passado a função add na linhas 4 e 5 do Quadro 19. Tendo os objetos recuperados, agora basta formatar a sua exibição no aplicativo. É utilizada a função getDisplayName dos objetos que representam as
  46. 46. 45 pessoas para criar uma lista em HTML com o nome de exibição das pessoas, que por último é escrita na tela (linha 13). Uma visão completa do exemplo mostrado nas listagens anteriores pode ser vista no Quadro 22. 1 <?xml version="1.0" encoding="UTF-8" ?> 2 <Module> 3 <ModulePrefs title="Listar amigos"> 4 <Require feature="opensocial-0.8" /> 5 </ModulePrefs> 6 <Content type="html"> 7 <![CDATA[ 8 <script type="text/javascript"> 9 function requisicao() { 10 /* Ver o Quadro 19 */ 11 }; 12 13 function resposta(dadosResposta) { 14 /* Ver o Quadro 21 */ 15 } 16 17 gadgets.util.registerOnLoadHandler(requisicao); 18 </script> 19 ]]> 20 </Content> 21 </Module> Quadro 22 - Listando os amigos do dono de um aplicativo Como pode ser visto no Quadro 22, para que a função requisicao seja executada assim que o aplicativo for carregado, é utilizada a função gadgets.util.registerOnLoadHandler (linha 17), pertencente a API de gadgets. Em resumo, um aplicativo que requisita informações sobre alguma pessoa deve seguir os seguintes passos:  Criar um objeto opensocial.DataRequest (representando um requisição) usando a função opensocial.newDataRequest;  Criar os itens que serão adicionados a requisição usando as funções opensocial.new...;  Para cada item criado, adicionar a requisição através da função add do objeto opensocial.DataRequest;
  47. 47. 46  Chamar a função send do objeto opensocial.DataRequest, passando uma função de retorno de chamada (callback);  Criar a função de retorno de chamada (callback) que irá receber como parâmetro um objeto do tipo opensocial.DataResponse, contendo os dados com a resposta da requisição. 3.3.4 Atividades Uma atividade em uma rede social pode ser definida como uma forma de comunicação ou como o compartilhamento de informação. A criação de atividades é uma ótima maneira de divulgar um aplicativo. O OpenSocial fornece ao desenvolvedor a capacidade de requisitar a criação dessas atividades através da sua API. (GREWE, 2009, p. 130, tradução própria). No OpenSocial atividades podem incluir:  Envio direto de e-mail aos usuários;  Notificações;  Atualizações do usuário (e também atualizações dos amigos);  Requisições para instalar um aplicativo (convites). Os recipientes podem controlar o limite de atividades que um aplicativo pode criar. O Orkut, por exemplo, define que o aplicativos ficarão restritos à criação de três atualizações do fluxo de atividades por aplicativo, por dia, para cada usuário. (ORKUT, 2010d). Como o limite de atividades pode variar de rede social para rede social, é importante ao desenvolvedor consultar a documentação de cada rede. 3.3.4.1 Mensagens de E-mail e Notificações Os seguintes passos são necessários para a criação de uma mensagem:  Criar o objeto representando a mensagem, usando a função opensocial.newMessage, passando como parâmetros o corpo (texto) da mensagem e outros campos da mensagem;
  48. 48. 47  Chamar a função opensocial.requestSendMessage passando como parâmetros o destinatário da mensagem e a mensagem propriamente dita. Há vários tipos de mensagens que podem ser criadas. O tipo da mensagem é passado como parâmetro na construção do objeto da mensagem. O Quadro 23 lista os tipos de mensagens que podem ser criados. Campo Descrição EMAIL Um e-mail. NOTIFICATION Uma mensagem privada curta. PRIVATE_MESSAGE Uma mensagem enviada a um usuário específico, que pode ser vista somente por esse usuário. PUBLIC_MESSAGE Uma mensagem enviada a um usuário específico, que pode ser vista por outras pessoas além desse usuário. Quadro 23 - Principais campos do objeto opensocial.Message.Field.Type Fonte: OpenSocial (2010g). Na construção do objeto da mensagem também podem ser passados os campos que formarão a mensagem. Esses campos são apresentados no Quadro 24. Campo Descrição BODY O texto principal da mensagem. Atributos HTML são permitidos e limpos pelo recipiente. BODY_ID O texto principal da mensagem como um modelo de mensagem. Especifica o ID de mensagem que será usado no código XML do gadget. TITLE O título da mensagem. Atributos HTML são permitidos e limpos pelo recipiente. TITLE_ID O título da mensagem como um modelo de mensagem. Especifica o ID de mensagem que será usado no código XML do gadget. TYPE O título da mensagem, especificado como um opensocial.Message.Type. Quadro 24 - Principais campos do objeto opensocial.Message.Field Fonte: OpenSocial (2010g). O Quadro 25 exemplifica a criação de uma mensagem de e-mail, que será enviada para o usuário que está visualizando o aplicativo. O Quadro 26 faz o mesmo, porém, usando a OSAPI.
  49. 49. 48 1 var parametros = {}; 2 parametros[opensocial.Message.Field.TITLE] = 'Título do e-mail'; 3 parametros[opensocial.Message.Field.TYPE] = opensocial.Message.Type.EMAIL; 4 var mensagem = opensocial.newMessage('Corpo do e-mail', parametros); 5 var destinatario = 'VIEWER'; 6 opensocial.requestSendMessage(destinatario, mensagem); Quadro 25 - Enviando uma mensagem de e-mail 1 var mensagem = {}; 2 mensagem.title = 'Título do e-mail'; 3 mensagem.body = 'Corpo do e-mail'; 4 mensagem.type = opensocial.Message.Type.EMAIL; 5 var destinatario = 'VIEWER'; 6 osapi.ui.requestSendMessage(destinatario, mensagem); Quadro 26 - Enviando uma mensagem de e-mail usando a OSAPI Caso fosse desejado enviar uma notificação ao invés de uma mensagem de e-mail, seria necessário mudar o tipo da mensagem de opensocial.Message.Type.EMAIL para opensocial.Message.Type.NOTIFICATION. 3.3.4.2 Atualizações As atividades geradas por um usuário ou os amigos do usuário são geralmente exibidas nas redes sociais sob o título de "Atualizações". No OpenSocial, uma atividade é representada pela classe opensocial.Activity. Os seguintes passos são necessários para a criação de uma atividade:  Criar o objeto representando a atividade, usando a função opensocial.newActivity, passando os parâmetros que definem a atividade;  Chamar a função opensocial.requestCreateActivity passando como parâmetros a atividade e a prioridade da atividade. Os parâmetros que podem ser passados na criação da atividade estão definidos em opensocial.Activity.Field, e podem ser vistos no Quadro 27.
  50. 50. 49 Campo Descrição APP_ID Uma string que especifica o aplicativo ao qual esta atividade está associada. BODY Uma string que especifica uma versão expandida opcional de uma atividade. BODY_ID Uma string que especifica o ID da mensagem do modelo de corpo nas especificações do gadget. EXTERNAL_ID O ID de uma string opcional gerado pelo aplicativo. ID O ID de uma string que é permanentemente associado a esta atividade. MEDIA_ITEMS Todas as fotos, vídeos ou imagens que devem ser associados à atividade. POSTED_TIME Uma string que especifica o tempo, em milissegundos, durante o qual esta atividade ocorreu a partir do horário inicial. PRIORITY Um número entre 0 e 1 que representa a prioridade relativa desta atividade em relação a outras atividades da mesma origem. STREAM_FAVICON_URL Uma string que especifica o URL do favicon6 do fluxo. STREAM_SOURCE_URL Uma string que especifica o URL de origem do fluxo. STREAM_TITLE Uma string que especifica o título do fluxo. STREAM_URL Uma string que especifica o URL do fluxo. TEMPLATE_PARAMS Um mapa dos pares personalizados de chave/valor associados a esta atividade. TITLE Uma string que especifica o texto principal de uma atividade. TITLE_ID Uma string que especifica o ID da mensagem do modelo de título nas especificações do gadget. URL Uma string que especifica o URL que representa esta atividade. USER_ID O ID da string do usuário ao qual esta atividade se destina. Quadro 27 - Campos do objeto opensocial.Activity.Field Fonte: OpenSocial (2010g). Uma atividade pode ter as seguintes prioridades:  opensocial.CreateActivityPriority.HIGH: prioridade alta;  opensocial.CreateActivityPriority.LOW: prioridade baixa. Se for solicitada prioridade alta, o aplicativo solicitará a permissão do usuário para criar as atividades em seu nome, caso ainda não tenha permissão. Se for ‒‒‒‒‒‒‒‒‒‒‒‒‒‒ 6 Ícone usado para representar um site favorito (bookmark) no navegador.
  51. 51. 50 solicitada prioridade baixa, a chamada não fará nada se o aplicativo não tiver permissão para a criação de atividades. O Quadro 28 mostra um exemplo de criação de uma atividade enquanto o Quadro 29 mostra um exemplo usando a OSAPI. 1 var parametros = {}; 2 parametros[opensocial.Activity.Field.TITLE] = 'Título da atividade'; 3 var atividade = opensocial.newActivity(parametros); 4 opensocial.requestCreateActivity(atividade, opensocial.CreateActivityPriority.HIGH); Quadro 28 - Criando uma atividade 1 var atividade = {}; 2 atividade.title = 'Título da atividade'; 3 osapi.activities.create({ userId: '@viewer', activity: atividade }); Quadro 29 - Criando uma atividade usando a OSAPI 3.3.4.3 Convites O OpenSocial permite aos usuários convidar os seus amigos para usar um aplicativo. Para isso, basta chamar a função opensocial.requestShareApp, passando como parâmetros o ID de um ou mais usuários e o motivo pelo o qual o usuário deseja compartilhar o aplicativo. Um exemplo de criação de um convite pode ser visto no Quadro 30 e no Quadro 31 usando a OSAPI. 1 var motivo = opensocial.newMessage('Veja que legal esse aplicativo!'); 2 opensocial.requestShareApp('VIEWER', motivo); Quadro 30 - Criando um convite para um usuário 1 var motivo = 'Veja que legal esse aplicativo!'; 2 osapi.ui.requestShareApp('@viewer', motivo); Quadro 31 - Criando um convite para um usuário usando a OSAPI
  52. 52. 51 3.3.5 Persistência A API do OpenSocial permite salvar e recuperar dados por usuário e por aplicativo. Esses dados serão sempre armazenados na forma de strings. Os dados são armazenados em pares chave-valor. (OPENSOCIAL, 2010d). Como só strings podem ser armazenadas, é sugerido converter os dados que serão armazenados para o formato JSON. Assim, o dado será gravado como uma string, mas irá manter a estrutura original do objeto. Posteriormente, quanto esse dado for recuperado, a string armazenada pode ser convertida para um objeto JSON. As funções para a conversão de string para JSON e de JSON para string estão na API de gadgets:  gadgets.json.parse: analisa uma string JSON, produzindo um valor JavaScript;  gadgets.json.stringify: converte um valor JavaScript em uma string JSON. 3.3.5.1 Armazenando Dados Para armazenar um valor, deve-se usar a função opensocial.newUpdatePersonAppDataRequest, passando como parâmetros o ID da pessoa, o nome da chave e por último o seu valor. Atualmente, somente o ID especial de VIEWER é permitido. O nome da chave pode conter caracteres alfanuméricos (A-Z; a-z; 0-9), sublinhado( _ ), ponto ( . ) ou hífen ( - ) e o valor deve ser um valor válido no formato JSON. (OPENSOCIAL, 2010g). No Quadro 32 é apresentado um exemplo de como gravar um dado e no Quadro 33 de como gravar um dado usando a OSAPI. 1 var requisicao = opensocial.newDataRequest(); 2 var atualizacao = requisicao.newUpdatePersonAppDataRequest('VIEWER', 'cor', 'verde'); 3 requisicao.add(atualizacao); 4 requisicao.send(); Quadro 32 - Gravando um dado
  53. 53. 52 1 var dados = {}; 2 dados.cor = 'verde'; 3 osapi.appdata.update({ userId: '@viewer', data: dados }); Quadro 33 - Gravando um dado usando a OSAPI 3.3.5.2 Recuperando Dados A recuperação dos dados gravados é feita através da função opensocial.newFetchPersonAppDataRequest. Essa função recebe como parâmetros um objeto opensocial.IdSpec para especificar quais pessoas devem ser obtidas e o nome de uma ou mais chaves das quais se deseja obter os dados. Um exemplo de como recuperar dados usando a OSAPI pode ser visto no Quadro 34. 1 function recuperarDados() { 2 osapi.appdata.get({ 3 userId: '@owner', 4 keys: ['cor'] 5 }).execute(retorno); 6 } Quadro 34 - Recuperando um dado usando a OSAPI No Quadro 35 pode ser visto um exemplo de como recuperar dados usando a API JavaScript tradicional. A função JavaScript retorno receberá os dados da requisição.
  54. 54. 53 1 function recuperarDados() { 2 var idSpec = opensocial.newIdSpec({ 'userId' : 'OWNER' }); 3 var requisicao = opensocial.newDataRequest(); 4 var visualizador = requisicao.newFetchPersonRequest(opensocial.IdSpec.PersonId.VIEWER ); 5 var recuperacao = requisicao.newFetchPersonAppDataRequest(idSpec, 'cor'); 6 requisicao.add(visualizador, 'visualizador'); 7 requisicao.add(recuperacao, 'dados'); 8 requisicao.send(retorno); 9 } 10 function retorno(retorno) { 11 if (retorno.hadError()) { 12 document.write(retorno.getErrorMessage()); 13 } else { 14 var visualizador = retorno.get('visualizador').getData(); 15 var dados = retorno.get('dados').getData(); 16 var cor = dados[visualizador.getId()]['cor']; 17 document.write('Cor: ' + cor); 18 } 19 } Quadro 35 - Recuperando um dado 3.3.5.3 Excluindo Dados Para excluir um dado do armazenamento, basta chamar a função opensocial.newRemovePersonAppDataRequest, passando como parâmetros o ID da pessoa a ser atualizada (somente o ID especial de VIEWER é permitido) e o nome de uma ou mais chaves a serem excluídas. Um exemplo pode ser visto no Quadro 36 e no Quadro 37 usando a OSAPI. 1 requisicao = opensocial.newDataRequest(); 2 var atualizacao = requisicao.newRemovePersonAppDataRequest('VIEWER', 'chave'); 3 requisicao.add(atualizacao); 4 requisicao.send(); Quadro 36 - Excluíndo um dado 1 appdata.delete({ 2 userId: '@viewer', 3 keys: ['chave'] 4 }); Quadro 37 - Excluíndo um dado usando a OSAPI
  55. 55. 54 3.4 API RESTFUL DO OPENSOCIAL Como alternativa a API JavaScript no lado do cliente existe a API RESTful, que permite uma interação entre os servidores de terceiros com os servidores das redes sociais. Ou seja, é possível desenvolver aplicativos sociais que sejam executados fora de um recipiente. Para realizar o serviço de autenticação e autorização é utilizado o protocolo OAuth. Em cada chamada REST são passados os parâmetros do OAuth pela URL. Adicionalmente à API RESTful, há também uma API RPC (Remote Procedure Call) para o OpenSocial, com as mesmas funcionalidades. Aplicativos baseados no servidor podem se comunicar diretamente com uma rede social (recipiente) de uma forma independente de linguagens usando a API RESTful do OpenSocial. O OpenSocial exige que o aplicativo passe por um processo de autorização (ou autenticação). Uma vez completado, isso permite ao programa fazer requisições REST seguras diretamente para o recipiente da rede social. Cada requisição terá associada a informação de autenticação apropriada. (GREWE, 2009, p. 175, tradução própria). A API RESTful define os seguintes recursos: Atividade, Pessoa, Grupo e Dados do Aplicativo. Os recursos podem ser representados em três formatos: JSON, XML e Atom. A maioria das operações realizadas sob esses recursos consistem de recuperação (GET), atualização (PUT), criação (POST ou PUT) ou destruição (DELETE). (OPENSOCIAL AND GADGETS SPECIFICATION GROUP, 2009, tradução própria). A estrutura do objeto de resposta de uma requisição REST bem sucedida, no formato JSON, é apresentado no Quadro 38. 1 { 2 "startIndex" : 1, 3 "itemsPerPage" : 10, 4 "totalResults" : 100, 5 "entry" : [ 6 {...primeiro item...}, 7 {...segundo item...} 8 ... 9 ] 10 } Quadro 38 - Estrutura do objeto de resposta de uma requisição REST
  56. 56. 55 No Quadro 38, estão representados:  startIndex: o índice do primeiro resultado retornado na resposta;  itemsPerPage: o número de resultados retornados;  totalResults: o número total de resultados;  entry: uma matriz com os objetos que foram requisitados (pessoas, por exemplo). A criação de uma chamada REST do OpenSocial envolve a construção de uma URL, a especificação do tipo do método HTTP (GET, POST, PUT, DELETE) e a criação de quaisquer dados e parâmetros necessários. (GREWE, 2009, p. 198, tradução própria). As redes sociais que suportam a API RESTful do OpenSocial têm uma URL base para onde as chamadas deverão ser efetuadas. A URL base do Orkut, por exemplo, é http://www.orkut.com/social/rest. Após essa URL base, são adicionados outros fragmentos e parâmetros. Por exemplo, a URL completa para retornar os dados da pessoa no Orkut é http://www.orkut.com/social/rest/people/@me/@self. Caso seja necessário que o resultado retorne no formato XML a URL da chamada será http://www.orkut.com/social/rest/people/@me/@self?format=xml. A Figura 4 mostra as partes que compõe a URL da chamada REST apresentada como exemplo. Figura 4 - Partes que compõe a URL de uma chamada REST do OpenSocial Fonte: Autoria própria. Na URL de exemplo foram usados dois seletores: @me e @self. Os seletores são usados para representar uma pessoa ou um grupo. Existem os seguintes seletores:  @me: para representar o usuário da aplicação;  @self: para representar a pessoa que está requisitando a solicitação;  @all: para representar todo um conjunto;  @friends: para representar o subconjunto de amigos; http://www.orkut.com/social/rest URL base /people/@me/@self Fragmento ?format=xml Parâmetros
  57. 57. 56  @app: para representar a aplicação que está fazendo a solicitação. A seguir são apresentados os fragmentos que podem ser usados na chamada de uma requisição REST. O termo {guid} é usado para representar o identificador de usuário único e global (globally-unique user identifier), o termo {pid} representa o registro de uma pessoa dentro de uma coleção, {groupid} representa o identificador do grupo e o termo {appid} representa o identificador do aplicativo. No Quadro 39 são apresentados os fragmentos que podem ser usados na construção da URL para retornar dados sobre uma pessoa. O Quadro 42 apresenta o fragmento usado para retornar os dados de um grupo. Fragmento da URL Descrição /people/{guid}/@all Coleção de todas as pessoas conectadas ao usuário {guid}. /people/{guid}/@friends Coleção de todos os amigos do usuário {guid}. Subconjunto de @all. /people/{guid}/{groupid} Coleção de todas as pessoas conectadas ao usuário {guid} no grupo {groupid}. /people/{guid}/@all/{pid} Registro individual de uma pessoa específica e conhecida de {guid}. Mostra a visão de {pid} através de {guid}. /people/{guid}/@self Registro do perfil do usuário {guid}. /people/@me/@self Registro do perfil do solicitante /people/@supportedFields Returna todos os campos que o recipiente suporta nos objetos de pessoas. /people/{guid}/@deleted Essa é uma API opcional que irá retornar todas as pessoas conectadas ao usuário {guid} e que foram excluídas. Isso deve ser normalmente usado em conjunto com o parâmetro updatedSince. Quadro 39 - Fragmentos da URL para o recurso Pessoa Fonte: Opensocial and Gadgets Specification Group (2009, tradução própria). Um exemplo da representação de uma pessoa no formato JSON é mostrado no Quadro 40, enquanto no Quadro 41 a mesma pessoa é representada no formato XML.

×