OpenSocial Intro

OpenSocial

OpenSocial’s goal:
Make the web more social

The social internet
A social website..
Provides a feature that becomes more engaging as the number of users grows.
Uses relationships between people to present users interesting information.

The social internet Some social websites...

The social internet
A social website..
Has overhead to manage users and relationships.
Grows slowly because users must sign up to use the site.
What if we remove
the overhead?
Developers can focus on providing features, not managing users.

The social internet
A social network..
Manages large numbers of users and relationships.
Is slow to add new features.

The social internet Many social networks...

The social internet
How do we add new features to social networks?
Make the social network a platform.
Give creative developers the tools to add the features themselves.

The social internet
A social application...
Lets the social network manage users and relationships.
Adds new features to the social network.
Lets users “install” the application without signing up for new accounts.
Grows quickly because users are already communicating with each other.

The social internet Lots of social apps...

Need for a social API
How do we put apps in social networks?

A day in the life of a social app developer

Introduction to OpenSocial
Numbers:
19+ implemented Containers
40+ committed Containers
3000+ applications
400,000,000+ of users
In China:

The OpenSocial APIs
Client-side:
Gadgets XML
Gadgets JavaScript
OpenSocial JavaScript
Server-side:
RESTful protocol
RPC protocol
Versions:
0.6 - Client-side APIs introduced
0.7 - Server-side APIs introduced
0.81 (current) - Server-side APIs finalized

Gadgets
Not widgets, not sprockets, not gidgets, not wadgets

Gadgets
A gadget spec:
Is an XML file.
Defines metadata about an OpenSocial app.
Is highly cacheable and does not need a high performance server.
Gadgets use existing web standards
XML to define metadata.
HTML for markup.
JavaScript for interactivity.
CSS for presentation.

Gadgets
A gadget server:
Takes the gadget spec as input.
Performs optimizations on the gadget spec.
Outputs HTML , JavaScript , and CSS as one document.

Gadgets
A container:
Displays the social network’s user interface.
Opens an IFrame to the rendered gadget.
Containers and gadget servers are both run by the social network, but do not need to be on the same machine, or even domain.

