1

VISHVESHWARAIAH TECHNOLOGICAL UNIVERSITY

S.D.M COLLEGE OF ENGINEERING AND TECHNOLOGY

A seminar report on

OPENSOCIAL

Submitted by

Sarah Ganihar

2SD06CS089

8th semester

DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

2009-10

2

VISHVESHWARAIAH TECHNOLOGICAL UNIVERSITY

S.D.M COLLEGE OF ENGINEERING AND TECHNOLOGY

DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

CERCERCERCERTTTTIIIIFFFFIIIICCCCATATATATEEEE Certified that the seminar work entitled “Opensocial” is a bonafide work presented by Sarah

Ganihar bearing USN NO 2SD06CS089 in a partial fulfillment for the award of degree

of Bachelor of Engineering in Computer Science Engineering of the Vishveshwaraiah

Technological University, Belgaum during the year 2009-10. The seminar report has been

approved as it satisfies the academic requirements with respect to seminar work presented for

the Bachelor of Engineering Degree.

Staff in charge H.O.D

Name: Sarah Ganihar

USN:2SD06CS089

3

CONTENTS

1. INTRODUCTION 4

2. HISTORY 5

3. OPENSOCIAL API

3.1 JAVASCRIPT API 6

3.2 RESTFUL API 7

4. FEATURES OF OPENSOCIAL API 8

4.1 MANY SITES, ONE API

4.2 SERVER OPTIONAL

4.3 LEARN ONCE,REACH ACROSS WEB

4.4 HOSTING OPENSOCIAL APPS

5. KEY CONCEPTS 10

5.1 PEOPLE

5.2 RELATIONSHIP

5.3 ACTIVITIES

5.4 PERSISTENCE

5.5 VIEWS

6. API PATTERNS 14

6.1 MAKING REQUESTS

6.2 CAPABILITIES DISCOVERY

6.3 ACTION REQUESTS AND PERMISSIONS

6.4 CACHING

4

7. OPENSOCIAL CONTAINER 17

8. HOW IT WORKS 19

9. A SIMPLE APPLICATION 21

10. WHY OPENSOCIAL 24

10.1 ENGAGE QUICKLY

10.2 MIMIC LOOK AND FEEL

10.3 ENABLE SELF EXPRESSION

10.4 EXPOSE FRIEND ACTIVITY

10.5 MAKE IT DYNAMIC

10.6 BROWSE THE GRAPH

10.7 DRIVE COMMUNICATION

10.8 BUILD COMMUNITIES

10.9 STATUSMOODCOMMENTS

10.10 PROFILE COMMENTS

11. REFERENCES 28

5

1.INTRODUCTION

The web is more interesting when you can build apps that easily interact with your friends and colleagues. But with the trend towards more social applications also comes a growing list of site-specific APIs that developers must learn.[1]

OpenSocial defines a common API for social applications across multiple websites. With standard JavaScript and HTML, developers can create apps that access a social network's friends and update feeds.

In web development, a mashup is a web page or application that combines data or functionality from two or more external sources to create a new service. The term mashup implies easy, fast integration, frequently using open APIs and data sources to produce results that were not the original reason for producing the raw source data. An example of a mashup is the use of cartographic data to add location information to real estate data, thereby creating a new and distinct web API that was not originally provided by either source.

. Applications implementing the OpenSocial APIs will be interoperable with any social network system that supports them, including features on sites such as Hi5.com, Myspace, orkut.com, sonico.com, Friendster and Yahoo . Based on HTML and Javascript as well as the google gadgets framework, OpenSocial includes four APIs for Social software applications to access data and core functions on participating social networks. Each API addresses a different aspect: one is the general Javascript API, one for People and Friends (people and relationship information), one for Activities (publishing and accessing user activity information), and one for Persistence (simple key-value pair data for server-free stateful applications). OpenSocial is currently in alpha development. The initial version of the API that was made public was 0.5, followed by version 0.6 released on December 1 2007 .Version 0.7 was released on February 4, 2008.Version 0.8 was released on May 28, 2008.

For launch, partners committed to supporting the OpenSocial APIs included the social

