Beginning with OpenSocial 0.9, support for a new featured called Data Pipelining was introduced. Pipelining is really simple to implement and can bring a lot of speed and power to your applications. Pipelined requests are sent before a gadget has been loaded so they are significantly faster.

Data pipelining can be used to load all sorts of information from friends lists, remote json data and plain HTML. For this example, I’m showing how to use pipelining to load in HTML to generate a home view more quickly than using gadgets.io.makeRequest() or osapi.http() after the gadget loads. Another option for quickly loading content is to use tag which provides essentially the same functionality as the data pipelining example here, but may or may not be supported by your container. To really get into the power of these alternatives to fetching data after load, be sure to read the developer wiki notes on remote data requests.

This simple gadget that will load the contents of a file and inject them into the DOM using simple JavaScript.

<?xml version="1.0" encoding="UTF-8" ?>
<Module>
	<ModulePrefs>
		<Require feature="opensocial-0.9" />
		<Require feature="opensocial-data"/>
		<Require feature="views" />
		<Require feature="dynamic-height" />
	</ModulePrefs>
	<Content type="html" view="home">
	<![CDATA[
<script xmlns:os="http://ns.opensocial.org/2008/markup" type="text/os-data">
	<os:HttpRequest key="home" href="http://example.com/data_pipeline.php" method="post" format="text" authz="signed" />
</script>
<script type="text/javascript" src="http://example.com/display.js"></script>
<div id="target_div">
</div>
}]>
	</Content>
</Module>

The content of display.js simply loads the pre-fetched content into the target_div on the home page view.

function init(){
	var home = opensocial.data.getDataContext().getDataSet('home');
	if(home && !home.error){
		if(home.content != undefined){
			document.getElementById('target_div').innerHTML = home.content;
		} else {
			document.getElementById('target_div').innerHTML = home.result.content;
		}
	}
}
gadgets.util.registerOnLoadHandler(init);

The entire “page” that you would want to generate for this display should be passed back as the output from the file http://example.com/data_pipeline.php. The file will be called with as a signed post containing the current viewer $_POST['opensocial_viewer_id'] and owner $_POST['opensocial_owner_id'] user id values along with the other required signature fields.

You can now query your systems to generate the appropriate display. For example, if the owner and viewer are the same, you might show a summary of activity to their account since they last visited the application. If the viewer and owner are not the same, you might display a public view of the owners activity within the application (and possibly promotional material if the viewer isn’t currently a user of the app).

Storing application data on the OpenSocial host is a great way to offload some unnecessary database and application server load. Why request a preference such as a skin for a user profile from your servers if we can just let the container handle it? MySpace allows for ~1K of data storage per user per application. However, there is a bug with the method newFetchPersonAppDataRequest when added as the only item of a DataRequest. Calling send on the request doesn’t actually do anything! It returns a DataResponse object with no data. As a work around, grab some other information to ensure that the request actually is sent to the container’s server. I used the owner data in this example.

// The function to load the application data
function getAppData(){
	var req = opensocial.newDataRequest();
	var owner = opensocial.newIdSpec({"userId":"OWNER"});
	req.add(req.newFetchPersonRequest(owner), "owner");
	req.add(req.newFetchPersonAppDataRequest(owner, "appdata"), "owner_appdata");
	req.send(getAppDataCallback);
	return;
}
 
// The callback for getAppData()
function getAppDataCallback(d){
	var owner = d.get("owner"); // if you need it, use it!
	var data = d.get("owner_appdata");
	if(data.hadError()){
		// handle the error appropriately
		return;
	}
	// do whatever your program needs to do with the data
}

MySpace has a good post explaining why you can’t use relative links within OpenSocial applications. If you’re building for the OpenSocial container and trying to make valid HTML apps, watch out for this one. I’ve written the following in a lot of applications and suspect that others have as well. The #na below will cause problems, despite being valid markup.

<a href="#na" onClick="doJavascriptCall();">Click Me</a>

Consider the following ways to invoke functionality instead:

<a href="javascript:;" onClick="doJavascriptCall();">Click Me</a>
<div onClick="doJavascriptCall();">Click Me</div>

While at GSP East, I presented on Muddl, a light fun word game that is anagram like in nature. I received lots of great feedback on the game from folks and encourage everyone to check it out.

It’s currently available on Facebook and Bebo. I’ll be finishing the port to MySpace and other OpenSocial containers soon.

The game play is very simple. After you go to the app you’re presented with some scrambled up letters. You then try to figure out what the word is. If you don’t get the word correct the system gives you a clue. If you’re still wrong you’ll get the first letter of the word revealed. After 3 tries you’ll be provided with another word. The game continues to challenge you as you play by increasing the length of the word.

Photo of Erik © James Duncan Davidson used with permission.

This week at GSP East the big names in the OpenSocial space came forward and basically gave a brief sales pitch on why they’re the platform to build on. Allen Stern has a nice synopsis of the panel. As a developer making decisions on where to focus time and efforts it seems like OpenSocial itself is really just playing catchup to Facebook. Most of the development folks I know are focused on Facebook still and are waiting for OpenSocial. The philosophical discussion aside, OpenSocial is looking stronger and stronger each day. Facebook recently open sourced their platform, but they’ve yet to announce any partners (beyond Bebo) who are adopting it. So their late foray into openness may be moot now.

OpenSocial, a group effort to create a widget platform spear headed by Google, has a few glitches that I’d love to see fixed. They are largely comparison items from Facebook, who has recently announced that it will open source it’s own platform. Regardless of the motivation, there are a couple of items I’d like to see ported from Facebook to OpenSocial.

1. Support for FBML like syntax: “Hold on a second! Standard HTML is the benefit of OpenSocial over Facebook” folks are probably thinking. While that’s true, without an effective way to capture and store user information for more than 24 hours (pesky terms of service documentation) developers are left querying for friends pictures etc over and over and over again. While this isn’t inherently a problem, if you wanted to display a 1,000 profile pictures for some unknown reason, you need to call the API a large number of times. Then generate the HTML and pass it to the client. This makes applications painfully slow. It’s great to store the numeric id (12345678) and be able to pass it back to the pre-client for parsing. The best examples are and . These really are very handy.
2. Support for FQL like syntax: OpenSocial does a great job of providing methods for gathering most of the information you would want from the social graph, but it’s lacking in the ability to remix the data in new and interesting ways (easily). OpenSocial requires all of the heavy lifting to be done on the client (or the application backend if their API allows it). Most clients have a reasonable limit as to how big data structures can effectively be and have the application still function. Processing on the applications infrastructure negates another advantage of OpenSocial which is requiring very little in the way of hardware to operate.

There are also some learnings here for Facebook. I’d like to see a few OpenSocial conventions ported from OpenSocial to Facebook.

1. OAuth Signature: To be fair, Facebook does provide signed requests, but it would be great if they’d use a standards based signature instead of their own homegrown version.
2. External JavaScript Libraries: Facebook’s FBJS is powerful and provides most functionality that developers need. It’s even been open sourced so it can be used outside of the Facebook universe. However, developers who’ve been working with jQuery, ProtoType or any of the other numerous javascript libraries have to start at the beginning again. Additionally, they may be missing the functionality in the FBJS library that they need.

Both platforms still have a ways to go in terms of making developers life’s easier and users application experiences more robust. I think it’s great news that Facebook is opening their platform more. It’s really more symbolic than anything, because they still ultimately control what they do or do not implement on their platform. Bebo is the only other social network using Facebook’s model and it still requires some re-writing for developers because of syntax difference and lack of some features.

Hi5 (yet another social network) is launching their OpenSocial based platform today (well really tomorrow and over the next few weeks) and have done a really great job communicating with developers how stuff is going to work. For example, letting developers know what will and won’t be working in their release plan. Facebook and MySpace could learn a good lesson here in communication. Stop being vague with your plans and let your developers and advocates know what’s up. Facebook has made some great strides with their notifications around larger platform changes, but the small stuff is still an open question.