Gadgets
Example gadget XML spec:
Uses HTML to print “Hello World”.
Colors the text red with CSS .
Alerts annoying message with JavaScript .
<?xml version="1.0" encoding="UTF-8" ?> <Module> <ModulePrefs title="Hello World!"> <Require feature="dynamic-height" /> </ModulePrefs> <Content type="html"><![CDATA[ <h1>Hello World</h1> <style type="text/css"> h1 { color: #dd0000; } </style> <script type="text/javascript“> alert(“Hello More!”); </script> ]]> </Content></Module> Live Demo

Gadgets
JavaScript utility functions for gadgets:
gadgets.io.makeRequest() Make cross-domain AJAX calls to remote servers.
gadgets.json.parse() and gadgets.json.stringify() Native JSON support.
gadgets.util.escapeString() Make text safe for display via innerHTML.
gadgets.util.registerOnLoadHandler() Execute code when the page is finished loading.

Gadgets
A gadget can require additional JS libraries (“features”).
minimessage – Display short messages to the user .
tabs – Create a tabbed user interface
dynamic-height - Change the size of your gadget in the container.
views - Navigate between different surfaces of the container.
skins - Make your gadget change its styles to match the container.
Containers may offer custom features...
<?xml version="1.0" encoding="UTF-8" ?> <Module> <ModulePrefs title="Hello World!"> <Require feature="dynamic-height" /> </ModulePrefs> <Content type="html"> <![CDATA[ ... ]]> </Content> </Module> Live Demo

Gadgets
What are views?
Gadgets can render in different locations on a container.
Rendering area changes from small to large.
Certain pages might be public, some are private.
Containers may have different policies depending on the page, especially when the gadget displays ads.
Views provide a way for gadgets to provide different functionality depending on where it is rendered.

Gadgets
iGoogle "home" view:
On iGoogle, the "home" view is a small, private page that does not allow ads.

Gadgets
iGoogle "canvas" view:
Large private view, allows ads.

Gadgets
Working with views in the gadget XML:
<Content> sections are repeated for each view .
Add a view="view name" attribute to each section.
Content sections may support multiple views, for example view="home,canvas"
<?xml version="1.0" encoding="UTF-8" ?> <Module> <ModulePrefs title="Hello World!"> <Require feature=“views" /> </ModulePrefs> <Content type="html" view="home" > <![CDATA[ ... ]]> </Content> <Content type="html" view="canvas" > <![CDATA[ ... ]]> </Content> </Module> Live Demo

Gadgets <?xml version="1.0" encoding="UTF-8" ?><Module> <ModulePrefs title="Hello Social!"> <Require feature="opensocial-0.8" /> </ModulePrefs> <Content type="html"> <![CDATA[ ... ]]> </Content> </Module> The OpenSocial JavaScript API is a gadget feature, too! Live Demo

The OpenSocial JavaScript API

Making Gadgets Social
Gadgets can become social with OpenSocial JavaScript API
OpenSocial API has three core services:
People & Friends
Access profile information
Access friends information
Activities
See what you’re friends are up to
Share what you are doing
Persistence
Provide state without a server
Share data with your friends

Representing users:
Client-side, users must work with the VIEWER and the OWNER .

Multiple personalities:
When you visit your own profile, you are both the VIEWER and the OWNER .

OpenSocial requests:
An OpenSocial DataRequest is created.
Requests are added to the DataRequest.
The DataRequest is sent to the server asynchronously.
When the request finishes, the supplied callback will be called.
function request() { var req = opensocial.newDataRequest(); req.add(req.newFetchPersonRequest("OWNER"), "get_owner"); req.add(req.newFetchPersonRequest("VIEWER"), "get_viewer"); req.add(req.newFetchActivitiesRequest("VIEWER"), "vactivities"); req.add(req.newFetchPersonAppDataRequest("OWNER", "*"), "odata"); ... req.send ( response );}; function response (data) { ... }; gadgets.util.registerOnLoadHandler(request);

OpenSocial responses:
Responses are bundled according to the keys specified in the request.
Check for an error at the global response level .
Check for an error at the specific response level .
Use getData() to retrieve the actual information in a request.
function response(data) { if ( data.hadError() ) { if ( data.get("get_owner").hadError() ) { ... } if ( data.get("get_viewer").hadError() ) { ... } ... } var owner = data.get ( "get_owner"). getData (); var viewer = data.get( "get_viewer"). getData (); };

The OpenSocial JavaScript API Working with people:
opensocial.Person - JavaScript representation of a user.

The OpenSocial JavaScript API Request one person: req.add(req.newFetchPersonRequest( idspec , opt_params ), "key");
idspec can be either “VIEWER”, “OWNER” or an ID number.
opt_params contains extra request parameters, such as which profile fields to fetch.
newFetchPersonRequest responses: var owner = data.get("key").getData(); alert(owner.getDisplayName());
Data contains a single opensocial.Person object.
Person objects can contain lots of information, such as addresses, companies, phone numbers, favorite movies, and thumbnail urls.

The OpenSocial JavaScript API Methods available on an OpenSocial Person:
getDisplayName() Gets a text display name for this person; guaranteed to return a useful string.
getField(key, opt_params) Gets data for this person that is associated with the specified key.
getId() Gets an ID is permanently associated with this person.
isOwner() Returns true if this person object represents the owner of the current page.
isViewer() Returns true if this person object represents the currently logged in user.
Live Demo

ABOUT_ME
ACTIVITIES
ADDRESSES
AGE
BODY_TYPE
BOOKS
CARS
CHILDREN
CURRENT_LOCATION
DATE_OF_BIRTH
DRINKER
EMAILS
ETHNICITY
FASHION
FOOD
GENDER
HAPPIEST_WHEN
HAS_APP
HEROES
HUMOR
ID
INTERESTS
JOB_INTERESTS
JOBS
LANGUAGES_SPOKEN
LIVING_ARRANGEMENT
LOOKING_FOR
MOVIES
MUSIC
NAME
NETWORK_PRESENCE
NICKNAME
PETS
PHONE_NUMBERS
POLITICAL_VIEWS
PROFILE_SONG
PROFILE_URL
PROFILE_VIDEO
QUOTES
RELATIONSHIP_STATUS
RELIGION
ROMANCE
SCARED_OF
SCHOOLS
An OpenSocial Person's fields:
SEXUAL_ORIENTATION
SMOKER
SPORTSSTATUSTAGS
THUMBNAIL_URL
TIME_ZONE
TURN_OFFS
TURN_ONS
TV_SHOWS
URLS

The OpenSocial JavaScript API Working with people:
A Collection represents many opensocial.Person objects.

The OpenSocial JavaScript API Request many people: var idspec = opensocial.newIdSpec({ “ userId” : “OWNER”, “groupId” : “FRIENDS”}); req.add(req.newFetchPeopleRequest( idspec , opt_params ), "key");
idspec is an object that can represent groups of people. “userId” can be “VIEWER” or “OWNER” or an ID, and “groupId” can be “SELF”, “FRIENDS”, or the name of a group.
opt_params contains extra request parameters, such as which profile fields to fetch, and how to order or filter the returned people.
Process the response: var owner_friends = data.get("key").getData(); owner_friends.each(function (person) { alert(person.getDisplayName()); });
Data contains a Collection of opensocial.Person objects.
Live Demo

The OpenSocial JavaScript API Working with data:
Persistent data gives apps key, value storage directly on the container.
String only, but conversion to JSON allows for storage of complex objects.
Storage per app per user - scales well with growth.
Ideal for settings, customizations.

The OpenSocial JavaScript API Set persistent data: req.add(req.newUpdatePersonAppDataRequest( idspec , key , value ));
idspec can only be “VIEWER”.
key is the name under which this data will be stored.
value is a string representing the data to store.

The OpenSocial JavaScript API Fetch persistent data: var idspec = opensocial.newIdSpec({ "userId" : "OWNER", "groupId" : "SELF" }); req.add(req.newFetchPersonAppDataRequest( idspec , keys ), "key"); req.add(req.newFetchPersonRequest("OWNER"), "ownerkey");
idspec is an object that can represent groups of people, the same as newFetchPeopleRequest.
keys is a list of persistent data keys to retrieve the data for.
The owner is requested because the data returned is indexed by user ID and we want the owner’s data.
newFetchPersonAppDataRequest responses: var app_data = data.get("key").getData(); var value = app_data[owner.getId()][key];

The OpenSocial JavaScript API Fetch persistent data: { "1234567890" : { "key1" : "value1" }, "2345678901" : { "key1" : "value2" } }
Data is returned as an object indexed by ID number, then as an object indexed by key name, even if there is only data returned for one user!
{ "1234567890" : { "key1" : "value1" } }
Multiple people:
{ "1234567890" : { "key1" : "value1", "key2" : "value2" } }
One person, multiple keys:
Live Demo

The OpenSocial JavaScript API Working with activities:
API to post information about what users are doing with your app.
Many containers have support for images and some HTML.
Channel to grow your application.
orkut MySpace hi5

The OpenSocial JavaScript API Post an activity: function postActivity( text ) { var params = {}; params[opensocial.Activity.Field.TITLE] = text ; var activity = opensocial.newActivity (params); opensocial.requestCreateActivity (activity, opensocial.CreateActivityPriority.HIGH, callback); };
Assign the activity text to the TITLE field.
Call opensocial.newActivity() to create a new Activity instance.
Call opensocial.requestCreateActivity() to post the activity to the container.
Live Demo

RESTful and RPC protocols
Servers talking to servers

Opens new development models
Background processing.
Easier Flash integration.
Mobile applications.

Communication methods:
RESTful (Representational State Transfer)
RPC (Remote Procedure Call)
Formats:
XML
JSON
AtomPub

REST:
Resources are URLs.
/people/{guid}/@all
All people connected to the given user:
Example - People: /people/{guid}/@friends
All friends of the given user:
/people/{guid}/@self
Profile of the given user:
/people/@me/@self
Profile of the authenticated user:
/people/@supportedFields
Supported Person fields:

Response format (JSON, XML, AtomPub)
Request extra fields
Filtering:
Paging:
fields={-join|,|field}. filterBy={fieldname} filterOp={operation}filterValue={value} updatedSince={xsdDateTime} networkDistance={networkDistance} count={count} sortBy={fieldname} sortOrder={order} startIndex={startIndex} format={format} Querystring parameters customize requests:

RESTful and RPC protocols <person xmlns=" http://ns.opensocial.org/2008/opensocial "> <id></id> <displayName></displayName> <name> <unstructured>Jane Doe</unstructured></name> <gender>female</gender> </person> REST responses (Person): {"id" : "example.org:34KJDCSKJN2HHF0DW20394", "displayName" : "Janey", "name" : {"unstructured" : "Jane Doe"}, "gender" : "female"} JSON: XML:

RESTful and RPC protocols REST responses (Person): AtomPub: <entry xmlns=" http://www.w3.org/2005/Atom "> <content type="application/xml"> <person xmlns=" http://ns.opensocial.org/20 08/opensocial "> <name> <unst ructured>Jane Doe</unstructured> </name> <gender>female</gender></person> </content> <title/> <updated>2003-12-13T18:30:02Z</updated> <author/> <id>urn:guid:example.org:34KJDCSKJN2HHF0DW20394</id> </entry>

REST:
Perform operations using different HTTP methods on each URL.
CRUD:
C reate
R etrieve
U pdate
D elete
HTTP:
POST
GET
PUT
DELETE

REST has some disadvantages:
Batch support requires multiple HTTP requests, or a contrived URL scheme.
Specifying multiple users via querystring is difficult. Is ?uid=1234,5678 the same resource as ?uid=5678,1234 ?

RPC:
One endpoint - parameters specify methods to call.
Batch support.
Specify collections of users through passed arguments, not URLs.
POST /rpc HTTP/1.1 Host: api.example.org Authorization: <Auth token> Content-Type: application/json { "method" : "people.get", "id" : "myself" "params" : { "userid" : "@me", "groupid" : "@self" }} Example - Fetch current user:
Request
HTTP/1.x 207 Multi-Status Content-Type: application/json { "id" : "myself" "result" : { "id" : "example.org:34KJDCSKJN2HHF0DW20394", "name" : { "unstructured" : "Jane Doe"}, "gender" : "female" }}
Response

RESTful and RPC protocols Authentication: Both protocols use OAuth to identify users and apps. Depending on what the application needs to do, it can use two-legged or three-legged OAuth.
Two-legged OAuth:
The application authenticates directly with the container .
Perform non-user specific operations:
Update persistent data for app users.
Can request information for users who have shared their profile information with the app.
Three-legged OAuth:
The user tells the container to give profile access to the application .
Perform user specific operations:
Post activities.
Fetch friends of the current user.

Client libraries are being created for PHP, Java, Python, Ruby.
Help you connect to OpenSocial containers, and work with social data on your server.
Sample: Login, get thumbnail and friends. OpenSocialClient c = new OpenSocialClient("myspace.com"); c.setProperty(OpenSocialClient.Properties.REST_BASE_URI, "http://api.myspace.com/v2/"); c.setProperty(OpenSocialClient.Properties.CONSUMER_SECRET, <MYSPACE_SECRET>); c.setProperty(OpenSocialClient.Properties.CONSUMER_KEY, <MYSPACE_APP_KEY>); c.setProperty(OpenSocialClient.Properties.VIEWER_ID, <YOUR_MYSPACE_ID>); OpenSocialPerson p = c.fetchPerson(<YOUR_MYSPACE_ID>); OpenSocialField f = p.getField("thumbnailUrl"); System.out.println(f.getStringValue()); Collection<OpenSocialPerson> friends = c.fetchFriends(<YOUR_MYSPACE_ID>); for (OpenSocialPerson friend : friends) { System.out.println(friend.getDisplayName()); }

OpenSocial Intro

by Pamela Fox

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 1

Statistics

OpenSocial Intro Presentation Transcript