network companies Bebo, Engage.com, Friendster, hi5, Hyves, imeem, NetModular, mixi, MySpace, Ning, orkut, Plaxo, Six Apart; as well as business-oriented networking companies LinkedIn, Tianji, Salesforce.com, Viadeo, Oracle, and XING,Plaxo and Ning released OpenSocial support within the first day of the launch, with Plaxo adding OpenSocial support to its Pulse feature, and Ning adding basic OpenSocial support ahead of its previously announced release of full support in late 2007 to early 2008.

2.HISTORY

OpenSocial was rumored to be part of a larger social networking initiative by Google code-named "Maka-Maka", which is defined as meaning "intimate friend with whom one is on

6

terms of receiving and giving freely" in Hawaiian.[4]

Opened to much fanfare in news coverage, OpenSocial did not work well in the beginning; it only ran on Google-owned Orkut, and only with a limited number of gadgets, returning errors for other gadgets. Other networks were still looking into implementing the framework.

As reported by TechCrunch on November 5, 2007, OpenSocial was also quickly cracked. The total time to crack the OpenSocial-based iLike on Ning was just 20 minutes, according to TechCrunch, with the attacker being able to add and remove songs on a user's playlist, and to look into information on their friends.

On December 6, TechCrunch followed up with a report by MediaPops founder Russ Whitman, who said "While we were initially very excited, we have learned the hard way just how limited the release truly is." Russ added that "core functionality components" are missing and that "write once, distribute broadly" was not accurate.

OpenSocial is commonly described as a more open cross-platform alternative to the FacebookPlatform, a proprietary service of the popularsocial network service Facebook. After launching Facebook Platform in late May 2007, as well as acquiring startup web desktop company Parakey in mid-July 2007,the fast-growing Facebook has been widely reported as a challenger to Google in establishing and leveraging a ubiquitous web operating system.Compared to Facebook, which is ranked second by page views worldwide for the month of September 2007, Google's social network orkut is ranked sixth for the same month, with more than half its members living in Brazil.

Reports on competition between the two companies increased with Facebook scheduling an announcement of an online advertising initiative (named Facebook Ads) the day after Google's social networking announcement was originally scheduled(November 6, 2007). The initiative includes ad serving and targeting programs (named Facebook Social Ads and Facebook Insights, respectively) in competition with Google's market-leading AdSense and AdWords programs.[2][3]

3. OpenSocial API 3.1 JavaScript API

The JavaScript API lives under the opensocial.* namespace and provides access to three primary areas of functionality:

People -- information about individual people and their relationships to each other. For eg facebook provides you to view your friends and friends of friends if any.

Activities -- ability to post and view updates on what people are doing. Persistence -- a simple key-value data store to allow server-free stateful applications.

7

Here are some of the things you can do with the JavaScript API:

o Build applications without maintaining your own server

o Build applications that include a server-side component (for offline processing and/or access from other websites)

o Expose existing web applications in the context of existing social websites

o Add social features to existing gadgets

o Write one application that can run in the context of many different social websites

The JavaScript API is designed to use standard web technologies:

It's packaged as a set of methods in the opensocial.* namespace and allows you to use any standard JavaScript programming techniques and third-party libraries. It includes a full asynchronous callback system to support rich AJAX interactivity.

3.2 RESTFUL API The RESTful Data API will provide complementary functionality to the JavaScript API, so you can access people, activities, and data from your server.The RESTful data API is also designed to use standard web technologies: Server interactions are based on the RESTful AtomPub protocol. Authentication is handled by OAuth.

This API defines a language- and platform- neutral protocol for clients to interact with OpenSocial container servers outside of gadgets on a web page. As a protocol, it is intended to be reasonably easy to implement in any language and on any platform. It should also be usable across a range of clients, from gadgets operating within a web page to servers communicating to synchronize data about a user. The protocol operates primarily in terms of resources and operations on them. It is defined on top of the HTTP protocol, and uses the standard HTTP methods (GET, POST, PUT, DELETE, etc.) to retrieve and change server state.

No single data representation is ideal for every client. This protocol defines dual representations for each resource in two widely supported formats, JSON [RFC4627] and Atom/ AtomPub, using a set of generic mapping rules. The mapping rules allow a server to write to a