Today I noticed a new tab in the application editor making it infinitely easier for developers of OpenSocial applications to adopt the MySpace platform. I first said they should be doing this two weeks ago and I’m happy to announce that they are. They now allow for the simple monolithic XML file to define your application. This is a great step forward. Their platform is becoming more robust and stable each day. Kudos to them, but they still have a lot to do as Nick O’Neill pointed out yesterday.

This evening I had the opportunity to implement what should have been a simple OAuth signature validation until I ran into trouble parsing the parameters of the request. I decided to use one of the many pre-built libraries instead of rolling my own (perhaps that’s where I went wrong) but I found that it wasn’t as easy as I had expected.

A quick primer for those unfamiliar with PHP, there are multiple variables that hold request information. The two most common for passing parameters to a PHP script are $_GET and $_POST, which are both associative arrays. PHP handles the encoding of the values and brings everything back to regular strings. This is very handy for passing data. There is one more useful structure called $_REQUEST that actually holds both sets of values in one structure – also very handy if you don’t know where your data will be coming from on a given request. Now back to my issue.

OAuth augments your parameters with a few specific values that are unique to it’s implementation and uses a shared secret key system to digitally sign requests providing a level of trust with any request. If your lost with OAuth, I wrote a quick primer about it a month or so ago. OAuth takes any data you pass and signs them into a hashed value by concatenating the data with the shared secret and a few other parameters. The resulting hash is then very unique and very difficult to guess. On the server side, you can now validate the request by looking at the parameters and re-calculating the hash value.

While that’s simple in theory, it’s a bit more difficult in practice, especially with MySpace’s implementation of OpenSocial and OAuth. Yesterday I blogged about how to make AJAX requests using OpenSocial. As a habit, I always default requests to POST when possible to get around any arbitrary data size limits that might be present and to keep data out of my log files. This resulted in quite a bit of drama trying to implement the signature because the library wanted to evaluate the POST parameters and MySpace sends them as GET values. I tried tweaking the library to use the generic $_REQUEST parameters, however, the $_POST values weren’t included in the hash! As a result I ended up moving all requests over to use get – which was very simple.

Below you’ll find the revised GET friendly code:

function ajaxRequest(url, callback_func, post_params){
   var queryString = "";
   for (k in post_params) {
      queryString += "&" + k + "=" + encodeURIComponent(post_params[k]);
   }
   url += "?" + queryString;
   var osParams = {};
   osParams[gadgets.io.RequestParameters.AUTHORIZATION] = gadgets.io.AuthorizationType.SIGNED;
   gadgets.io.makeRequest(url, makeRequest_callback, osParams);
   function makeRequest_callback(data){
      renderStatus("Handling ajax response with typeof: " + typeof(data.data));
      var json = gadgets.json.parse(data.data);
      if(!json){
         alert('Unable to parse JSON object');
      }
      callback_func(json);
   }
}

Now you can use the OAuth libraries to parse your signature in PHP and verify who’s posting to your data points. Don’t forget to s/_POST/_GET/g your code to update all POST references. It seems like a bug to me in the implementation that if the request is made via POST the parameters wouldn’t also be passed in the same way. Perhaps there’s a method to the madness I’m not aware of?

Two MySpace developers posting on a thread regarding requestNavigateTo within the MySpace environment need credit for this one. Kristaps and Eric posted a discussion which included some nice brief code snips. The code is short and sweet. All that’s required is a surface name and any optional parameters you would want to pass to that surface. Note in OpenSocial 0.7 “surfaces” are now known as “views” which might throw some developers for a loop as they make the transition.

function navigate(surfaceName, params){
   var surfaces = gadgets.views.getSupportedViews();
   var surfaceRef = surfaces[surfaceName];
   gadgets.views.requestNavigateTo(surfaceRef, params);
}

Valid views within MySpace (as of this time) are home, profile, and canvas. Sample usage for moving to the Canvas view from the profile (or home) would be as follows:

<a href="#na" onClick="navigate('canvas',{});" title="Move to canvas">go to canvas</a>