Calling the OpenSocial JavaScript API
Now it's time to call the OpenSocial JavaScript API and socialize your Flash.
Friends and Relationships
The ActionScript communicates with JavaScript using the
Call and
CallBack
functions, which are provided with ExternalInterface. For example, when initializing, the information
about
viewer is loaded through the following code.
if (ExternalInterface.available) {
ExternalInterface.call("loadViewer");
ExternalInterface.addCallback("onJSLoadViewer", onASLoadViewer);
}
For simplicity, omit the error checking.
ExternalInterface.calls, the
loadViewer function written in
main.js. The
ExternalInterface.addCallback registers the
onASLoadViewer function in ActionScript as a
onJSLoadViewer function, which is available for JavaScript. Here's the corresponding code in
main.js:
function loadViewer() {
var req = opensocial.newDataRequest();
req.add(req.newFetchPersonRequest(opensocial.IdSpec.PersonId.VIEWER), "viewer");
req.send(onLoadViewer);
}
function onLoadViewer(data) {
var person = data.get("viewer").getData();
var personname = person.getDisplayName();
var personid = person.getId();
thisMovie('demoswf').onJSLoadViewer(personname, personid);
}
The above code illustrates the steps taken to request data with the OpenSocial API.
In the
loadViewer function, you need to:
- Create a request (opensocial.newDataRequest).
- Specify what kind of data you need (opensocial.IdSpec).
- Send a request and pass the callback function as a parameter.
Then, in
onLoadViewer call back function:
- Get data when calling back.
- Call the ActionScript function to return data to Flash.
With this request, you obtain the user name and ID before the Flash content starts. Such a request also occurs in
the demo application when you click the Get Friends button or ExternalInterface calls
loadFriends.
The request for the friend's data is similar. But instead of using
newFetchPersonRequest, you should use
newFetchPeopleRequest, because you are asking for information about several people. The returning data is an array of person (see
Listing 2).
Persistence
As noted earlier, use GQL to save the user data instead of the OpenSocial API. The next section puts this into context.
Activity
Activity in OpenSocial means anything the application posts on a user's page. For example, activities include game
progress or achievements earned in a game. But the application needs the user's permission to post activities. The
steps to post activities are straightforward (from the
OpenSocial
Developer's Guide):
- Call newActivity to create a new activity with the given text as its title.
- Call requestCreateActivity to send the activity to the server, passing a callback function.
- In the callback function, handle an error if the server returns one.
Unfortunately, this feature is not very well supported. As tested, Friendster doesn't implement it and error messages occur when posting activity in MySpace.
Check Point 3: Now you can use the OpenSocial API to load user and friends' data from containers. The API is
easy to use, but debugging is a problem. It is suggested that you use the
Firefox's Firebug plugin for Firefox to debug JavaScript code.
Using Persistent User Data for Comments
As stated previously, you should use the datastore service of GAE instead of the OpenSocial Persistence API.
First, you need to define a data model. Do this by deriving a new class from
db.Model in the google.appengine.ext package.
from google.appengine.ext import db
class Comment(db.Model):
uid = db.StringProperty()
content = db.StringProperty()
The example's Comment model pretty simple. It contains two strings for the comment and user id content.
Then, use the makeRequest OpenSocial API to access the GAE database
(clicki here for introduction to
makeRequest). To save a user's comment, a Post request is made along with the content. Use the Get method to retrieve a comment (see
Listing 3).
As in the loadFriends function, callback functions (onSaveComment and
onLoadComment) are also provided as a parameter when making a request. You can check whether an error occurs and report it to front end Flash through ExternalInterface.
On the GAE side, a new RequestHandler class ApiServer is created to deal with the
GET and POST access to
http://flashsns.appspot.com/comments (see
Listing 4).
The syntax of GQL is similar to SQL (check the reference
here).
Check Point 4: The Save/Load was implemented with GQL for persistent user data. You can check all the saved
data in the DataViewer section after logging in to GAE as admin. The logging function in
GAE helps debug.
Finally, by following all the procedures, you have now integrated all three OpenSocial features (People and Relationships, Persistence, and Activities) for a Flash demo. You've hosted the entire project in GAE. Theoretically speaking, to make it run on different containers, the only step left is to submit the URL of the XML file, which describes the application. But because OpenSocial is constantly upgraded, the compatibility to the social network sites is inconsistent. Hopefully, things will improve soon.