8

single interface rather than implementing the protocol twice. OpenSocial container servers are free to define additional representations but MUST support at least the JSON and Atom formats defined in this document.

The protocol defines Activity, Person, Group, and AppData resources and collections (resources which consist of a set of other resources). Most operations consist of retrieving (GET), updating (PUT), creating (POST or PUT), or destroying (DELETE) these resources. The protocol provides an optional feature to batch multiple requests together in a pipeline to avoid multiple HTTP round trips. Finally, it specifies an optional partial update feature which avoids sending large resources over the wire to update just one field.

4.Features of Opensocial API 4.1 Many sites, one API

A common API means you have less to learn to build for multiple websites. OpenSocial is

currently being developed by a broad set of members of the web community. The ultimate goal is for any social website to be able to implement the API and host 3rd party social applications. There are many websites implementing OpenSocial, including Engage.com, Friendster, hi5, Hyves, imeem, LinkedIn, MySpace, Ning, Oracle, orkut, Plaxo, Salesforce.com, Six Apart, Tianji, Viadeo, and XING.

4.2 Server optional

OpenSocial is built upon gadgets, so you can build a great, viral social app with little to no serving costs. With the Google Gadget Editor and a simple key/value API, you can build a complete social app with no server at all. Of course, you can also host your application on your own servers if you prefer. In all cases, Google's gadget caching technology can ease your bandwidth demands should your app suddenly become a worldwide success.

9

4.3 Learn Once, Reach Across the Web

One of the most important benefits of OpenSocial is the vast distribution network that developers will have for their applications. The sites that have already committed to supporting OpenSocial -- Bebo, Engage.com, Friendster, hi5, Hyves, imeem, LinkedIn, mixi, MySpace, Ning, Oracle, orkut, Plaxo, Salesforce.com, Six Apart, Tianji, Viadeo, and XING -- represent an audience of about 200 million users globally. Critical for time- and resource-strapped developers is being able to "learn once, write anywhere" -- learn the OpenSocial APIs once and then build applications that work with any OpenSocial-enabled websites.

4.4 Hosting OpenSocial Apps

Your website can host third party OpenSocial apps integrated with your site's social network. A site that can host OpenSocial apps is called an OpenSocial container. The basic requirements for containers are detailed in the OpenSocial API Specification. OpenSocial apps typically include gadgets, so you will need to provide a way to allow a user to add gadgets to their page. You can provide your own directory, link to hand-picked URLs, and/or allow users to add gadgets by URL. Gadgets are typically implemented as individual iframes within your containing page. To host OpenSocial apps, your website must implement the OpenSocial API Specification. In most cases, this means that you connect your own social network's backends to the OpenSocial Service Provider Interface (SPI), which is part of Shindig, to allow an OpenSocial app to access your site's data. However, it is possible to use data from another social network as well, should you prefer. The SPI implements:

• Adding and removing friends

• Adding and removing apps

• Storing activities

• Retrieving activity streams for self and friends

• Storing and retrieving per-app and per-app-per-user data

5 .Key Concepts

Social applications revolve around people and their relationships. OpenSocial provides a standard way for websites to expose their social graph and more. Seeing the activities of other people helps you stay up to date with your friends, and allows everything from resumes to videos to spread virally through the graph. OpenSocial also provides a way for application data to persist on a social networking site, as well as specifying the different ways that an application can be viewed within an OpenSocial container. Finally, OpenSocial defines an API through which users of web services, mobile devices, and desktop applications may interact with social

10

data. 5.1 People

It's people! Social graphs are made out of people! People are a fundamental part of social networking software and the OpenSocial API. The Person object provides access to a user's information. Part of this information is stored in the user's profile and, depending on the site, can include anything from "favorite TV shows" to "5 things you'll find in my bedroom." The other important user information is the set of connections they have in the social graph and this is covered in the Relationships section.

There are two Person objects that can be requested directly—the VIEWER and the

OWNER. To understand the distinction, imagine you're checking out a coworker's profile on Orkut. In this case, you are the VIEWER and your coworker is the OWNER. It's also common to view your own profile, in which case you are both the VIEWER and the OWNER, and some applications may choose to handle this case differently. OpenSocial also provides for the case of anonymous viewing, where the gadget will not be able to access the VIEWER's information.

The API Reference contains more detailed information about the Person class. A note about user IDs: One of the pieces of data that is always returned with a Person object is the user's ID. The user ID must be alphanumeric (A-Za-z0-9) and must uniquely identify the user in a container. This standardization is intended to allow for prefixing IDs with a domain name and separator to create globally unique IDs (e.g. "orkut.com:34KJDCSKJN2HHF0DW20394"). Note that there will likely be a size limit placed on user IDs to help manage storing IDs in a database. 5.2 Relationships

The ability to create relationships is what turns a multi-user application into social software. Being able to share information and interact with friends changes the dynamic of user experience—you're engaging with people, not software.

11

There are two representations of sets of people available to OpenSocial—

VIEWER_FRIENDS and OWNER_FRIENDS. In the case where you're checking out a coworker's profile, requesting VIEWER_FRIENDS will return the set of users that are friends with you, while requesting OWNER_FRIENDS will return the set of users that are friends with your coworker. Logically, if you're viewing your own profile, VIEWER_FRIENDS and OWNER_FRIENDS will be the same set of users. Also, if the container supports anonymous profile browsing, then the application won't be able to access the set of VIEWER_FRIENDS.

Note that OpenSocial makes no assumptions about the relationship between VIEWER

and OWNER. The VIEWER and OWNER could be friends, but if you're looking at a stranger's profile, there's no relationship between you, the VIEWER, and them, the OWNER.When an application wants to interact with or display data for "friends of friends", the OpenSocial specification supports extending a query for VIEWER_FRIENDS or OWNER_FRIENDS by a NETWORK_DISTANCE parameter. Containers can optionally support "friends of friends" queries, "friends of friends of friends" queries, and so on.

5.3 Activities

Since we can't be online all the time, it helps to have a record of what our friends have been interacting with a social application which allows you to learn new features and uses of the application, so activity streams are one of the major drivers for organic growth of applications.

OpenSocial exposes activity streams, which are a collection of actions a user has taken in

the context of a given container. These activities can include interaction with the container itself, such as updating your profile or installing a new gadget, or interaction with an OpenSocial application, such as sending your friend a virtual gift or setting a new high score in a game.

Activity templates allow application developers to define messages with placeholders for pieces of application or user data. This separation of data and presentation allows multiple activities to be combined into activity summaries—consolidated bundles of activities that let users know what their friends are up to without having to wade through a flood of messages.

The API Reference contains more detailed information about the Activity class. 5.4 Persistence

Applications can provide a richer user experience if they can save their state between sessions. OpenSocial defines a data store that applications can use to read and write user-specific

12

data. This data store can be read by anyone who can see the gadget, but only the VIEWER's user- scoped data is writable.

Clearly this free data store could be abused, so containers may implement quotas or rate

limits to preserve their disk space. However, OpenSocial does not currently define these policies. 5.5 Views

Containers can support several different locations where gadgets may be rendered. Such locations are formally called views (formerly Surfaces in earlier versions of the API). All gadgets (not just OpenSocial applications) have become view-aware. A gadget can ask which view it is currently being rendered on, as well as what views the container supports.

Containers may define their own views, but the specification defines the following standard views in the gadgets.views.ViewType object:

o Profile - A gadget on the profile view is rendered alongside other applications in

the user's profile, so it will be smaller and can't support passing URL parameters from the container to the gadget.

o Canvas - A gadget in the canvas view is rendered by itself, so it will have lots of real estate and URL parameters passed to the container page can be forwarded to the gadget.

o Home - A gadget in the home view is rendered on a private "homepage" where the OWNER is always the same person as the VIEWER. There may be multiple gadgets present in this view.

o Preview - A gadget in the preview view does not have access to either the OWNER or VIEWER objects. This view is intended to provide "test drive" functionality so that gadgets can demonstrate functionality for potential users.

In addition to requesting data about the current view, gadgets may also request that the container navigate the user to another view. Imagine a news gadget that normally runs in a small profile view that changes to a full canvas view if the user clicks on a headline to get more information. Gadgets can choose the best rendering context for their current state.

When navigating to another view, a gadget may also request a change in OWNER. For example, imagine an application that places a survey on the user's profile view. This application may want to provide links to the user's friends' profiles, so that the user can see which surveys his or her friends are currently displaying.

13

6.API Patterns

This section describes several common patterns in the OpenSocial API. 6.1 Making Requests

The OpenSocial API queries the container asynchronously for most of its calls, which is

why most OpenSocial methods don't directly return data, but rather allow you to specify a callback that will be executed when the server's response is ready. Of course, making lots of asynchronous requests isn't always ideal, so the API allows for batch requests to allow developers to ask for many pieces of information at once. A developer can create an opensocial.DataRequest and add several individual request objects to it. Upon receiving the DataRequest, the container can process each request optimally and return the results of each operation as a batched result object. Containers must preserve the semantics of executing requests in serial order, though. A request that contains a write and then a read must return the newly written data, while a request that contains a read and then a write must return the data that was present before the write took place.

6.2 Capabilities Discovery

The gadgets and OpenSocial specifications determine the common APIs that all containers will support, but there are cases where a certain method or a profile field will be offered as an extension in some containers. To help developers write gadgets that can take advantage of these extensions, yet degrade gracefully in their absence, these APIs include gadgets.util.hasFeature and opensocial.Environment.supportsField methods to query the container at runtime and determine which features are available.

6.3 Action Requests and Permissions

There are cases where a gadget may wish to perform an action that needs approval by the user or mediation by the container. OpenSocial supports "request" features that allow the container to decide how to handle the interaction with the user. Functions like opensocial.requestCreateActivity, and opensocial.requestPermission allow the

14

container to inject its own policy decisions into the gadget execution flow and notify the gadget of the result. Under this specification, it is equally valid for a container to defer to the user, always approve, always deny, or use any other method to determine responses to request calls. Additionally, this allows the container to enforce UI flows in a safe and integrated way.

6.4 Caching

When gadgets call makeRequest, the calls may be cached. This is great for reducing the load that your servers have to be able to handle, since OpenSocial applications may have millions of users, each requesting data from your server. However, this caching of makeRequest calls can wind up displaying old data to users if the content returned by your server changes often.

If you expect the content at the URL you are fetching to change frequently, you may

want to work around the automatic caching with a more finely grained method. You can define a refresh Interval parameter, which should be specified as the number of seconds that should elapse before the makeRequest call requests content from your servers again. For example, specifying 10 will mean that the container would only query the supplied URL once every 10 seconds, no matter how many people are using the application. Specifying 0 will query the server each time the function is called, effectively bypassing the cached version.

15

7.Opensocial Container

So what does it mean to be an OpenSocial container? In a practical sense, it means that a site can run any application built on the OpenSocial APIs. This implies a number of things:

1. The container must implement all methods in the JavaScript API

Reference.

Methods may return the error code opensocial.ResponseItem.NOT_IMPLEMENTED for a specific method if the container does not support a specific request. No additional public methods or classes may be put on the OpenSocial namespace at any level. The required methods and fields are defined in the following JavaScript files:

o address.js

o bodyType.js

o collection.js

o datarequest.js

o dataresponse.js

o email.js

o enum.js and so on.

2. The container must only use the specified extensibility mechanisms for any container-specific extensions.

Extra person, activity or other object fields should be defined in an enum under

the container's namespace, and the environment should allow applications to discover these fields. For example, if the field orkut.PersonField.SPECIAL_FIELD is defined as "orkut.specialPersonField", then opensocial.getEnvironment().supportsField("person","orkut.specialPerson Field") and opensocial.getEnvironment().supportsField(opensocial.Environment.Object Type.PERSON, orkut.PersonField.SPECIAL_FIELD) should both return true.

Any extra data request types should be available with a namespaced call like

myspace.newFetchAlbumRequest. The gadget would then use

16

batchRequest.add(myspace.newFetchAlbumRequest(...)).Any extra objects may be added to the container's own namespace. These objects can be returned from person.getField or other similar requests.

3. The container must satisfy the Gadgets API Specification.

In short, this requires handling three types of requests: the Gadget Rendering

Request, the Gadget Metadata Request, and the JavaScript Request. 4. The container must support the RESTful API Specification.

Containers must provide both JSON and AtomPub represenatations of data.

OpenSocial uses HTTP GET to retrieve, PUT to update in place, POST to create new, and DELETE to remove. POST operates on collections and creates new activities, persons, or app data within those collections.

17

8.How It Works?

The figure below shows how a gadget works in a social website. Firstly it takes the information needed for it’s working from the container website. The information needed includes information about his or her profile data and friend’s data. The gadget includes some simple html, and java scripts. Also a gadget can include some flash objects which is optional. The gadget sends a invoking function to container asking the particular data. It return a call back function which is used by the gadget for retrieve the data when the server’s response is ready, By using the built in functions the gadget can perform the required function. The different social networking sites like facebook, orkut, myspace, Hi5 and so on provide you with a set of API’s they’ve used in their site so that you can make use of it to create your own application. For eg facebook provides rather gives you the code for various applications like commenting on someone’s status, posting your activity, accessing friends and many such codes. Your job is to use them and create a whole new user experience which is the idea behind mashups. Orsiso(Organize, Socialize, Simplify) is one such application which can be called as a mashup.

It is basically a Singapore registered online livestreaming management/real-time internet startup (2007) and has been funded thus far by experienced technology business angels and with the support of the Singapore government IDM grants program.

Using opensocial platform you can create a new user experience aggregating different social networking sites, gaming sites, shopping, cooking, business and the list continues. Opensocial relies on the idea behind Web 2.0 which was developed for the users to make web more interactive and opensocial continues it.

There can be one more thing to worry about. As there are many users who create account on different sites and sometimes may forget their usernames and passwords. The solution to this is open ID. Open ID provides with a technology of what is known as RPX. RPX is a third party which you can use in your website that allows users to use any of their existing email IDs from facebook, Yahoo, Gmail, linkedIn to login to your site.

18

Fig 8.1

19

9. A simple Application 9.1 Writing a "Hello, World" gadget

The simplest gadget is just a few lines of code. This gadget displays the message "Hello,

world!":

<?xml version="1.0" encoding="UTF-8" ?>

<Module>

<ModulePrefs title="hello world example" />

<required feature=”opensocial=0.8’>

</ModulePrefs>

<Content type="html">

<![CDATA[

Hello, world!

]]>

</Content>

</Module> Note the following about the "Hello World" example:

o Gadgets are specified in XML. The first line is the standard way to start an XML file. This must be the first line in the file.

o The <Module> tag indicates that this XML file contains a gadget.

o The <ModulePrefs> tag contains information about the gadget such as its title, description, author, and other optional features.

o The line <Content type="html"> indicates that the gadget's content type is HTML.

o <![CDATA[ ...insert HTML here... ]]> is used to enclose HTML when a gadget's content type is html. It tells the gadget parser that the text within the CDATA section should not be treated as XML. The CDATA section typically contains HTML and JavaScript.

o </Content> signifies the end of the Content section.

20

9.2 Accessing People and Profiles

This is a simple example that lists the names of your friends. But first, it's important to understand the roles defined by the OpenSocial API: Viewer: the user logged into the browser. As a viewer you might be viewing your own page, or you might be viewing another user's profile.

Owner: the user who owns the profile or application in question.

Friends: users whom the owner or viewer has added as friends in the container.

The "List Friends" example discussed in this section fetches the viewer and the viewer's friends, and displays a list of the viewers friends. It illustrates how to fetch and operate on data in an OpenSocial application. The basic steps are as follows:

1. Retrieve the data.

o Create a DataRequest by calling opensocial.newDataRequest().

o Call DataRequest.add(request) once for each type of data you would like to retrieve.

o After you add all of the individual requests to your DataRequest object, call DataRequest.send(callback).

2. Implement a callback function to process the retrieved data.

o Once the server request has been processed, the callback function is executed. This function takes one DataResponse parameter that has the results of the request. In "List Friends", the DataResponse contains the viewer and the viewer's friends. The callback function processes the data in the DataResponse.

These steps are discussed in more detail below.

9.2.1 Retrieving the Data

To get information about a viewer and a list of the viewer's friends, you create a new

DataRequest object and add a request to it for each type of data you want to retrieve:

21

Function getData() {

var req = opensocial.newDataRequest();

req.add(req.newFetchPersonRequest(opensocial.DataRequest.PersonId.VIEWER),

'viewer');

req.add(req.newFetchPeopleRequest(opensocial.DataRequest.Group.VIEWER_FRIENDS

), 'viewerFriends');

req.send(onLoadFriends);}; The last parameter in the newFetch*Request() calls is a string key used to retrieve the data in the response. 9.2.2 Using a Callback Function to Process the Data

Let's suppose you did the example in the previous section. Now you want to do something with the returned data, which is of the type opensocial.DataResponse. The onLoadFriends() callback function below parses the DataResponse it takes as a parameter, and displays the names of the viewer and the viewer's friends:

function onLoadFriends(dataResponse) {

var viewer = dataResponse.get('viewer').getData();

var html = 'Friends of ' + viewer.getDisplayName();

html += ':<br><ul>';

var viewerFriends = dataResponse.get('viewerFriends').getData();

viewerFriends.each(function(person) {

html += '<li>' + person.getDisplayName() + '</li>';

});

html += '</ul>';

document.getElementById('message').innerHTML = html;

22

9.23 AN APPLICATION DEMO

9.23.1 SETTING THE ORKUT ENVIRONMENT Next, log into orkut and create an account if you don't have one. In order to access orkut sandbox please sign up here. Once your account is approved, enter the sandbox. The navigation bar on the left side of the page has an "Apps" heading with an "edit" link directly beside it, which takes you to a page for adding and managing applications. After clicking this link, you should see a text input for adding an application by URL. Enter the publicly accessible URL that you entered in your browser before (the location of your gadget specification) and click "add application." This will prompt you to give the application authorization to your profile, friends, activity stream, and

23

navigation bar. Grant it permission by clicking "add this app to my profile." This will return you to the previous page, where you can either click on the newly installed application under "My applications" or on the left side navigation menu. Click on your application in either location to navigate to the canvas page of the gadget. If you see "Hello, world!" then you've successfully installed your first gadget.

If something went wrong... If you receive an error message when adding the gadget, orkut is most likely having difficulty retrieving the file from your hosting service. Double check that the file is externally visible and that the XML is copied exactly as above. If you receive an error after installation, and you've already double checked the contents of the file, it is possible that the orkut sandbox is undergoing maintenance — wait a few moments and try refreshing your browser window. If you're making changes to your gadget spec but not seeing them reflected in the orkut sandbox, this is because the orkut sandbox currently caches your gadget spec to minimize the load on your server. Great for an application in production, but this can be a pain when you're actively developing your app. You can bypass the caching mechanism by adding "bpc=1" to the URL of the profile or canvas page that you're viewing. 9.23.2 GIVING GIFTS

Now it's time to implement the raison d'être of your gadget, giving gifts. In this section, we will modify the gadget to allow the viewer to give a gift to one of their friends. First, you'll need to modify the basic HTML in the gadget specification so that it can insert new information for gift giving into the layout. The resultant XML looks like this:

<?xml version="1.0" encoding="UTF-8"?>

<Module>

<ModulePrefs title="Gifts part 2 - Send Gifts">

<Require feature="opensocial-0.8"/>

</ModulePrefs>

<Content type="html">

<![CDATA[

<script type="text/javascript">

24

/* ... */

</script>

<div id='main'>

<div id='give'>

<form id='gift_form'>

Give <span id='gifts'></span> to <span id='friends'></span>. <a href='javascript:void(0);' onclick='giveGift();'>Give!</a>

</form>

</div>

</div>

]]>

</Content>

</Module>

Now that there are nice hooks into the HTML, modify the output of the friends list into a set of option tags for use within a select tag. This will allow you to select a friend to receive a gif

25

10. Why Opensocial? If you're new to developing social applications, it can be difficult to immediately grasp how good applications facilitate fun and meaningful social experiences. To accelerate your learning, there are a few light-hearted recommendations around building good social applications. Not all of these "best practices" are necessary in every case, but they might spark thoughts about finding new users, keeping old ones, and leveraging the social graph for fresh content and viral spread. [5] 10.1.Engage Quickly

Across containers, there's a common tendency for a user to take a chance on an unknown application, and shortly thereafter remove it if no immediate value is found. The lesson to be learned from this interaction is that first impressions really do matter, and it's necessary to engage the user quickly before attention is lost. To this end, we suggest you focus on the 30- second experience; before distracting the user with expert features or sending invites, slow down and give the user a simpler taste of what your application is about.

10.2.MimicLook and Feel

Across OpenSocial containers there can be a lot of variation in the look and feel of pages and profiles. When designing your application, it can help to attempt consistency with the container UI by using similar fonts, tabs and buttons.

In cases where applications strive for stronger identity, it can be good to create a UI look and feel which is slightly distinct but still aesthetically strong to play on a user's tastes and need for self expression.

10.3.EnableSelf Expression

The profile page in a container is often a representation of a user's identity, interests and tastes. From the perspective of the owner, it's a means for self expression and a starting point for exploring the social graph. From the perspective of viewers, it's a place to learn, communicate, and find shared interests. Applications best take advantage of the profile by enabling self expression through common interests around entertainment, brands and groups. Self expression is also enabled through specific forms of communication like gestures and gifts or conversations around special topics.

10.4. Make it Dynamic

26

Good social applications aren't only static badges of self expression; they dynamically

change to provide an interesting experience across sessions. Change can be derived from the social graph as friends interact with the application to change its state. Change can also occur as the application internally generates new content. In both cases, the day-to-day changes can help to keep an application interesting and desired over time.

10.5. Expose Friend Activity

A particularly easy way to make an application dynamic and social is to record and present the activities of friends who are using the application. This could be thought of as an application-specific activity stream in which the news and updates of friends are always presented in the context of the application itself. From these activities, users become more aware of how others are using the application, driving increased use and change.

10.6. Browse the Graph

Exposing the activities of friends is one method among many for passively browsing the social graph. Users are often interested in low-effort interactions like viewing a friend's most recent activity, comparing content and choices, and indirectly interacting through their own activity. In supporting this style of interactions, it's essential to make it easy to browse what friends are doing. This is often achieved by linking names to a user's container profile or even creating application-specific user profiles which provide an overview of a user's activity and content.

10.7.DriveCommunication Browsing friends' activities and content often flows well into conversation, creating an opportunity to develop deeper social interaction. In places where communication can happen, it's good practice to make the option explicitly available. This can be done in a more persistent, public manner through a comment system or sharing wall. It can also be done in private by linking into a container's messaging, email or instant messaging systems, or even through an internal communication layer like pokes or other simple gestures and messages.

10.8.BuildCommunities

A container's entire social graph is often huge, and even a user's immediate social circle might be too large for a user to easily track. By growing smaller communities and making them accessible, an application can provide rich and interesting functionality that enhances the overall social experience.

27

10.9 StatusMoodComments

This endpoint provides a way to fetch the comments posted on a user’s StatusMood updates. It also provides a way to request the comment author’s basic info (image, name and profile URL) along with the comments themselves. This could reduce the number of calls to the server you need to make if you plan on displaying the commenter’s data along with the comments. [6]

10.10 ProfileComments

This provides a way to fetch the comments posted on a user’s profile. It also provides a way to request the comment author’s basic info along with the comments, which again will reduce the number of calls to the server if that information is needed. [6]

11.REFERENCES

[1]. www.google.com

[2]^ Nicole, Kristen (2007-11-01). "Newsgator Joins OpenSocial". Mashable. Federated Media Publishing. Retrieved 2008-01-24.

[3]http://www.opensocket.org/blog/2007/11/11/opensocket-facebook-app-released-in-beta [4] www.wikipedia.com [5] http://googleblog.blogspot.com/2007/11/opensocial-makes-web-better.html [6] MySpace developer platform

28